Tutorials 

by Dr. John Timmer, Contributing Editor

In an operating system you rarely restart, it's easy for a program to go bad and sour your experience. Keeping this from happening, however, doesn't require a trip to the command line. In keeping with this being an FAQ site, I'm going to provide an answer that's appropriate for the following questions:

How can I kill a Unix process without resorting to the command line?
Why does my machine suddenly starts acting sluggish? What can I do about this other than restarting?
How do I kill a program like the dock that doesn't show up in the Force Quit dialog?

Short answer: Most of the methods for managing processes require a trip to the Terminal, but a combination of three utilities (two of them Apple-provided) should be able to help you visually identify when something is hogging processing time and bring its misbehavior to a halt.

Long answer:

Identifying a problem.

As with many things, the first step towards a cure is to recognize that you have a problem. Sometimes this is easy: an application may stop responding to your input and show the perpetually spinning beachball. Other times, it may not be clear which application is chewing through your processor time, or the culprit may be a background process that isn't obviously running. There's always the chance that things are behaving slowly just because there's a lot going on. How do you tell whether intervention is required?

The easiest way to spot when something is misbehaving is to monitor your CPU usage. Although there are a bunch of free applications that will do this for you, I’m perfectly happy with the one Apple includes in the Utilities folder of the OS-X install: CPU Monitor. I find it's most useful to have this as a login item, with its preferences set to show the extended load in the dock. Moving from left to right in the screenshots below, you can see that most of the time, the system hums along nicely at a low level of CPU usage, although when browsing the web, loading and rendering a page will often lead to a brief spike. I know things are wrong when things max out and stay there, like in the right image.

Finding the culprit.

Okay, so something's gobbling up processor time, even when you're not doing anything. How do you find out what? Here's where the next utility comes in: Process Viewer (also residing in the Utilities folder). When you launch that, it'll bring up a list of everything that the system knows is running. Best yet, it lets you sort and filter that list. Since we're wondering what's taking up our processing time, we can click on the header of the CPU column to sort the processes based on that value. This makes it easy to see what the top CPU using processes are. Don't be surprised if Process Viewer itself starts out on top of that list - its first sampling came while it was busy launching itself. If you wait until it samples things again, it should drop down to a more reasonable amount. Whatever comes to the top of the list instead will probably be the process that's causing you grief.

Filtering is useful if you have a hunch as to what's causing your problems: by typing part of that processes' name in the "Find" box in the upper left corner, you'll be able to focus your search in on some likely troublemakers.

(Some of) The Usual Suspects.

Sherlock's Content Indexing. Each time Sherlock is launched, it starts a process that indexes all your selected folders (even if its last launch was 2 minutes earlier). Because I have both my home folder and all the developer documentation set to be indexed, this can take quite a while. During that time, the indexing gobbles an enormous amount of processing power. Note that stopping it is probably not the best of ideas, even if it is annoying.

Classic. Even though Classic is an impressive feat of software engineering, it's far from perfect. When things go wrong, a frequent symptom is runaway processor usage. Even when things are working well, some Classic programs simply hog the processor. I've even had situations where Classic appeared to crash, and OS-X let me boot it again. Suprisingly, I found that the original version was still going berserk in the background.

Carbon Apps. Just because your favorite application's been Carbonized, it doesn't mean that all the bugs that plagued it have magically disappeared. Now, instead of locking up the system, some of these bugs can cause the application to chew through processing time. Unfortunately, all of these wind up in Process Viewer under the same name, "LaunchCFMApp", and it's hard to tell which of these you're going to have to force to quit. If you've got unsaved work, it's best switching between all your Carbon applications and saving it before trying to quit anything. It may be that the rampant application won't allow you to save, thus helping you identify it.

Killing the bad one.

Now that you've identified which process is causing you trouble, it's time to bring it to an end. The standard mechanism for killing a program remains the command-option-escape key combination, which will let you pick a program to kill. Alternately, you can control-click its icon in the dock, bringing up a menu that includes "Quit". Holding option down option key at this point changes that to "Force Quit."

Since you've already opened up Process Viewer, though, you might as well use that to kill the misbehaving program. Simply double clicking that program in the list will bring up a dialog that allows you to shut the program down. This is especially useful when you've got a host of Carbon apps while only one is misbehaving, or when the bad one is not an application, but rather a background process (more on that below). Finally, it's worth mentioning that logging out should kill all the processes you've started since logging in, and rebooting will definitely shut everything down.

Getting rid of background processes.

As mentioned above, some processes that can gobble up your processor are background applications, so they don't show up in the dock or the force-quit dialog. Process Viewer will allow you to identify these, but it will only let you kill some of them. That's because many of the background processes were started by the OS itself, and thus inaccessible to a mere user such as yourself. Fortunately, Process Viewer includes a column for "User", to let you know if you started it. If the User entry for a process matches your login name, you can kill it. Do note, however, that killing some of the more significant background processes (WindowManager comes to mind) will effectively log you out. If you can't identify what a process you own does, it's probably safest to log out in order to kill it.

This is even more true of the process is was launched with a user of "root" - rather than just ending your login session, killing one of these can make the entire OS act flakey or bring it crashing to a halt. For this reason, you can't kill one of these processes very easily. Far and away the safest thing to do is to reboot your computer if one of these has gone bad.

But we're not using OS-X because we like rebooting, right? If we know that the OS can live without a process running, or know how to restart the process after killing it, it may be worth killing a root process. Although you can use some cryptic Unix commands to do so, a more visually pleasing way is to launch Process Viewer as root, the superuser, which then lets you kill any process owned by root.

Accomplishing this is where the third utility comes in, Pseudo from Brian Hill. Currently in beta, this application will let you launch anything, including Process Viewer, as root. To do so, simply drag Process Viewer's icon onto Pseudo's icon in the Finder. When you let go, Psuedo will launch and ask for an administrator password. After filling that in, Process Viewer will launch, this time with root privileges. From there, any process on the system can be killed.

When used carefully, these utilities can keep your system running well for longer between re-boots.

PS - Pseudo is shareware - don't forget to reward its author for his work when it comes out of beta.

If you have any questions or comments about this article, feel free to e-mail me at john_timmer@osxfaq.com