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.

In the case of a system shutdown running /etc/rc.shutdown, the only
things that actually get run by default are: cron, inetd, xdm,
and /etc/rc.shutdown.local.

In the case of a manual restart of subsystems such as amd (and
third party stuff like squid) actually works more reliably, because
you know things have been shutdown.


I've used `traditional SYSV' systems which do try and shut down
everything and have had to uncleanly shut them down because a service
wouldn't go down cleanly. I haven't experienced this under NetBSD's
rc.d system, and I've got a few local scripts that get run at shut
down time as well. And if something does play up, there's always the
terminal interrupt key...

Luke.