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

Making SysV boot scripts reboot faster

 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

Reply to: