Newsgroups: comp.unix.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Subject: Re: Writing a program that cannot be killed except by reboot
Message-ID: <1991Apr15.013235.18807@athena.mit.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
References: <444@wrdis01.af.mil> <1991Apr14.200931.17551@aplcen.apl.jhu.edu>
Distribution: na
Date: Mon, 15 Apr 91 01:32:35 GMT
Lines: 23

In article <1991Apr14.200931.17551@aplcen.apl.jhu.edu>, akbloom@aplcen.apl.jhu.edu (Keith Bloom) writes:
|> mcgough@wrdis01.af.mil (Jeffrey B. McGough) writes:
|> >Is there anyway to block ALL signals to a program so that it
|> >may not be killed by kill???
|> 
|> I've seen situations in which the program is trying to write to some
|> device like a network socket or parallel or serial port, and there's
|> something wrong with the connection.  In this case, it frequently
|> happens that even kill -9 won't work; rebooting is the only thing *I*
|> can think of to do when this happens.  I suppose a program could do this
|> deliberately.

  While the program is hung in the device driver, it is running in the kernel,
not in the user code, which means it can't do any work at all.  I don't see
much use for a process that can't be killed but can't do any work either.  The
second the device driver exits and the program is able to work again, it can
be killed.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710