Oh, I agree that being able to nominate a runlevel at boot time is a good thing. But I think it would be more consistent to do it by specifying it the same way that it is specified in inittab or to telinit, and the same way it is reported by 'who -r'....
That is, they should all use numeric runlevels, or they should all use text runlevels. It is the inconsistency that I don't like... As far as the dependencies go, are you sure they are checked at script execution time? Normally it would be when the script was added to the runlevel that the sequencing would be done (ie in gentoo when rc-update was run). And I don't think just running all the scripts is enough to change runlevels. Normally you have to work out the difference between the old runlevel and the new, shutdown the things in the old runlevel that weren't in the new, and only start the things in the new runlevel that weren't in the old. That is why it is best to do the change with 'telinit'. Regards, DigbyT On Mon, Mar 28, 2005 at 09:43:41AM -0700, Kiawud wrote: > I'm not even going to claim any expertise in this area. However, off > the top of my head, I can see the following advantages to how Gentoo > does the runlevel: > > 1) By adding 'softlevel' information to the grub settings, you can > switch between runlevels at boot time instead of having to login, > change '/etc/inittab' and then reboot. > 2) By adding the dependency information to the init-scripts, you can > run any init-script knowing that it will make sure everything needed > for it is already running or started. > 3) To change between runlevels, you just have to run all the scripts > in a given '/etc/runlevels/<runlevel>' ... so, if you start in console > mode and want to switch to xdm mode, just run the scripts in that > runlevel directory via a simple shell script (ie: for i in `ls > <runlevel-dir>; do $i start; done) ... (of course, there's probably an > easier way to switch runlevels on gentoo, but again, I'm not an > expert). > > As usual, these are just my thoughts... > > -Hani > -- > [email protected] mailing list -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- [email protected] mailing list
