At the risk of repeating myself, I don't really mind if it is
numeric or text - so long as it is consistent and functional...

For instance you refer to /sbin/rc as the way to change from
one runlevel to another, yet 'man rc' shows nothing. Whereas
a 'man telinit' on gentoo does give a description of a program
claiming to be the correct way to change runlevel...

Plus it isn't clear to me from any docs I can find if /sbin/rc expects
a text or numeric runlevel argument. At least telinit is
well documented...

If /sbin/rc is the way to do it, why is it not documented in the manual??
If telenit is not the way to do it, why is it in the manual??

And why specify the runlevel by name at boot, and by number in inittab?

Fudging things by just making the name equal the runlevel number just
introduces a source of potential confusion. A bit like having some file
commands use name, and others using inode number. Sure you could suggest
that all file names be made equal to the text representation of the inode
number, but that would hardly be an elegant solution and would defeat the
purpose of having text names... It is much better to have all system calls
work on names and keep the inodes internal - as is done.

Maybe it is just me, but I think it seems a bit of a confusing muddle..

Anyway, thanks for the clarification on the dependency cache stuff.
That was something I wasn't sure of.

Regards,
DigbyT

On Mon, Mar 28, 2005 at 01:55:28PM -0500, Dave Nebinger wrote:
> > > 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...
> 
> There's nothing stopping you from renaming default to 3, etc.  If that's
> what you prefer, then go ahead and have at it.  Gentoo is your friend, not
> your enemy.
> 
> > I agree.  The worst part about switching from one *nix version to
> > another is trying to figure out how that particular distro chose to
> > implement the runlevels.
> 
> Hardly.  This is just one difference as compared to the whole /etc
> structure.  Gentoo tends to nest /etc files in directories where, if you
> build and install yourself, tend to have configuration files right at the
> /etc level.
> 
> And when you're digging into other documentation you'll find references to
> what are considered 'standard' files that aren't in the same places in
> gentoo.
> 
> > > 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).
> > >
> > 
> > I'm not sure.
> 
> It's both.  The env-update (and rc-update) rebuild the dependency cache file
> which is then used at runlevel switch to ensure that the services for the
> particular runlevel are up (or stopped if necessary during a runlevel
> switch).
> 
> > > 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'.
> > 
> > True, when switching between runlevels, you might want some services
> > to stop.  So, you'd probably need to create a more intelligent shell
> > script (unless there is already a way to switch between runlevels).
> 
> It's called /sbin/rc...
> 
> Telinit & sysv runlevels are not the be-all and end-all.  That's why gentoo
> (and suse as well) use different models.
> 
> --
> [email protected] mailing list

-- 
Digby R. S. Tarvin                                             [EMAIL PROTECTED]
http://www.digbyt.com
--
[email protected] mailing list

Reply via email to