A beginner’s introduction to the GNU/Linux command line, Part II—Managing processes

A tutorial for novices that discusses processes and process related commands including ps, top, grep, fuser, more, jobs and kill.

Short URL: http://fsmsh.com/2099

Rosalyn Hunter
2007-07-11
User space | Easy
0 Up Down
Tags: command line, processes

Your GNU/Linux computer is an amazing machine. It can display images. It can run programs. It can perform dozens of functions all at the same time. How can you keep track of all this activity? By monitoring the processes that your computer runs, and one of the best ways to monitor and control processes is by using the command line.

Long ago computers were like calculators—they did one thing at a time—but today’s computers can multi-task doing hundreds of things at the same time. The different tasks share processor time. This is why you can search the web while writing a paper and listening to music all on the same computer at the same time.

What do you do when you can’t make your process stop no matter how many times you click that little `x` in the corner?

Each of these different things happening on the computer is called a “process”, and your computer takes turns letting all of the processes run a little bit at a time. The computer works so fast that you usually don’t even notice.

But occasionally, a process stops responding to you. What do you do when you can’t make your process stop no matter how many times you click that little x in the corner? You try using the keyboard commands Esc and Ctrl + C. You even try Ctrl + Q, Ctrl + X, and Ctrl + Z; but they don’t work. What do you do next?

If you can get into a terminal, you can kill any process

Well, if you can get into a terminal, you can kill any process. The command is called kill. The command name is easy enough to remember, but your problem is knowing what to kill. Each process has a different process identification number (PID) and you must use that number to kill it.

To see a list the processes currently running on your system, you can use the command ps. If I open a terminal program and type ps now, I will see this:

rosalyn@onizuka:~$ ps
  PID TTY          TIME CMD
14036 pts/2    00:00:00 bash
14040 pts/2    00:00:00 ps

(The prompt on my system says rosalyn@onizuka:~$. Needless to say, your computer will say something different. When I show an example like this, only type the words after the dollar sign. The computer’s response will be shown on the following lines.)

The computer responds telling me what processes I am currently running in this terminal window. First, I am running the terminal window itself using the BASH shell. Then I am running the command ps. That’s not very informative. Is it?

I would really like the computer to show me all of the processes running on my system. To find that, I must use options (letters typed after the command that modify its function). In order to see all of the processes running on my system, I use the ps aux command:

rosalyn@onizuka:~$ ps aux

ps reports a snapshot of the current processes running on your system.
a tells the computer to show all processes
u tells the user name of who owns the process, and
x lists processes that were not started in a terminal.

This command will return a long list of processes that scrolls off my terminal screen. Somewhere in that list is the process ID that I am looking for. If I am using a terminal with a scroll bar, I can just scroll back up and read it all to find the process. Personally, however, I prefer to use a different command to get the process ID. The command called top.

Tasks and processes

What’s the difference between a task and a process? Nobody knows. For the most part people use the word task when they are talking about sending things to the processor to avoid saying things like, “the processor processes the process”.

Well, actually, there is a difference between tasks and processes. The process that starts your computer is called init. It is listed by the process ID 1. This process is also called Task [0]. For the most part, however, just consider tasks and processes to be the same thing.

Top lists the processes using the most time on the computer’s processor. It prints only what will fit in your terminal window, and it refreshes every few seconds to give you an up to date picture of your system. If your program has stalled, then it is probably taking up lots of processor time, and it will be right near the top of the list. Typing top on my system shows me this:

top - 00:15:36 up 10:53,  1 user,  load average: 0.79, 0.69, 0.58
Tasks:  86 total,   3 running,  83 sleeping,   0 stopped,   0 zombie
Cpu(s): 29.9% us,  6.6% sy,  0.0% ni, 62.8% id,  0.0% wa,  0.3% hi,  0.3% si
Mem:    484292k total,   361820k used,   122472k free,    25596k buffers
Swap:  1421712k total,        0k used,  1421712k free,   169384k cached

  PID   USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  13247 rosalyn   16   0  155m  67m  46m R 26.3 14.2  11:58.69 seamonkey-bin
   3363 root      15   0 93448  50m  44m S  9.0 10.6   6:05.50 XFree86
  14032 rosalyn   15   0 27320  14m  25m S  1.0  3.0   0:02.04 konsole
  13227 rosalyn   15   0 14168 9928  11m S  0.7  2.1   0:09.65 gvim
   3094 gkrellmd  15   0 18824 1340 2240 S  0.3  0.3   2:24.32 gkrellmd
  13207 rosalyn   15   0 26532  14m  23m S  0.3  3.1   0:01.69 kdeinit
  14196 rosalyn   16   0  2104 1084 1888 R  0.3  0.2   0:00.11 top
      1 root      16   0  1516  520 1364 S  0.0  0.1   0:00.58 init

If you lengthen the terminal window, it will show more data. Now, suppose the program “seamonkey” was frozen. I could kill it by typing the command kill followed by seamonkey’s process ID 13247.

Of course, to do this I need to get a prompt again. Top will keep refreshing in the terminal window until you tell it to stop. Both the letter q for quit and typing the control button and c at the same time (Ctrl + C) will stop the program and give you back your prompt.

To kill seamonkey, I can type:

rosalyn@onizuka:~$ kill 13247

This should stop the process causing the seamonkey window to close, but sometimes it doesn’t. What do I do if seamonkey still won’t close?

Well, kill also has options. The basic command tries to be nice. It says, “Could you please stop now?” But if the process just won’t die when you ask it nicely, then use the option -9. The command kill -9 says “take no prisoners!”

Write a full post in response to this!

Do you like this post?
Vote for it!

Copyright information

Verbatim copying and distribution of this entire article is permitted in any medium without royalty provided this notice is preserved.

Biography

Rosalyn Hunter: Rosalyn Hunter has been on the internet since before the web was created. Born into a family of instructors, she has made it her life's goal to teach others about the important things in life, such as how to type kill -9 when a process is dead. She lives in a little house on the prairie in the American West with her husband, her three beautiful children, a cat and a dog.

Login or register to post comments
58975 reads
Printer friendly version (unavailable!)

Very nice article.
In the part about killing processes, what if "Ctrl+C", "Ctrl+X", "kill 13247" and "kill -9 13247" don't work? I've had this come up a few times where I cannot seem to get rid of a process this way. Then you just have to really wait on it to finish or respond. (And this is attempted as root). Is there even another type of command to run?
Thanks.
------
let's all play nice!

Did you try CTRL-Z? I've had a few rare cases where it didn't work to kill the process, but it worked to suspend it (with CTRL-Z). Now you usually can kill it, but there may be cases where even this won't work.

Cases where the "kill -KILL" (equivalent to "kill -9") won't work usually occurs because the program is accessing a network drive that has gone offline, such as an NFS share. In those cases, the only way to kill the program might be to reboot the computer, or at least bring it into single-user mode and back, so that all network shares are forcibly unmounted.

Other than Slay, I can't think of a more powerful way to kill processes right now.
If it is that persistent, I usually reboot. Sometimes that is the best way to solve hardware dependent problems.

-Rosalyn

Ok, thanks. Rebooting isn't usually an option as it's a server (usually). But yeah, it's not so often though, just once in a while.

------
let's all play nice!

For what it is worth, one should NEVER skip directly from kill (-15) to kill -9.

The process is:

kill $PID
wait a few seconds
kill $PID
wait a few seconds
kill -2 $PID
wait a few seconds
kill -1 $PID
wait a few seconds
try to figure out why the process is not dying correctly
kill -9 $PID

One should never ``kill -9'' a process unless you have found that it is trying to close a file descriptor on a non-responsive filesystem or other type of issue that is actually causing it to not clean up properly.

If the same process is frequently requiring a ``kill -9'' then one should figure out why it is not dying correctly and switch to a different program if it can not be corrected as the process is experiencing some serious issues.

At one time there was a ``Useless use of kill -9'' award given out on Usenet for those System Admins that do not know what they are doing. As *NIX is gaining more and more popularity we are seeing many more people just using kill -9 like it should be default. There is a reason that a process should be given a SIGTERM, SIGINT then SIGHUP. The reason being that programs are written to where they catch these signals and perform cleanup processes. A SIGTERM will typically tell the program that the user wishes for it to go ahead and close all file descriptors after telling it's children(if child processes have been forked) to close up shop. A SIGINT is then used to Interrupt the program from whatever it is doing and close up shop. A SIGHUP, commonly rebound to re-read the configuration file, is a Terminal Line Hangup which should, by default, tell the program to not wait for children to respond via their pipes and just close the file descriptors and die. The evil SIGKILL tells the process to just die and not worry about what it might have been doing. SIGKILL can leave ZOMBIE child processes and ghost logins.

eg: If you were to ``sleep 9999& kill -9 $$'' then you may notice that you will often have a ghost login AND the sleep process will still be alive after your shell is dead. If, instead, you were to issue that as ``sleep 9999& kill -1 $$'' then you will find that there is no ghost login and the sleep process should have been reaped by your shell as it exited cleanly.

On a side note: one does not have to quit from ``top'' in order to kill a process. Simply pressing 'k' while viewing top will prompt you for the PID(and signal depending on the OS and distro.) One can perform many actions from within ``top'', just press 'h' to see the different shortcuts.

Thanks for your more detailed insight into Killing processes.
I wonder what Xkill does?

If I want to tell my computer to show me a process, could I actually enter the command SHOW PROCESS. Or how about the whole system, like SHOW SYSTEM? In a cluster, can I just enter SHOW CLUSTER? How about a plain HELP? Can this be done or are computers today as primitive as they were in the late 60s, when people had to deal with 2-letter commands like "ps"?
Hey, I asked my system manager these questions, and she said on Linux the HELP command is called woman. When I replied that his is weird, she said progress was made when an operating system called MSDOS was introduced which had at least the HELP command. Now, how about the rest?

I wouldn't really call something primitive just because it has a two letter command.

Anyway, if you really want specialized command names, you can always try scripting them. You can make short files called scripts that when you run them by typing their name, initiate a long command for you. In that case you could do ps with lots of options added and formatted the way you like it when you type SHOWPROCESSES. I don't think you can have a space in the command though.

About the woman command.

I see no sign of it. I think it must be a joke.

Anyway, thanks everyone for the comments. If you find any other good ones. Post.

Thanks Rosalyn

You don't even have to script anything, you can simply alias them.
So if you want SHOWPROCESS to do "ps aux" in bash, you type "alias SHOWPROCESS ps aux".
Now, in this terminal, every time you'll type SHOWPROCESS, it will do "ps aux".
If you want to have that possibility in every terminal you open from now on, just add "alias SHOWPROCESS ps aux" to the file .bashrc in your account.
Also, short command names are still used of efficiency. It's a LOT faster to just type "ps" or "ps aux", than to type SHOWPROCESS.
And for the "help" command in linux/unix, either you misunderstood, or your are making a bad joke. The command is "man", as in manual, followed by the command you want help with.
For example, you could type "man ps", and it would give you an explanation about the use of "ps", it's options, it's peculiarities...

#!/bin/bash
if [ $1 == "PROCESSES"]
then
ps aux
fi

put that in a file named SHOW in /usr/local/bin and chmod +x /usr/local/bin/SHOW
then you can run SHOW PROCESSES
but it is faster to write ps aux than writing SHOW PROCESSES

'help' works on my system as does 'help ls' ('help' basically does 'man help' and since 'help' is a hardlink to 'man', 'help ls' is the same as 'man ls'). Of course this is BSD *nix, not Linux where the default bloated ass shell (bash) has a built-in very unhelpful 'help' command.

And yet, Linux is the predominant open source operating system.

I would add one more useful command to the list: killall. killall lets you kill a program directly if you know the name of the binary. For example:

killall akregator

will kill all instances of Akregator.

xkill turns your mouse pointer into a skull and crossbones, whatever window you left click on gets "run through" so to speak. Right click to return to a normal mouse pointer.

where is Part I of this article??

Here is Part 1.

If kill and slay dont work, there is always SysRQ. That strange little button sharing "print screen" is actually an access to several very powerful, low level kernel interrupts. The good news is that SysRQ commands cannot be denied by the system. The bad news is that it must be enabled both during compile, and in kernel.sysrq additionally, the potential for harm is much greater than that of kill -9, but IF your server has it enabled, and all else fails, its worth a try.

Wow!
I never heard of SysRQ. I'm gonna have to look that up.

Sounds like the tip of a long series of programmer tools or something.
Thanks for the comment.

-Rosalyn

I found something about sysRQ. It's really old. I felt embarrased that I didn't know it when it is printed on my own keyboard!

I found a really nice wikipedia page on this function.

http://en.wikipedia.org/wiki/SysRq

Gary Richmond actually just posted a blog article about this yesterday.

There's no shame in not knowing about ALL those PC BIOS level interrupts - I'm not sure they're even all properly referenced (except in those old 1979 Intel datasheets...)
Those keys shouldn't work with:
- PPC Macs
- Intel Macs (use EFI, not BIOS)
- Alphas
Or do they?
---
A computer is like air conditioning: it becomes useless when you open windows.

I'm still using Debian but now it's Etch instead of Sarge and I'm happier than ever with it. Etch is substantially more user friendly than Sarge and still works beautifully on older hardware.

I love the way you write. I read Part II all the way through without my eyes glazing over. I doubt if any of it will stick, because that's how my strange brain works, but the first time a process hangs up and can't be shut down I'll remember this tutorial, revisit it (even if I have to change computers and google for it), read it again and apply the information. Then I'll remember it.

I hope you'll continue this series. I want the book when it's printed, or, if it's an eBook I'll buy it and print it myself.

I'm still a Wannabe Linux Geek (and still in training)

Don Crowder

Instead of 'ps' use 'pgrep -l '. Example, try 'pgrep -l firefox' when running firefox. You will see the PID as well as the name of the program (ie. firefox).

Instead of wasting time remembering stupid numbers, use pkill . Example, with firefox running try typing pkill firefox. This will TERM-inate (signal 15) firefox, without having to remember stupid numbers.

(YMMV. Works on opensuse. I haven't tried this on other distros)

I did not know about pgrep (so thanks for that tip). But when I read your post I did 'man pgrep' and it comes up with a man page for pgrep _and_ pkill - so your 'most used' would be shorter as 'pkill firefox'.

fuser -k /path/to/program

this will kill the program that you named along with any forks that the program may have initiated.

fuser -k `which gcc`

kills every instance and any forks

This guide is good I guess but to REALLY kill some stuff, just type:
[dangerous command that could destroy your system, edited]

Hi,

This comment shows that it's a good idea to moderate comments, ALL the time, no matter how many you have.
I just cannot believe some people.

Anonymous user: I hope you realise that your IP address was recorded on the server.

Merc.

And people wonder why the Linux community has such a bad reputation. Thanks to people like you, new users are afraid to take advice from us seasoned users. Hopefully nobody used that command and lost data.

Hi,

Well, I reported the hell out of him.
He was from a .mil domain (!). So, hopefully somebody will get seriously told off about it.

Luckily, the community also "works" :-D

Bye!

Merc.

This article while helpful actually made the process more difficult than it has to be.

There is a nice little command called "xkill" that works easily. You either bring up a run dialog box or open a terminal program, then just type "xkill" and hit enter. You will notice your cursor has changed to normally a skull and crossbones, click on the frozen application to be killed and left click on it. It should die very quickly. Done.

I only use the standard "kill" command if I am running apps from the command line ( I'm rarely ever there...) and one froze.

1) This is an article about the command line, and xkill is an x application (albeit a small one).

2) Sometimes there is no window to xkill.

3) Sometimes there is a window, but your xserver is locked up so the mouse won't do anything or you can't get the application menu to come up (And yes, I have encountered systems where X is locked up, but virtual terminal switching works, and killing the offending process frees up the X session).

4) Sometimes the whole console is locked up, but you can remote login via SSH and kill the offending process to fix things (i.e. from another computer). I suppose it's a bit counter-intuitive that SSH often works even when the console is completely locked up, but it is often true.

Hi Rosalyn,

Very nice written article! Thank You!

By the way if anyone is interested, most of these commands will also work in a terminal window on OSX, which uses BSD.

I am not sure why people are afraid of the command line. Once you get used to it, it's really great. Last night I installed a new application on my Xubuntu box. I could have used the GUI installer, but it was easier and quicker to use apt-get.

Kill -9 no more cpu time
kill -9 and your process is mine

Nice !
I learnt a couple of things I didn't know =)

Hi,
Enjoyed your article! Thanks

But in my mind’s eye I can hear some veteran command line user out there scoffing. “Ha!” he says, “I could do all of that in one line.”...

Quite an amazing eye - perhaps that should've been "mind's ear" ;o)

Good article though. Well done.

Ryan

Best voted contents

Special 301: FOSS users. Now we're all Communists and Criminals
Gary Richmond, 2010-03-05
Microsoft's Internet Driving Licence: stupid, unworkable and unenforceable
Gary Richmond, 2010-03-10
The Bizarre Cathedral - 69
Ryan Cartwright, 2010-03-12
Interview: Nina Paley (author of "Sita Sings the Blues" and the two "Minute Meme" animations)
Terry Hancock, 2010-03-15

CariNet: Cloud computing is a reality.

Buzz authors

Free Software news

Other sites

The Top 10 Everything (Dave). The good, the bad and the ugly.
Free Software news (Dave & Bridget). All about free software -- free as in freedom!
Book Reviews: Illiterarty (Bridget). Book reviews, blogs, and short stories.

Hot topics - last 60 days

Linux performance: is Linux becoming just too slow and bloated?
Mitch Meyran, 2010-01-26
Web code is already open - why not make it free as well
Ryan Cartwright, 2010-01-20
Save "Sita Sings the Blues" from the Flash format: can you convert FLA?
Terry Hancock, 2010-01-29
Microsoft's Internet Driving Licence: stupid, unworkable and unenforceable
Gary Richmond, 2010-03-10
Special 301: FOSS users. Now we're all Communists and Criminals
Gary Richmond, 2010-03-05

Hot topics - last 21 days

Microsoft's Internet Driving Licence: stupid, unworkable and unenforceable
Gary Richmond, 2010-03-10
Special 301: FOSS users. Now we're all Communists and Criminals
Gary Richmond, 2010-03-05
The Bizarre Cathedral - 69
Ryan Cartwright, 2010-03-12
Interview: Nina Paley (author of "Sita Sings the Blues" and the two "Minute Meme" animations)
Terry Hancock, 2010-03-15

Odiogo

Free Software Magazine uses Apollo, project management and CRM for its everyday activities!