The Linux distillery
Bringing the world of Linux to you, David cuts through the tech and shows you how it works and how to use it, in terms that apply to any distro. RSS
Technology news and Jobs arrow The Linux distillery arrow Dawn of the Linux dead
Dawn of the Linux dead E-mail
by David M Williams   
Monday, 25 February 2008
In the examples given previously, a number crunching process would always be in the Running state. It is always wanting to perform some work and isn’t sleeping or blocking due to input or output (I/O). You can see the state of all your processes through the ps command with the –o option; this specifies a list of fields that ps should display for each process. For instance, ps –o pid,state,cmd displays the process ID, process state and executed command for every task.

You’ll see some of your processes are in state S, ie they are sleeping but are interruptible. If the process receives a signal – like CTRL/C or kill -9 – then it will respond and quit. Pretty much anytime your code is sleeping or is blocking because it is waiting for input or output it will be interruptible.

Uninterruptible sleep is used when kernel code, mostly device drivers, decides the process dare not be disturbed while an operation is taking place. Imagine the damage if you could interrupt a piece of code to debit funds from one bank account and credit them to another; you could conceivably have the debit but not the credit. The complete operation has to succeed.

Alternatively, a device driver may set the state of a device and then wait to get a response back from it. If this could be interrupted the state of the device may change before the process wakes to read the response which will no longer be relevant or valid. This activity has to be guaranteed to run as a complete transaction – and hence the use of uninterruptible process states.

Uninterruptible states are only transient; a process doesn’t live in that state from startup to shutdown. Instead, the driver invokes this state for short durations during critical moments where it must guarantee it finishes what it started.

You can see uninterruptible states in action if you perform a long operation on a slow device. The CD-ROM drive comes to mind; execute a command like
dd if=/dev/cdrom of=/dev/null &
which copies the entire contents of a CD into the null device (so it doesn’t actually save anywhere, or take up disk space.)

Run this ps command periodically
ps –C dd –o pid,state,cmd
and observe how the process state of the dd command changes over time. You should see it enter uninterruptible sleep – or state D – periodically.

Note carefully that for all the good reasons behind uninterruptible states they may be a dangerous thing: if you insert a faulty CD, or your CD ROM is damaged, it’s possible a badly written driver could try to read from the device and not think to timeout after a certain period without a response. As the media or hardware is damaged, the process never gets a response. The user is left wondering why the process is stuck and why it can’t be killed or woken up in any way at all. The only option is to reboot the computer.

And now for our title feature, zombie processes. This isn’t just the type of beastie in a B-grade horror movie but is an actual recognised Linux process state.

Like its namesake a zombie process is neither alive nor dead. It doesn’t consume any memory or take up the CPU. It does, however, show in the output of the ps command.

Where does a zombie process come from and is there anything you need to do? Please read on.

CONTINUED







 
< Next story in category   Previous story in the category >
iTWire user statistics Visitors last 30 days
Suscribers
904,266
13,751
#1 independent technology news advertise here
  •   *  
  • Search
  • AdvSeach
  • Login
  • Events
  • FreeStuff
Subscribe to our free e-newsletter