Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention
[Roger Leigh]
> On a heavily loaded or slow system, I suspect it would be highly
> likely some would get SIGKILL before they could shut down properly.
> I can't say I'm a big fan of the proposal for this reason.
I do not understand this objection. The only way I can get it to make
sense is by assuming that you believe my proposal is to remove most
packages init.d scripts from the shutdown runlevels, even the ones
that need special care when taking the service down. And that is not
what I am proposing. I am claiming that there are daemons around that
_do not_ need any special care when the service is taken down, and
that these daemons do not need a script in runlevel 0 and 6 to take
them down as it is faster to let the sendsigs script kill them.
Btw, if the 5 second wait isn't long enough for sendsigs, we can
extend it. There is code there to make sure sendsigs terminates as
soon as the last process it tries to kill is dead, so we could
increase the timeout without affecting the normal shutdown times. It
will wait from 0 to 5 seconds at the moment, depending on how long it
take for the processes to die. It would not be a problem to let it
wait from say 0 to 10 seconds, or 0 to 30 seconds.
> With a better init, like upstart, or a dependency-based init,
> there's no reason why scripts can't be run in parallel. But, simply
> sending everything a TERM and KILL doesn't seem do be very clean in
> my understanding.
It is already possible to run the sysv-rc system in parallel when
using the dependency information provided in the LSB headers, using
the insserv package, so there is no need to replace sysvinit to get a
better init. :)
Unfortunately, there is still a few bugs in the dependency information
provided in init.d scripts in the debian packages, so at least for a
few corner cases the generated sequence is wrong. See
<URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> for
information on the progress. Packages are fixed every day, and I hope
the provided information will be correct enough for normal desktop
installs any day now. When that is in place, I will focus on another
goal, the Debian Edu tasks, to make sure Debian Edu can switch to
dependency based boot sequencing for Lenny. I would love Debian to
switch to dependency based boot sequencing for Lenny to, and with luck
and a lot of work, it will happen. Could use some help here, though,
to get LSB headers with dependency information into the 33% of scripts
that are still lacking them, and more testers to discover and fix the
headers with bugs in their dependency information.
I got a report the other day from someone claiming to have used the
dependency based boot sequencing for a long time, and not had any
problems with it, so I guess it is approaching stable. :) But as I
said, there are still some issues with it, and I report bugs about it
as soon as I find them. :)
Happy hacking,
--
Petter Reinholdtsen
Reply to: