Unkillable processes?

[Jerry Feldman]

On Sat, 25 Feb 2006 10:40:19 -0500
Bill McGonigle <bill at bfccomputing.com> wrote:

> On Feb 25, 2006, at 08:15, Jerry Feldman wrote:
> 
> > This will almost always work, especially with zombie processes.
> > What you are doing is transitioning into single-user mode.
> 
> Any idea what the underlying mechanism is that makes this work?
First, the kill(1) command calls the kill(2) system call with very
little else. 

In Unix and Linux there is effectively a process tree.
The /sbin/init(8) command is always process number 1 and is "The Mother
of All Processes". When you boot into run level 1 (Single User Mode)
there should be no daemons running, and no file systems mounted other
than root, unless you manually mounted them. The only other user user
processes running are generally those associated with the superuser. 
(There will be some kernel processes running, but those show in square
brackets "[kthread]".

When your system transitions into multi-user mode (either run levels 3
or 5), a number of daemon processes are executed as well as some
getty's (virtual terminals). When you start a process from your shell,
that process inherits not only that shell's environment, but it's
ownership as whoever is logged in. In the GUI mode, you have the X
server running, then a display manager, then the window manager, and
when you cause a process to start it has an ancestry. When you
transition down to single user mode, the system kills everything. Most
unkillable processes tend to be locked into an effective deadlock that
is resolved when you get rid of some of the peers and ancestors. 
Transitioning to single user mode also shuts down the network. 

However, there can be cases where a process is locked in an
indefinite I/O wait. It is very rare when these occur and even single
user mode won't clear it. The most common indefinite I/O wait that I
have seen is NFS where the network of NFS server gets hosed. In this
case, going to single user will clear it. 

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20060225/8b3c25b9/signature.bin