[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Faster shutdown and the ubuntu "multiuser" update-rc.dextention

"Josselin Mouette" <joss@debian.org> wrote in message [🔎] 1199470514.4357.107.camel@shizuru">news:[🔎] 1199470514.4357.107.camel@shizuru...
Ubuntu discovered this a while back, and introduced a method to avoid
calling stop scripts in runlevel 0 and 6.  It is the "multiuser"
extension to update-rc.d, and in Ubuntu packages are changed to calls
dh_installinit with '-- multiuser' as an argument to enable it.  This
add the "multiuser" argument (instead of to the "default" argument) to
update-rc.d, which go on and set up the boot sequence without
references to the script in runlevel 0 and 6.  This can be done
without such extention, and how is the topic of the rest of my email.

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.

Really. First AIUI most of the candidates for this already do something similar in their shutdown scripts. The sigkill ensures that a program which hanged in the sigterm handler gets terminated. Further, it ensures that any service that chose to ignore the sigterm signal for some
odd reason gets killed as well.

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.

Those cases are also not candidates for this.

Let’s just switch to a parallel init system, and the Ubuntu wannabees
will win their precious few seconds without risking to introduce data
corruption bugs on production systems.

While those with dependecies and complex clean shutdown procedures would benefit from such a system, the remaining cases would still be sped up slightly more by letting the later script take care of them.

On a somewhat related note, it has just occured to me that the standard GNU/Linux system design (and as far as i know, the standard UNIX design) does not really have a concept of shutdown priority. I know that Microsoft Windows does have some meathod of indicating a higher than normal priority shutdown (useful for things like autoshutdown when the UPS indicates that it is running out of power). Should a similar sytem of some kind be implemented in Debian GNU/Linux?

Reply to: