On Wed, May 16, 2001 at 10:47:55PM +1000, Luke Mewburn wrote:
> On Wed, May 16, 2001 at 04:50:01AM -0700, John Nemeth wrote:
> > On Aug 25,  7:48am, Luke Mewburn wrote:
> > } 
> > } Module Name:	basesrc
> > } Committed By:	lukem
> > } Date:		Wed May  9 16:41:00 UTC 2001
> > } 
> > } Modified Files:
> > } 	basesrc/etc: rc.subr
> > } 
> > } Log Message:
> > } * change wait_for_pids() to spin forever (rather than just ~ 65 seconds).
> > } * change the default `stop' case to wait_for_pids after kill $sig_stop.
> > }   this means that "/etc/rc.d/foo stop" won't return until the service
> > }   has shut down. third party scripts that implement their own stop mechanism
> > }   should offer this functionality as well.
> > } * in the default restart case, don't bother doing `$0 poll' in between
> > }   stop & start, because of the change above. (XXX: deprecate poll ?)
> > 
> >      Yuck!  I really don't like this change.  This is one of the things
> > I hate about SysV.  I have seen too many cases where some service fails
> > to stop and hangs the shutdown process.  Murphy's Law means that
> > usually you are far enough along in the shutdown process that you can't
> > recover and have to hit the "big red button" which leads to problems
> > with things like corrupt filesystems.  Processes that don't die within
> > a reasonable period of time should be killed with extreme prejudice.
> > If you're going to go this route, then you should at least make the old
> > behaviour an option.
> 
> There's nothing stopping you from hitting ^C to interrupt the wait
> whilst rc.shutdown is running that script.

Oh, great, so I have to hit ^C on the console to get the system 3,000
miles away at which I typed "shutdown -r now" over the network to shut
down.

This is completely stupid.  Note that our init takes care to *not* cause
this problem, and always has -- you don't give arbitrary user processes a
veto about whether the system is being halted or not, that's asking for
trouble.

And, all too often, finding it.