Subject: Re: CVS commit: basesrc
To: John Nemeth <firstname.lastname@example.org>
From: Luke Mewburn <email@example.com>
Date: 05/16/2001 22:47:55
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,
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...