Date: Thu, 23 May 1996 11:35:13 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: sfinn@thecore.com, gpalmer@FreeBSD.ORG, gfoster@gfoster.com, questions@FreeBSD.ORG Subject: Re: runaway processes Message-ID: <199605231835.LAA07940@phaeton.artisoft.com> In-Reply-To: <199605230526.OAA07307@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 23, 96 02:56:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> When a user logs off without exiting pine the processes begin using > > >> lots of CPU and cannot be killed with -INT. Has a fix or workaround > > >> been developed for this? (Yeah, I know, don't run pine :-)! > > > > > >This is a bug in pine. Try ``kill -9 <PID>''. That should do it nicely > > >:-) There is an update to pine (if I remember), but the new version > > >may have other problems too... > > > > We have used pine 3.91 thru 3.93 and the problem persists ;-) > > > > Even rtin 1.3 950824BETA PL0 displays this behavior. > > It's not like it's not _documented_ or anything. From the read(2) manpage: > > RETURN VALUES > If successful, the number of bytes actually read is returned. Upon read- > ing end-of-file, zero is returned. Otherwise, a -1 is returned and the > global variable errno is set to indicate the error. > > The problem is that the losers who wrote the stuff never bothered to > test for this; they expect an error condition on stdin instead. > > The correct fix is for you to hunt down all the places in the offending > programs where read() is called on stdin and patch them to check for '0' > return, and then pester the maintainers and forward patches to the ports > people. > > Otherwise this will never be fixed. With respect, I *still* disagree about the interpretation of POSIX SIGHUP that resulted in this state of affairs in the first place. I believe that most programs *do* handle this problem, either by explicitly catching SIGHUP and processing it, or by taking the default action for SIGHUP, and exiting. Most mail programs are in the first category in order to restore mailboxes. You need only look at csh, tcsh, and bsch "&" processing and ash, pdksh, and bash "nohup" processing to see that child processes of the controlling process for a tty are expected to be sent SIGHUP as well as the controlling process, based on the process group (pay specific attention to the fact that signal masks are inherited over exec). That is, the signal is sent *before* the revocation takes place, not after. This is the behaviour on SVR4, Linux, SunOS, Solaris, AIX, etc.. I realize we are holier than them (8-)), but this needs to be fixed in the SIGHUP handler and the propagation of signals to process group members on gsignal() prior to revocation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605231835.LAA07940>