Re: runlevels [was Re: Upcoming Debian Releases]
On May 26, Tom Lees wrote
>
> No, we don't need xdm in runlevel 4. A better solution would be this (but
> it is more difficult, requires multiple inetd.conf files):-
>
> 2: multiuser, minimal networking, no networking daemons (including inetd).
> 3: multiuser, "client" networking (rpc.ugidd, ident, etc.)
> 4: multiuser, "server" networking (ftp, http, finger, etc.)
>
> > 5: empty for making special local runlevel?
whenever i was playing around with runlevels, i had runlevel 2 to do
system administration (some more programms than runlevel 1/single user.
most important : several getty (doing system work with one getty is a
pain IMO (think of reading a manpage for special parameter xyz)).
please keep runlevel 2 this way, a lot of people will use it this way, i
think. no net, not daemons, a few getty and some utilities (filesystems
mounted).
i ever used 3,4,5 to alternate some program (most difference was with x
/ without x, but in low memory times, i also had a runlevel with x, but
no other daemons like inn, so netscape wasn't that slow).
for most people :
the basic is, what programs you want to run, and what not. then you try
to group these decissions into runlevels. for 10 programs you would need
2^10=1024 runlevels to have all possible situations. even if you drop
the unrealistic, you cannot get all possible situations. the only way to
reduce the number of runlevels is a) don't do specifig runlevels or b)
force a policy.
if we are talking about changing runlevels, we should also discuss
(these themes came up at the linux kongress in a init system discussion) :
a) dependencies or something like that. most daemons won't work without
network. nfsd won't work without portmap. etc...
b) link policy. i don't know how update-rc.d is working, but there are
different aproches (start or stop script in every runlevel, not
both; start and stop script in a runlevel, or none; stoping
daemons with a stop script in the old / the new runlevel etc.)
i know, update-rc.d manages these things, but whe should have a
document, that shows how everything is working, and why we ar edoning it
that way.
c) some program, that can show : these programs are running / these
programs should be running.
d) standart for scripts: every script has start and stop. but what about
"restart" or "reload" or ... ?
(that's an example, why i would like to have debian in one big
cvs source - you could checkout all init.d scripts, modify them,
check them in, and all packages would get fixed with the next
release.)
currently debian is using numbers to mark when to start / stop a
program. we should have a policy what these number mean. think of topics
like "/var is mounted and rw" or "/tmp is rw" etc. yes, there are
systems with read-only filesystems all the time ...
more stuff to think about and discuss. comments are welcome.
regards, andreas (good night, it's 2 a.m.)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: