I always find it dumb that rebooting a GNU system involves doing so much stuff, when the machine is going to be rebooted anyway. e.g. why deconfigure the network interfaces? It's not even getting saved, it's just volatile system state that will be destroyed by the reset. For a reboot, all you need to do is save anything that's needed, and close any files that are open for writing. You don't have to bring the system to the exact state it was in at bootup, or anything. Then you can unmount your filesystems to make sure they're in sync (including network mounts), and reboot. Some daemons that only log to syslog don't even need to be stopped, since they won't have any files open for writing. Scripts like alsa will just save mixer settings on reboot, and only unload the modules on stop. The only reason /etc/init.d scripts do so much work in "stop" mode is that they don't know whether it's a shutdown, or if you just want to stop the service (is that a bad word because MS uses it? I hope not). I suggest that when shutting down, the rc scripts should call /etc/init.d/foo reboot, and if that returns an error, try the normal stop. (Current init scripts exit 1 in the default case.) BTW, "reboot" is probably better than "shutdown", because nobody will run it thinking that it shutdown the service, when in fact it won't if it doesn't have to. This should save a lot of disk I/O when all you want to do is reboot. It would be even better if there was a way to completely avoid running some init scripts on shutdown. There are quite a few init scripts that load some settings from a config file and apply them to the kernel, e.g. hdparm to tweak IDE driver settings. These don't need to be called on shutdown, but their packages put K links in /etc/rc6.d and /etc/rc0.d. So I guess I've got two ideas here: having a reboot argument, and having a way for init scripts to indicate that update-rc.d shouldn't make kill links for them. They might both be useful, since in the case of alsa, it still wants to save the mixer settings before a reboot, but it doesn't have to unload the modules and everything. (There are other scripts in the same boat, of course.) An init script could indicate that it didn't need to be run on reboot at all by its name. I haven't though of anything that doesn't look ugly; foo.noreboot or foo.startonly aren't exactly elegant (and startonly isn't even right, since it could be something that can be stopped by the init script, but doesn't have to be for reboot). It's probably better to avoid anything non-obvious like file permission bits or gid, and a file that lists which ones to run, or which not to run, would need to be maintained by the package system and that would be needless complexity. A subdirectory off of init.d is a possibility, but seems like a needless change just to speed things up a little. I do think it would be good to have some mechanism, maybe a magic comment in the file that update-rc.d looks for when setting up the symlinks. It's annoying to have init scripts which you've removed the symlinks for, and you don't know where to put them back. (was this S10 or S35?...) A format for comments that update-rc.d could read would be nice in general, and could be used for my purpose too. I'm not subscribed to debian-devel, and I'd appreciate a CC:. And no, I'm not hoping to get this into Sarge... I mean, it's going to be released any time now, right :-> -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Attachment:
signature.asc
Description: Digital signature