[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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
