When Kill dosen't work 4341

In a message on Wed, 03 Aug 2005 07:10:44 -0400, wrote :

As was stated in another poster's response, there are many conditions, including low-level driver state, external hardware (or remote systems in the case of NFS), that the kernel only has limited 'control' over. To properly delete a process without leaving dangling data structures, etc. the kernel needs to know about all of a process's state and have control over a process's state. When a process is in state D, this means that some of the process's 'state' is probably under the control of a part of the kernel (such as a driver module) that is outside of the main part of the kernel (the part that would be involved with killing the process, for example). Typically, there is a flavor of 'critical section' that cannot be messed with until it completes. *Normally*, buttuming perfect hardware (and perfect NFS servers), processes never sit in state D long enough for most users to even notice this state with ps and only rarely with top... But then hardware breaks down: often this problem occurs with dirty, scratched, etc. media (floppies, zip carts, CD-DVD-ROMs, tapes) or with network problems with NFS and SMB servers. I've rarely needed to re-boot when these things happen, most often with NFS -- local SCSI problems timeout or run out of re-tries within a 'reasonable' time frame, even when I managed such dumb things as pulling the power cord out of a SCSI Zip drive and losing termination of the whole SCSI bus on a SCSI based machine.