Xref: utzoo comp.unix.questions:6792 comp.unix.wizards:8155 comp.unix.microport:563 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!rutgers!gauss.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport Subject: Re: Trouble killing processes in SysV/AT Message-ID: Date: 30 Apr 88 01:45:25 GMT References: <3950@killer.UUCP> <3951@killer.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 19 You ask about processes that refuse to die. (Calling them "immortal" confers a positive aura that is probably undeserved. Normally these processes are in a useless state, and might better be referred to as members of the "undead".) Unix, along with many other operating systems, kills processes by telling them to die. You probably envision that kill -9 invokes some code that goes through all the tables ripping out entries for the process. Unfortunately, the kernel isn't organized in such a way that this is possible. Processes may own resources, locks, mapped memory, etc. All of these have to be released validly before the process can safely be removed from the system. Thus a kill starts a surprisingly complex series of events, some of which are executed in the process' own context. If the process is in an inconsistent state, it may be unable to complete these events, and hang in the process of being killed (or killing itself). I've seen this sort of thing happen in many different versions of Unix (including various Berkeley-based Unices), and similar things afflicted TOPS-20. By definition it is caused by a bug in the kernel, typically some sort of race condition or deadly embrace.