Re: Proposal: A config file for runlevels (DRAFT)
On Mon, 30 Dec 1996, Winfried Truemper wrote:
> [My apologies to everyone who recieves this twice.]
>
>
> You may have read the discussion about possible enhancements in Debians
> configuration policy. This mail is a request for comments on one
> aspect of the discussion: a config file for runlevels.
>
> The traditional "SysV" scheme of implementing runlevels is through links
> in "/etc/rc?.d/*". The main problem with this links is that you can't
> get easily a survey of your setup.
Only on a Debian system. My Solaris system has all mulit-user,
networking CLIENT stuff in runlevel two. Run level three
contains server realted stuff (usually just nfs server and maybe
sybase). Everything else is EMPTY!
Debian's position is that its easier to put a link in every rc*.d
directory instead of allocating runlevels for packages. I think
it would make much more sense to Do The Right Thing here and take
the time to identify at least two default runlevels for debian.
Run level 2 should be configured as a mulituser/networked/client
run level and runlevel 3 its server compliment. Then packages
just need to be flagged as falling into either one of these two
groups.
This would make it much easier to develop tools to manage run
levels because they would be inherintly easier to manage. I
realize that all of the work put into the start-stop-daemon
intended to handle having links everywhere, but it doesn't. It
doesn't handle the case where I want a run level to stop some
services a start others, or not start some, etc.
The scripts themselves could also provide a comment line with
info to be extracted by management tools to identify the purpose
of the script (or package, or whatever). These are very slight
changes that can be made relatively painlessly. I think they
address the issue you raised (of managing run levels) without
departing from the familiar use of SysV init scripts.
In fact, I think that the centralized database that Bruce and
Lars have been discussing offers the leverage to do this fairly
easily. I'm I'm correct, the database will have default values
for packages provided by the maintainer. These values will be
for configurable things that needn't be touched unless the user
wants to dive in and get dirty. One of these items could easily
be a default run level. This could then (but needn't be)
modified/set prior to installing the package in the manner
described by Bruce.
Now that I think about it, it might make sense to provide another
default run level that's user selectable for "experimental"
packages. This could be a rarely used run level of say "7". The
idea would be for people to install experimental packages there
so they don't get run by default. There could be an easy tagging
method in dselect (or some future front end to the dselect
library interface) that allows people to install experimental
packages there. An experimental package may be a "stable"
package that the user doesn't know about but wants to try, or it
may be something from "unstable", etc.
The only other change that would need to be made is to have the
run levels started incrementally at boot time (and only at boot
time). That means when the initial run level (either default in
inittab or entered in the absence of a default value) at boot
time is "4", run levels "1", "2", and "3" have the K and S
scripts run along the way to "4". This may be the most
significant part of the change. I think this will allow for a
much more manageable run level environment, and make it easier to
create tools to manage them.
Perhaps a tool that would consult the database for runlevel
selections and verify link correctness (or implement conformity)
would also be useful. Perhaps this should be built into the
yet to be written run level management tool(s) though.
Sorry for the long post.
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: