Mike McMullin wrote:
I have a 9.3 system (fairly stock) running amsn 0.95 with the following problem. amsn crashes leaving wish running. Using ksysguard to kill the wish process (pid owner == user of ksysguard) doesn't always work, opening a terminal and using kill (pid number) doesn't work, nor does killall -e wish. Am I missing something in the kill command that would cause it to fail to kill the given pid and in killall to kill a given process by name?
'kill' is a poorly named program. It would be better named 'sendsignal' If you just run 'kill <pid>', what really happens is that the process with that ID receives signal number 15, which is SIGTERM. When a program receives a signal, the signal handler for that signal is invoked. For most signals (you can see a list if you run kill -l) that handler is SIG_IGN, which does nothing at all. For signal 15, the default handler will close down the program. But any program can replace that handler, to ignore the SIGTERM. So just because a program doesn't terminate on 'kill' or 'killall' (which is really the same thing, except you can use program names instead of process IDs) that doesn't necessarily mean it's a bug, the program could just be ignoring the signal. The only signal that can't be ignored, where the system default handler is the only one allowed, is SIGKILL, or signal 9. This signal will cause the program to be unconditionally shut down, removed from the process list, killed. There is, however, a kind of process which can't be killed even by signal 9, and that is a process in state 'D' (Uninterruptible sleep). This state means the process is currently executing a system call, and while that is going on, it can't be interrupted. If the process is in there for more than a fraction of a second or so, then this usually means it's hanging. There are many possible reasons for this, buggy drivers (or bad hardware), trying to read from an NFS or SMB server that has gone away etc etc etc, and they will all result in processes that are unkillable. There are also "processes" in state Z (zombie), which can't be killed, because they are already dead. These are processes that have exited, but they are still listed in the process table, because their parents haven't called the "wait" system call, to clean up after them (a parent's job is never done, eh :)