[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: runlevels

[I am slowly moving this from bug.gnu to debian-hurd, because this is mostly
related to Debian organisation.]

On Mon, Feb 22, 1999 at 09:21:26AM -0500, Thomas Bushnell, BSG wrote:
> Yeah, I understand the way the System V init works.  I am just
> uncertain, as is Joel Weber, I think, of exactly whether the
> full-blown complexity of the System V layout is worth much at all.

Please don't question the need for the scripts to be run in each runlevel.
To decide about the necessity is within the package maintainer and the
system administrator of a Debian box. Any Debian system should support this

To give you an idea why this is useful, consider

1) Checking file systems.
2) Setting up keyboard layout (!) (not everybody knows how a US keyboard looks like)
3) Basic networking for remote administration.
5) Other network services to make the system functional.

Single user mode in _Debian_ is definitely NOT intended for fixing a
completely broken system, but for administration of a multi user machine.

If you need to do administration tasks and want to ensure nobody is logged
in, you eneter single user mode, and do your work. After that, going back to
multi user runlevel makes the system available again.

To fix completely screwed system, which can't even execute shell scripts,
you need a rescue disk anyway. Your opinion seems to differ, but that's how
Debian thinks about it, and all Debian systems should follow it.

(in another mail, you wrote):
>    *What* scripts need to get run when entering single-user mode upon
>    system boot?  Please be specific.

First, the scripts are started which bring down certain services, and then
scripts are started, which start other services. Note that just killing all
tasks is _not_ acceptable, because each service should have a chance to exit
gracefully (and each script should have a chance to execute other commands,

>    Some things that should definitely
>    *not* happen when entering single-user mode upon system boot are
>    things like starting the network or fsck-ing disks.

As the system administrator of your machines, you are free to remove all
symlinks in runlevel 0, which start those. Other people, for example the
Debian folks, like to have a good keyboard layout (not everyone has US
keyboards) or network for remote administration.

>    *What* scripts need to get run when shutting down the system?  Be
>    specific.  Right now tasks just generally die, but they should
>    probably get the signals that are also sent on transition to
>    single-user (SIGHUP, then SIGTERM, then SIGKILL).  Is more that
>    necessary?  Exactly why?

First, each script prints out a line, which informs the administrator about
the shutdown progress and makes it more comfortable to localize errors.

Then, the ORDER in which the services are brought down can be specified,
which helps to make the system more reliable. This way you don't kill the
network below apaches eyes.

Then, some scripts can save state information for next start up, for example
sound driver modules, or the random seed of the random number generator

> I understand that the existing Debian packages assume the System V
> layout, so we need to make that work, but there are more ways to do it
> than just implement the System V init.

Everybody is welcome to work on other solutions, Debian has a well defined
interface called update-rc.d which can be diverted. However, any solution
needs to support different runlevels and stopping and starting services in
a given order. We even have already have an alternative concept available,
where all scripts are stored in a file this way:

        # This is the configuration file for /etc/debian/runlevel.conf
        #<sort> <off>   <on>            <script>
        05      -       0               /etc/init.d/halt
        05      -       1               /etc/init.d/single
        05      -       6               /etc/init.d/reboot
        10      0,1,6   2,3,4,5         /etc/init.d/sysklogd

However, this is of little relevance.

It is just important that we have _complete_ control over scripts started
and stopped from one runlevel to another.

[future idea deleted]

> But for right now, I think the best thing to do is hobble together a
> layering which would run the existing scripts on top of the BSD-style
> init that the Hurd currently supports.

Yes, I am working on it. That's why I started this discussion.

> H: Halted, or rebooting.  Both should be treated identically.
> S: Single-user
> M: Multi-user
> H -> S
>   Now: Currently the system runs /bin/sh.  It's been pointed out that a
>     sulogin might be nice for this case, and I agree.  It should be as
>     easy as tweaking init slightly to run a different program.

The sulogin will be started from the Debian scripts which are started in
this runlevel.

>   Debian: I don't think we actually need to run any startup scripts
>     here.  As a sysadmin, I have never found the running of automatic
>     scripts for single-user mode to be helpful, and it often hurts.

It is easy for you to remove the links from the runlevel directory, so that
no service is started. However, Debian, as a distribution builder, must
support everybody, and in general, see above, Debian considers the single
user runlevel for administration, not for fixing a completely screwed
system (use the rescue disk for that).

>     But it would be a nice idea to have a program that would run the
>     scripts that Debian packages install for this case, and so we
>     should do that.  Then a sysadmin who wants that state to start up
>     can run the program.  We could add a printf in init that would
>     mention this program to the user, and suggest its use.

As I showed above, it is more convenient to do it the other way round.

Consider remote administration: If you enter single user mode, and every
process gets killed but a shell, it is too late for you to enter a comand,
you can't, because you can't connect.

Consider keyboard layout: Not everybody can use the US keymap.
> H -> M
>   Now: /etc/rc gets run and then the live terminals get started.
>   Debian: Just put commands in /etc/rc to run the startup scripts.  
>     Hey, that would be the same program as above.

Isn't that /libexec/rc? However, it is not the very same command, because
we need a different behaviour, if we have single or multi user.
> S -> M
>   Everything would be the same as for H -> M.

No, absolutely not. You are forgetting about the way how sysvinit works.

In H -> M, you start the "start" boot scripts (rcS.d) and then the multi user
"start" scripts.

In S -> M, you start the "stop" scripts in single user, and then the "start"
scripts in multi user.

This is quite different.

> M -> S
>   Now: Running programs get signalled (SIGHUP, then SIGTERM, then
>     SIGKILL).  The /bin/sh is run.


>   Debian: I suspect that just killing things is fine.  But if extra
>     actions really need to get run, then have a watchdog process that
>     listens for the SIGHUP and then runs the shutdown actions.

Killing is not fine. You can shutdown much more nicely if you run the stop
scripts in a certain order, print out a message for debugging, and give the
programs a chance to exit themselves. You can also save state information
(see above). THEN, you send SIGTERMS, and wait a couple of seconds, THEN,
you send SIGKILL. After that, you unmount local file systems, and power

>     But it
>     should still always work even if the shutdown actions aren't run,
>     because sometimes people do kick power cords or the power grid
>     fails. 

I can't follow this argumentation. All bad things can happen if you plug
power chord, especially with your file system.

> M -> H
>   Now: Running programs vanish as the kernel stops. 
>   Soon: I will change this to do the same things that happen for the
>     case M -> S above.
>   Debian: The same comments as M -> S apply.

Yes, the same as above.

> S -> H
>   Now: Running programs vanish as the kernel stops.
>   Debian: For reliability, the system better not depend on any scripts
>     in this case!

You obviously have a different understanding of the single user mode then
Debian. Because we care about reliability, we at least try to exit as
gracefully as possible, by quitting in order.

Please reflect the situation again. I am surprised how lightly you take this
issue (it reminds me of the "out of memory" discussion a while back). Debian
has lots of experience with putting a system together, and the run level
concept has proven to work very reliable.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Reply to: