[Gordon Farquharson] > But if one does not use the optimization (I presume in this case, > we're talking about insserv), then we don't have a problem.
I am not talking about insserv optimization. I am talking about sysv-rc (/etc/init.d/rc) optimizations, ie the normal debian boot system. > It seems that insserv with the LSB headers do have the capability to > run the script as the first and last script within a particular > runlevel, or is there a way to do implement this? Neither the normal sysv-rc boot system nor insserv have this capability. There is no way to know if some other script will insert itself before or after a given script in any system. It is always possible for a script to insert itself before or after another script. Btw, why run a script both at the end of rcS.d and at the start of rc[0-6].d? It seem redundant to me. Why not only run one at the end of rcS.d (which is imedately before the start of rc[0-6].d), and then again at the end of rc[0-6].d? What should happen when runlevel is switched from 2 to 3, btw? Should the leds change or not? At the moment, I am not sure what will happen, because the runlevel change handling in /etc/init.d/rc is not supposed to have both stop and start symlinks for the same script in the same runlevel. > In addition, the NSLU2 is almost exclusively used as a server, so > boot time is not really an issue, so I doubt that many people are > going to be tempted to install insserv. The main feature of insserv is correctness, not speed. It make sure boot scripts are always correctly ordered according to their stated dependencies, and not sometimes messed up because of problematic selection of sequence numbers. I hope some NSLU2 users want to ensure correctness. I know I want it for my NSLU2. :) > For future releases, Debian may use insserv by default, or upstart > (which seems to have been adopted by Fedora, and is obviously used > in Ubuntu), or something else. When that happens, I think that we > can revisit this problem. I'm not sure it makes sense to put a lot > of work into finding a solution until the new init system becomes > the standard. Does this sound reasonable? Nope, not really. Because your assumtion that the current behaviour is OK with the default debian system is not correct. It is depending on undefined behaviour, and I strongly recommend not having both start and stop symlinks for the same script in a given runlevel because of this. I am not quite sure how the leds are supposed to blink at boot and runlevel switching, and this make it hard to propose a solution that do not depend on undefined behaviour. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
