On Sat, Jan 17, 2004 at 04:34:44PM +0100, Thomas Hood wrote: > Peter Cordes wrote: > > I always find it dumb that rebooting a GNU system involves > > doing so much stuff, when the machine is going to be rebooted anyway. > > You are right that the current situation does not optimize the speed > of system shutdowns. I have also thought of broaching this subject > in debian-devel, but I never thought it was pressing enough. It's something that's not worth the effort for any one system, only if it's going to help everyone (well, desktop and laptop users). That's why I posted here instead of just removing rc[06].d/*hdparm, etc. on my systems. Now that I look at things in more detail, I see that most of the most obvious candidates for this optimization, such as hwtools, already have this optimization because they're only linked from /etc/rcS.d. > There are two ways to speed up the process. Either refrain from > calling some initscripts, or call the initscripts with a different set > of arguments, allowing them to work faster when preparing for system > shutdown. > > The second solution is more flexible. The way to do the first solution is to put the start link in /etc/rcS.d, or to put a start link in rc[06].d as well as the other runlevels. (look at /etc/init.d/rc: start scripts that are in the previous runlevel as well don't get restarted.) It turns out that this is already being done, by /etc/rc0.d/S35networking, the RAID scripts, and even portmap. Of course, the second is more flexible, and I don't think anything takes advantage of it. > Right, so the init script needs to be able to distinguish a system > shutdown from a service stop. > > [...] > stop) > + [ "$2" = "system" ] && exit 0 > > The same thing could be accomplished using a special environment > variable instead of an argument. /etc/init.d/rc exports runlevel, and RUNLEVEL is apparently already an env var before it runs the init scripts. You could use that without making any changes to rc itself. OTOH, using something specifically for this would make it possible to disable the optimization and do a full stop. > A problem with implementing this is that if the shutdown fails > then the system is left in an undefined state -- services weren't > "properly" shut down and might not be restartable. However, > people might accept this in return for a faster shutdown. This is useful for laptop/workstation machines, not servers so much. If shutdown fails, the system isn't usually in much of a state to recover from anyway. The few people who think they could recover from a failed shutdown can tweak /etc/rc. > > So I guess I've got two ideas here: having a reboot argument > > ... or a second argument after "stop" ... It's not a stop, it's a prepare-for-reboot. OTOH, most scripts won't know about "reboot" at first, so with my idea, they'd get run twice, once exitting with an error, and only working the second time. Your extra argument idea is probably better. -- #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