In message <[EMAIL PROTECTED]>, writes: ... > This is very wrong. No matter what happens, a kill -9 should > kill the process. Are there any other signs of a kernel malfunction? > (You may want to reboot). If it happens again, could you supply the > versions of the kernel and of mirror?
I don't think that this is necessarily wrong. According to Maurice J. Bach in "Design of the Unix Operating System": `The kernel checks for receipt of a signal when a process is about to return from kernel mode to user mode and when it enters or leaves the sleep state at a suitably low scheduling priority. The kernel handles signals only when a process returns from kernel mode to user mode. Thus, a signal does not have an instant effect on a process running in kernel mode.' (p. 201) If a process is sleeping on some low-level I/O event that never occurs, it will never wake up and the kernel will never check for a signal on it. Therefore it will never die, no matter how often you run `kill -9' on it. (This assumes that Linux is implemented in the same way as "standard Unix", whatever that is.) I have frequently had this problem with programs that access cartridge tapes, on Interactive Unix and on SCO. The only solution was to reboot, because the process never woke up, but meanwhile it had the tape device open so that no other process could access it. If this is a correct diagnosis of the problem, the solution would have to be to develop some system call to force the process to wake up to be killed. I don't know whether any such call exists, but altering the kill() system call is probably a change with fairly major implications for the kernel. -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://lfix.co.uk/oliver Make it idiot-proof, and someone will breed a better idiot. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .