Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention
[Josselin Mouette]
> Frankly I couldnʼt imagine a worse idea to fix this problem.
>
> Many daemons will corrupt their state if they arenʼt killed cleanly.
> Leaving them a grace time is actually worse than simply cutting the
> power, because you can be sure the daemon is actually writing some data
> at the moment you kill it.
I am unable to understand your argument. You seem to claim that
because some daemons need a shutdown script, those that do _not_ need
a shutdown script but would work fine by just being killed should keep
their shutdown scripts, and that do not make sense to me. Daemons
without the need to update state on disk during shutdown (like for
example gpsd and xfs), do not need more than a signal to die. There
is no need to give them a grace period.
No-one has suggested as far as I can see to remove _all_ shutdown
scripts, while all arguments against removing some shutdown scripts
seem to base their argument on that premise. To repeat myself another
time:
Daemons that need a shutdown script should keep it. Daemons that do
not need a shutdown script can drop it, and leave it to sendsigs to
kill them.
The fact that there are some daemons that need their shutdown script
do not affect the fact that there are daemons that do not.
> The most funny thing comes from daemons which depend on each
> other. You will easily hit cases where a daemon will not shut down
> properly because it cannot find the one that depends on it, and in
> the end increase the shutdown time instead of shortening it.
How will this be a problem with correct dependencies in the init.d
scripts? Scripts for daemons that need other daemons running should
stop before those daemons, and thus keep working even if the other
daemons happen to be killed by sendsigs and not by the other daemons
init.d script.
> Letʼs just switch to a parallel init system,
What do you mean here? Like sysv-rc with CONCURRENCY=shell or
CONCURRENCY=startpar, or something else?
> and the Ubuntu wannabees will win their precious few seconds without
> risking to introduce data corruption bugs on production systems.
As far as I can see, nothing I have proposed increases the risk of
data corruption, so I fail to understand your comment.
Happy hacking,
--
Petter Reinholdtsen
Reply to: