Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!fu-berlin.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!fauern!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: killing persistent processes Date: 3 Oct 1995 16:14:59 +0100 Organization: Private FreeBSD site, Dresden. Lines: 28 Message-ID: <44rk1j$cv8@uriah.heep.sax.de> References: <44p48a$c11@atlantis.utmb.edu> NNTP-Posting-Host: uriah.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit M. L. Dodson <bdodson@beowulf.utmb.edu> wrote: >Question on killing processes which are hung, but have resources locked (this >on 2.0.5R): > >I was doing a dump to my floppy tape when it aborted with an "unexpected >interrupt" message. I flipped over to one of the alternative consoles and >tried to kill the dump. The ft process wouldn't die. And I couldn't rerun >the command because ft had /dev/rft0 locked up. Had to reboot the machine >to recover. Now this isn't a problem on my home machine, but I'd like to >bring up some production machines at work with FreeBSD. My question is how >to kill processes like this without a reboot? You cannot. Signals are delivered to processes only at the transition from kernel to user mode. If a process is hanging inside kernel mode (e.g. in state "D" as shown by ps(1) -- uninterruptible disk wait), the signal will only be scheduled for later delivery, but since the system call apparently never returns, it won't be delivered at all. This is generally an indication of a bug, e.g. in your case with the ft driver. For a production machine, don't use ft-style tapes at all. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)