>} 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
network".

I think that there should be _some_ middle ground here -- perhaps putting
some sort of "shutdown timeout" into init might be the right thing.

--Ken