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