Subject: Re: NetBSD master CVS tree commits
To: John Nemeth <firstname.lastname@example.org>
From: Ken Hornstein <email@example.com>
Date: 04/07/1996 00:51:09
>} I mean: if we are going to change to an init.d-style startup
>} process, we might as well add the common extra feature of having
>} shutdown scripts run for each "package" which was started.
> It's not a feature, it's a bug.
> I would much rather not see shutdown scripts. If a process needs
>to do anything special, it should trap SIGTERM. I much prefer the
>standard BSD shutdown method of sending SIGTERM followed shortly by
>SIGKILL, since I've seen too many problems caused by shutdown scripts.
>I.e. init calls script, which calls some program, which then promptly
>hangs for any number of reasons (i.e. system was in an unexpected
>state, NFS server unavailable, coding bugs, etc.), thus hanging the
>system in a way that only a power cycle will fix and preventing proper
>system shutdown. In my opinion, it is absolutely unacceptable for a
>user process to stop a clean shutdown.
While I agree with your last statement, shutdown scripts _do_ provide one
advantage not handled by trapping SIGTERM: you can provide some ordering
to a shutdown sequence.
For example, I run AFS over a PPP link. Both the AFS daemon and the PPP
daemon trap SIGTERM. However, AFS wants to do a tiny bit of network
I/O before it shuts down. Some of the time it makes it, other times PPP
dies first and AFS hangs the shutdown sequence for a few minutes.
Note that this is a case of the kernel hanging the shutdown process :-)
While one _could_ say this is a bug in AFS, I can think of other things
that might want to do some final network I/O before they die (database
apps might want to flush out some changes, for example). In this case,
it would be cool if we could say, "shutdown AFS, _then_ shutdown the
I think that there should be _some_ middle ground here -- perhaps putting
some sort of "shutdown timeout" into init might be the right thing.