Posts Tagged ‘kill’

Pause (and then resume) Battery-Guzzling programs

Wednesday, June 7th, 2017

My laptop battery dies quickly these days. Certain apps (cough, cough, Slack), have very high idle CPU-usage. You can pause these programs with

killall -STOP Slack

And later you can resume the application with

killall -CONT Slack

Kill Apple Remote Desktop via ssh

Monday, September 10th, 2012

I tried to remote control my work machine from home using Apple Remote Desktop and got the following error:

Apple Remote Desktop or another administration application is currently running.

The problem was that I had left the same Apple Remote Desktop client running on my work machine. To solve this I sshed to that machine and issued:

killall "Remote Desktop"

Update: You can then use remote desktop to reopen the Apple Remote Desktop client and go to preferences > Security and check “Allow control of this computer when this application is running”

Set up virtual host on mac os x

Tuesday, September 6th, 2011

We’re using SVN to version control our group’s webpage which is all php scripts. If everything were html files then making edits on a locally checked out copy would be easy since I can just open the files in a browser and check my edits. But, being PHP scripts, to properly see the sites I need a php server running which can host the local copy of the site and I can see the edits I make live. Then finally when I’m sure everything looks and executes correctly I can check in the edited version and update the version on the real server. Here’s how I constructed my local setup.

Check out svn to some directory, from now on referred to as “path/to/htdocs-igl”:

svn co path/to/htdocs-igl

Be sure that no apache servers are not running. The following in order should to do that:

sudo apachectl stop

Use ps and grep to determine if they really stopped. This should return nothing:

ps -ef | grep httpd | grep -v grep

If it returns some lines, then kill each replacing [PID] with each row’s process ID:

sudo kill [PID]

If the process didn’t really die then try:

sudo kill -9 [PID]

And after you think you’ve done enough killing, issuing this again for good measure:

sudo apachectl stop

Now that we’re sure no apache servers are running. Start one:

sudo apachectl start

To check that it’s working browse to http://localhost/. You should see something fully load other than “Not found, blah blah”.

Now, add the following as a new line at the bottom of the file /etc/hosts:       localigl

Now you should be able to go to http://localigl/ and see the same thing as you did with http://localhost/.

To have http://localigl/ point to your checked out version of the website, you need to edit the file /etc/apache2/users/[your mac username].conf:

NameVirtualHost *:80

<Directory "/Users/[your mac username]/Sites/">
    Options Indexes MultiViews Includes
    AllowOverride All
    Order allow,deny
    Allow from all

<VirtualHost *:80>
    ServerName localhost
    DocumentRoot /Users/[your mac username]/Sites/

<Directory "/absolute/path/to/htdocs-igl/">
    Options Indexes MultiViews Includes
    AllowOverride All
    Order allow,deny
    Allow from all

<VirtualHost *:80>
    ServerName localigl
    DocumentRoot /absolute/path/to/htdocs-igl

Replacing, in the file name and the file contents, [your mac username] with, uh, your mac username.

You must give execute access to parent directory and the root directory of the checked out website:

chmod 755 path/to/htdocs-igl/..
chmod 755 path/to/htdocs-igl

Finally, restart the server with:

sudo apachectl graceful

If you now go to http://localigl/ you should see a listing of the checked out website’s root directory contents (or if you’re using index.html, you’ll see that rendered file). Since we’re using PHP for everything we must enable php scripts.

Uncomment the following line in /etc/apache2/httpd.conf to look like this:

LoadModule php5_module        libexec/apache2/

And again restart the server:

sudo apachectl graceful

Now when you go to http://localigl/ you should see your php scripts executed and rendered.

Source This document is well written but did not enough stress that you must stop all servers (that you may have accidentally started when fooling around) before starting the steps. And it’s nice to repeat his steps with exact names closer to my current set up.

Find out which application is using external hard drive in order to eject it

Monday, November 23rd, 2009

When using the Mac OS X UI to eject an external hard drive, I occasionally get this error: ‘The disk “[volume name]” is in use and could not be ejected. \ Try quitting applications and try again.” Only mac won’t tell me which applications are using this drive. I hopelessly try to kill applications by force quitting or even using activity monitor to zap processes.

I think I have finally solved this.

Open up the program called (located in Applications/Utilities). Enter the following replacing [name of drive] with the name of your hard drive:

sudo lsof +D "/Volumes/[name of drive]"

You should get a list that looks something like this:

bash      637  ajx  cwd    DIR   14,2      442 2993107 /Volumes/path/to/file/in/use
preview   638  ajx  cwd    DIR   14,2      442 2993107 /Volumes/path/to/file/in/use

These are the applications/processes that are using your hard drive. They must be killed (quit) before you eject it safely.

Try to quit any applications you recognize the normal way. For each of the other processes (line items) you want to issue the kill command followed by that process’s PID. You might get errors in which case for each PID try the following until you don’t get an error. You can always run the lsof command again to see if the process really died.

kill [PID of process]
sudo kill [PID of process]
sudo kill -INT [PID of process]
sudo kill -KILL [PID of process]

Update: So it seems sometimes lsof will just hang… I don’t know what to do in this case, hopefully I will update again with further solutions.

Use ssh to kill single, unresponsive application instead of rebooting entire machine

Thursday, August 13th, 2009

Below is a way to avoid restarting you Mac/Linux machine just because one application has frozen the graphic user interface (by killing just that one app).

Script Editor on my Mac OS X machine froze my machine, freezing not just Script Editor but the whole Graphic User Interface of my Mac.

Luckily I had Remote Login enabled (Go to System Preferences > Sharing and make sure “Remote Login” is checked) and I knew my local ip address.

System Preferences Sharing Window

You can find your local ip address at the bottom of the same window above.

System Preferences Sharing Window

So I used a terminal shell on my girlfriend’s computer to ssh tunnel into my frozen machine and kill Script Editor. Opening on my girlfriend’s machine I issued:

ssh [username on my mac]@[local ip address]

Then after agreeing to the RSA fingerprint and entering the password to my Mac. I simply issued:

killall "Script Editor"

Change "Script Editor" to the name of whatever application is freezing your machine. You can issue the command:


to see running processes.

Note: You must have ssh enabled before your machine freezes.
Note: If killall doesn’t actually kill the application in question, stronger kill levels exist.

How to kill ruby on rails WEBrick server daemon

Friday, July 24th, 2009

I have been running a rails app on a machine, which I can’t restart (no root access) or physically pull the plug on, just using the prepackaged rails server, WEBrick. But I quickly found out that it was not that easy to kill my app. I’d run something like script/server -d -p 25000 > /dev/null .
Notice that -d puts the server in daemon mode and > /dev/null sends all the standard out to /dev/null .
I tried to kill the app using top and then killing with the process ID, then tried pgrep and kill on the command line, to no avail.

Finally I found the (simple) solution that I’ll repost here. On the command line of the machine running the server:

pgrep ruby

This will give you the process id of the rails app (assuming you don’t have another ruby app running). Note: if pgrep is not available on your machine try using the command:


and look for the id of a process called ‘ruby’.

Now kill that process using the command:

kill -9 [id]

Where [id] is the process id given by pgrep.

It seems kill -9 may be jumping the gun and perhaps you ought to be safe and follow the advice I found elsewhere.
I’ll reiterate his point here. After finding the process id using prgep issue the following commands waiting five seconds before trying the next one until the kill succeeds:

kill pid 
kill pid
kill -INT [id]
kill -INT [id]
kill -KILL [id]
kill -KILL [id]

Notice that -KILL is the same as -9 .