Lennart Poettering wrote:
What's wrong with numerical runlevels other than Linux flavors starting the
network in level 2 instead of 3?
They don't make any sense, that's wrong with them.
1 as single user, 2 as multiuser makes reasonable sense, with networking
as the logical next step.
Why only 6 of them?
Until someone decided to make X something special you only needed 3
steps that you could jump among: single user, multiuser,
multiuser+network. But with a scheme based on directory names and the
inherent sort order of a wildcard expansion, there initially wasn't a
real limit.
I never understood why a process like "shutdown" or "reboot" should be
considered a "level". Do you?
runlevel 0 = quit sounds extremely logical. 6=reboot was someone just
running out of ideas.
Nobody knows what the actually mean.
Unless they read a SysV manual back when they fit in your pocket?
They are using numeric ids for no
reason.
Their sort order is well known.
I mean, people invented stuff like DNS for not having to
deal with random numbers that often. Why should they deal with random
numbers when dealing with init systems, then?
Almost all distributions use only 2 or 3 of them.
Their configuration is plain awful.
They're totally awkward, because there are numeric levels and the
magic runlevel S.
Well, yeah - but then there is q also - and necessarily so...
Also, init doesn't really have any information what service is running
in which one is not for the current runlevel.
That's the point. Init should not know anything specifically except for
the stuff it manages directly per inittab.
> To work around that the
configuration is highly redundant with lots of symlinks.
Which lets it do anything it needs to do, finding out only when it needs
to know. All very good things.
Then, on the philosophical level, having a single set of "runlevels"
just doesn't cut it, because services these days should only be
started maybe when a certain HW is around, or when some specific user
software runs that wants to make use of it. How do runlevels fit into
that? They are too static to reflect this dynamic way of starting and
stopping services properly.
In short, they don't make any sense. They should die.
They make sense for what they do - otherwise how can I tell the system I
want to go down to single user mode with a clear definition of what will
still be running? And I should be able to tell it I want multiuser mode
but with no networking, but Linux distros screw that up. But init
isn't limited to those, it also does things specified in inittab. If
you want magic stuff to happen on certain events, respawn the thing that
detects the event starting at the desired runlevel and let that
program do whatever is supposed to happen next. Getty watching for a
carrier detect hardware event is the original example - and it doesn't
need to know anything except what to exec next and doesn't need to wait
around for results. Processes are supposed to be cheap enough that if
you need one you can use it - don't make init need to know anything else.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
