Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!EU.net!Germany.EU.net!zib-berlin.de!news.tu-chemnitz.de!irz401!uriah.heep!not-for-mail From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Non dying process. Serious? Date: 12 Nov 1995 14:36:28 +0100 Organization: Private FreeBSD site, Dresden. Lines: 42 Message-ID: <484t8s$jlt@uriah.heep.sax.de> References: <47oe90$mhh@news.bu.edu> NNTP-Posting-Host: uriah.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mikhail Teterin <mi@bu.edu> wrote: >For a while I had the idea that `kill -9' must kill -- it is a signal >handled by the OS, not by process. I'd recommend you the ``Daemon Book'' (``The 4.3BSD Operating System. Design and Implementation.'') It explains in great detail the signal delivery. Basically: signals are being delivered on the transition of a process from kernel to user space. So if a process is being killed but is currently executing a syscall, it will see the signal only on return of the syscall. If the syscall is never returning, the process will hang around forever. This is usually a bug inside a driver. (And no: this has *nothing* to do with zombies. Zombies are dead processes [i.e., they have been exiting] where the status has not yet been fetched by the parent. You never need to reboot to get rid of zombies, killing all successive parents until the zombies are away should suffice. At least, the parent of all parents [init, pid 1] should always clean up zombies.) > Well, ppp will not die. The way to achieve >that is simple -- specify wrong memory address for the COM-port of >interest. In my case, kerenl did not detect my mistake, reporting presence of >the COM port. Well, but *that's* strange: the sio driver is performing one of the hardest checks for the existance and proper functionality of the hardware. It's even known to fail on some lousy internal modems, since they do not fully emulate the specified semantics of a 8250 UART. (And sio is actually the only driver in ISAland that has got a chance of asking the device to issue an interrupt: the COM port can be told to loopback itself.) Are you pretty sure this misdetection happened with a standard, unhacked sio driver? If so, Bruce Evans would certainly like to know from you (bde@freebsd.org). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)