INFO: I installed SymformSync the other day, a distributed cloud storage system, but deleted it again the same day. (I like the idea, but it's not suitable for someone on a laptop like me.) However, there's a process symformsync that keeps popping up and consuming pretty heavily on the CPU. I deleted the application, but this process still keeps popping up! Needless to say, I don't appreciate not having control over the processes on my own CPU!
Q: How do I find this process that keeps starting up by itself, and how do I delete it?
Answer from Symform:
Thank you for contacting Symform support. I understand that you are needing the instructions to remove Symform from your Mac.
Here is the information:
Access the Terminal program on your Mac, by going to the search tool in the upper right-hand corner, and entering in Terminal.
Once Terminal is open, enter in the following command, depending on what you want to do:
Normal uninstall will only stop the services and remove the software. It will leave the service configuration and log files in place.
sudo /Library/Application\ Support/Symform/scripts/uninstall
To completely remove all aspects of the Symform software, configuration, and logs, a purging operation is available as well. This will remove any synchronization and contribution supporting files and directories too.
sudo /Library/Application\ Support/Symform/scripts/uninstall --purge
You will need to enter in your Mac password when running either of these commands.
Related
I'm trying to use docker beta on OSX, mainly for Symfony development but the mounted volumes are incredible slow. Even for a vanilla Symfony project I get 6s page load time. That's unbearable! Has anyone found a solution to this issue? Trying to move away from vagrant but I just can't find any reasonable way to work with docker instead.
Okay the user Spiil gave a solution but I wanted to elaborate on the exact steps to take since I went through 12 hours trying to figure it out, but once you know how its super easy and fixes all the slow down issues!
The key here is to understand this solution creates NFS (Network File System) drives as the means of communication from the Docker Containers to your Mac instead of the standard OSX File System which is very slow currently either due to bugs or the way it works*
Follow these steps exactly.
1.) Clone this repo here (https://github.com/IFSight/d4m-nfs) in your home directory. To do this open up terminal and type cd ~
Then type git clone https://github.com/IFSight/d4m-nfs
Alternatively you can also do this in a one liner git clone https://github.com/IFSight/d4m-nfs ~/d4m-nfs
2.) Next go into the d4m-nfs folder and create a new file in the /etc folder and title it d4m-nfs-mounts.txt
3.) Add the following lines of code to this.
/Users/yourusername:/Users/yourusername:0:0
What the above does is allows you to still use relative folders with docker-compose and allows all ports to connect on it hence the 0:0.
EDIT
Do not put /Volumes here!!
4.) Go to your docker preferences and do the following
Make sure only /tmp is showing and NOTHING ELSE. I mean nothing else it won't work if there is anything else since it will create conflicts with the NFS systems that the script will make for you later. Restart docker and docker-compose down any containers as well.
5.) Finally navigate to the d4m-nfs directory we created in step 1 and type the following command, /bin/bash d4m-nfs.sh
edit The correct way to type the command above is this as another user from the github (if-kenn) pointed out, ./d4m-nfs.sh which uses the Shebang for what shell should run it.
If done correctly there should be no errors and this should work. Please note DO NOT RUN as sh d4m-nfs.sh this will create errors and you will have to delete your exports file to start over. In fact anytime you make any changes you will have to clear your exports file.
This is what mine looks like.
EDIT:: IMPORTANT -- Remove the /private and volumes! This should only be users/username now!
If you see anything other than this you were not running with bash. You can quickly get to the exports file like this in Mac if you make any errors and just clear it out to start over.
Just select go to folder
and then type /etc/exports
This is a nice shortcut to quickly get to it and clear it out in your favorite text editor.
Also make sure no containers are running or you will get the ........ loop of death. If this loop of death continues make sure you upgrade docker and then restart your computer. Yes restart... it seemed to be the only way to get it to work on my friends computer. Refer to this (https://github.com/IFSight/d4m-nfs/issues/3)
Note to .... loop. I recently found another solution. Make sure you are NOT logged as root, and make sure you pulled the git repo into your users ~ folder not the root ~ folder. In otherwords, it should be in Users/username.
Also, make sure /tmp folder has full write permissions since the script needs to write here or this won't work either. chmod 777 -R /tmp
6.) If you did it right when running the script it will look like this.
Then simply run your docker-compose up -d as usual in your symfony project folder (or whatever project you are using with docker) and everything should work... except NO MORE slow downs!
You will need to run this anytime you restart your computer or docker.
Also note if you get mounting errors showing up, you probably don't have your project stored in your Users/username directory. Remember that is where we mounted it. If your project is somewhere other than there you will need to modify the d4m-nfs-mounts.txt file accordingly.
Other Info:
For people reading this now, maybe it's better to wait for Docker to fix this issue. A pull request has already been accepted to improve performance(https://github.com/docker/docker/pull/31047).
This will be release somewhere in April 2017 and should be a big improvement.
I've tried some workarounds for Docker for Mac, but all of them had some pretty big disadvantages, mostly in usability. A good source for alternatives of the OSXFS can be found at: https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync. Credits for Eugen Mayer for setting this up.
EDIT:
First improvement is implemented in the edge release. https://github.com/docker/for-mac/issues/77 has more info on this.
There's a long thread with explanation from Docker Team and various workarounds.
Currently, the issue is being tracked on GitHub.
While some workarounds may be better than others, I'm afraid the ideal option for now is to switch to Linux.
I spent a lot of my time in searching viable solution. And I found.
d4m-nfs
allow you use docker volumes via nfs.
In my case it gave increase performance 16 times! (1.8sec vs ~30sec)
Also d4m-nfs has quite a intricate manual, so here is another link with detailed example: https://github.com/laradock/laradock/issues/353#issuecomment-262897619
I just leave this here for other googlers.
Normaly volumes should be fast.
But you can not change anything to make them faster if you dont want to change the format of your disk.
But maybe the bottleneck is the CPU or RAM.
You can check that with the command docker stats. These are by default set to 2 cores and 2 GB RAM. You can change this in the Docker for Mac GUI.
I had exactly the same thing. For me using docker-bg-sync (see on GitHub) made a dramatic improvement in speed and CPU usage.
Not as nice as just mounting the volume as you have to start a new container for every sync but it does the job.
In latest docker 17.06.0-ce-mac18 volumes mounted with :cached seems to run quite decent.
I've found that creating a CoreOS VM under Parallels, then using the Docker that is inside CoreOS is far faster than Docker for Mac (currently running Version 17.12.0-ce-mac49 (21995)).
I'm doing Linux code builds using CMAKE/Ninja/GCC and it's almost twice as fast as the exact same build from Docker for Mac.
In my case, I have a ton of library sources that are part of the container (e.g. Boost, OpenSSL), and a decent amount of C++ code that I keep local to my Mac.
This seems to be a recent development. Docker/Mac has become much slower than I remember it being a month or two ago. Maybe it's just me...
We overcame this issue by synchronizing the local and the docker for mac filesystem using syncthing. We built an open source tool that follows this approach, in case it helps:
https://github.com/okteto/cnd
I want to be able to take a snapshot of the current system and will go back to it whenever I mess up with files. I looked at the Time Machine solution, but realized that it's only a good solution when I know what file I am looking for. But sometimes, some installation process creates binary files in multiple system paths, which are very hard to locate and identify. Say I installed a package, but then I felt like I shouldn't have done that. Uninstallation might still leave files around. So What might be some of the graceful solutions to go back to a status of the machine when everything is nice and clean.
Use disk utility (Applications | Utilities)
Click on the HDD and then click on new image. You can choose to have a compressed image or not. If you don't have much stuff on the drive it shouldn't be more than 30-40GB. Once you have the dmg file, stick it somewhere for backup purposes.
Also, create a recovery disk/stick with the recovery tool.
I dunno about "graceful" but Carbon Copy Cloner is definitely an easy solution for rolling back to a previous state. You can make an exact clone of your drive, then restore it back if something goes horribly wrong. I use CCC to make periodic backups of my Macs, as a sort of secondary backup to time-machine, which is easy to use but which I don't have total confidence in.
You can restore an entire system from a Time Machine snapshot, but it requires booting from the Recovery Partition or a Recovery disk. Basically, once you've rebooted in recovery mode, you can choose Restore From Time Machine Backup and then you'll be asked to locate the drive. Once you've done that, a list of Time Machine snapshots will be presented for restoring.
I haven't done this recently, but there are indications that the time of the backups may always be in PST, so be careful when looking at the times.
While OSX comes with TimeMachine, it also has the well-known (in Linux community!) command line tool called rsync.
With Google, I'm sure you can find many articles of how to use it, though here's an interesting blog of why its author uses rsync with Time Machine.
I'm currently installing qt4-mac and it's taking forever to build. I've searched around and I've discovered that it's going to take anywhere from 2-5 hours to install.
Is there a way to interrupt this installation process and if so do I need to do some clean-up afterwards?
Have you tried using control+c?
Also, I'm not entirely sure about cleanup, but according to the MacPorts docs, the command sudo port -fp uninstall --follow-dependents [your port name here] should help (this page is about uninstalling MacPorts itself, but it's the same command). I'm not sure how MacPorts treats interrupted installations and if it treats "half-installed" items as uninstallable, but it's worth a try.
This is an old thread, but I'd like to share my personal opinion on this.
Once upon a time (two years ago I guess, not sure about the current state of affairs) I interrupted a MacPorts update (sudo port upgrade outdated) with not Ctrl+C (roughly SIGINT), but rather SIGKILL, since I was running into some trouble with the hardware at that time. I ended up with a completely broken install that defied all efforts of clean-up or recovery, and I ended up restoring a full backup of /opt/local.
I never dare to interrupt MacPorts install/upgrade since then, even with Ctrl+C's.
The moral of the story is: interrupting MacPorts installation process could be potentially pretty dangerous. Leave it alone if it is simply running for a long time (sometimes building does take forever). If you do believe it is hanging rather than actually building, make sure you have a backup, and proceed with caution (of course, it's too late to back up when you are already running the install).
I also would like to chime in. I think a good practice is to watch where you are in the installation before Ctrl+Cing, then clean the dependency you were on and redo the main install later. For example, I was installing kdenlive and killed it in the middle of the virtuoso (one of many dependencies) install. Later, I did a sudo port -v selfupdate, then a port clean virtuoso, then started the kdenlive install again with sudo port install kdenlive. This seems to be a decent way to go; it cruised through the first part and picked up at normal speed when it got to virtuoso.
Don't press Ctrl+C
Building on the answer by 4ae1e1, while (s)he interrupted the process sending a SIGKILL signal, I interrupted it sending an actual SIGINT signal, i.e. the usual Ctrl+C, and now no MacPorts app are working so far.
So I completely agree with 4ae1e1.
If you need your machine
If you need to suspend the installation, e.g. because you need your CPU to be available for other things, to send a SIGSTOP signal instead, in order to pause the installation.
kill -STOP installationPIDs
Once you are ready to resume it, you can send a SIGCONT signal and you can complete it.
kill -CONT installationPIDs
You should easily find the PIDs of the installation process, for example you can just run htop and look among the processes using most of the CPU.
If you change your mind about an installation
Even if you change your mind and you do not want that port/package installed anymore, I strongly recommend to just complete the installation (pausing it when needed as suggested below) and just uninstall the port/package afterwards. It sounds like a waste of time, but it is the safest thing to do.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.
I want Windows Update to automatically download and install updates on my Vista machine, however I don't want to be bothered by the system tray reboot prompts (which can, at best, only be postponed by 4 hours).
I have performed the registry hack described here to prevent Windows forcibly rebooting my machine, which is a good start. However, is there any way to get rid of the reboot prompts altogether, or decrease their frequency?
Not sure if it is the same for vista, but worth a try.
On Windows XP, you can modify a group policy setting to change how frequently it re-prompts you. (start -> run type gpedit.msc)
Look under Computer Configuration/Administrative Templates/Windows Components/Windows Update
The setting you want is called Re-Prompt for restart with scheduled installations.
The default is 10 minutes.
You can also try modifying the No auto-restart for scheduled Automatic Updates installations setting found in the same location.
Just turn off the Automatic Update service. It will restart the next time you reboot so you'll still get the updates done.
Running this in a command window will stop it until the next reboot.
sc stop wuauserv
I recommend disabling the auto update.
As a developer the last thing you need is to have random updates done to your workstation, especially while you are working. I set aside a time every month to go through the process manually. I avoid doing it if I am in the middle of testing something really important or up against an immediate deadline.
To clarify what ehogue said:
Start->Control Panel->Administrative Tools->Services->Automatic Updates->Right-click->Stop.
In Windows XP, after windows has been updated, I use the following trick: run this command
pssuspend wuauclt
pssuspend is a free sys-internals tool.
This way, you will not be prompted about restart.
I will risk some down-votes here by saying: this seems a little bit schizophrenic, though a lot of people ask for it.
If you want Windows to download and install the updates, but not complete the install process by rebooting - what's the point? Why not simply turn of AutoUpdates in the first place? if you don't even want the OS to tell you it would like to reboot, then how can you know that you need to, y'know, reboot?
Patches which call for a reboot are not fully active until that reboot is complete; thus your system remains vulnerable to the unpatched behaviour. If you are a human who goes to the bathroom or eats meals, I just do not understand the mentality of wanting to patch but then postpone the reboot for days, weeks, months. Better to stay unpatched!
just open taskmanager and right-click on "wuauclt.exe" en clcik stop or delete or something that should keep that program from running.