init run level 7 - Linux

This is a discussion on init run level 7 - Linux ; I read somewhere once, a few years ago, that init actually could support run levels 7, 8 and 9, but that nothing had ever been standardized for these levels. Now I actually have a use for one of them. The ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: init run level 7

  1. init run level 7

    I read somewhere once, a few years ago, that init actually could support run
    levels 7, 8 and 9, but that nothing had ever been standardized for these
    levels. Now I actually have a use for one of them. The question is, can it
    actually be done as run level 7? Or if not as 7, what about using another
    run level like 5?

    The objective is to configure a clean system shutdown and reboot through the
    kexec kernel reload method, instead of the usual reboot. If you are not
    familiar with kexec, it is a facility to allow a kernel image to be loaded
    into the kernel that is now running, such that a special reboot call will
    end the current kernel and initiate the running of the kernel in the new
    image that was pre-loaded. A clean shutdown and unmounting of filesystems
    is still needed before the new kernel is started. The obvious clean way to
    do this is have init run the last step to trigger the kernel reload after
    all the system shutdown has completed.

    So maybe run level 7 can be used. Or maybe not.

    If 7 cannot be used, what about using run level 5? Is there anything inside
    init that would make it handle run level 5 differently if it were configured
    just like run level 6, except for the final step?

    I plan to set up a system to boot in partition 1 and start up ssh daemons.
    It would also start up a timer process that will wait about 3 minutes then
    if a special flag has not been set (probably a file in /etc) it will proceed
    to boot a new kernel image with a different root filesystem and start up a
    full server. The idea here is to have a window of opportunity on a reboot
    to access the system remotely and perform maintenance, including rebuilding
    the main system's root filesystem. It would also be a more safe way to
    reload a new kernel that might not work, as long as there is some means to
    do a hardware reset to get out of a failed one (e.g. one of those web
    controlled power strips).

    OK ... now I need to anticipate off direction responses I might get and head
    these off before someone wastes a lot of posting time trying to suggest
    these things. I already know about pivot_root() and in fact use it
    extensively. But pivot_root() does not work well with an already up system
    (it works great much earlier in time). And that doesn't deal with a broken
    kernel being tested (that might hang on hardware only the remote server
    has). Running the main server under some kind of virtualization might be an
    option, but that's not the aspect I am exploring right now. I'm not sure
    that virtualization would really do the complete job, but I will look at it
    at some point in the future. I've also considered, and dismissed, the idea
    of just starting a production system under chroot. The kexec facility looks
    the most promising, so that is why I am exploiring the init run level issue
    right now to see just how viable kexec will be. So please don't waste my
    time with diversions (that often happen on Usenet).

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-11-07-1719@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: init run level 7

    phil-news-nospam@ipal.net wrote:
    > So maybe run level 7 can be used. Or maybe not.


    The kernel already has different ways of shutting down, which are
    performed from the same run level, namely reboot and halt. So kexec can
    just be a third case. This could be patched into to a shutdown -e
    option.


  3. Re: init run level 7

    On 8 Nov 2006 15:36:57 -0800 Kaz Kylheku wrote:

    | phil-news-nospam@ipal.net wrote:
    |> So maybe run level 7 can be used. Or maybe not.
    |
    | The kernel already has different ways of shutting down, which are
    | performed from the same run level, namely reboot and halt. So kexec can
    | just be a third case. This could be patched into to a shutdown -e
    | option.

    Run level 0 is halt and run level 6 is reboot. Which to use for kexec?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-11-09-0249@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: init run level 7

    phil-news-nospam@ipal.net wrote:
    > I read somewhere once, a few years ago, that init actually could support run
    > levels 7, 8 and 9, but that nothing had ever been standardized for these
    > levels. Now I actually have a use for one of them. The question is, can it
    > actually be done as run level 7? Or if not as 7, what about using another
    > run level like 5?


    The init man pages imply it can:

    Runlevels 7-9 are also valid, though not really docu-
    mented. This is because "traditional" Unix variants don't
    use them.

    --
    Clifford Kite
    /* In my book, the first poster to resort to personal abuse in a Usenet
    debate loses by default. - Rod Smith */


  5. Re: init run level 7

    Clifford Kite wrote:

    >phil-news-nospam@ipal.net wrote:
    >> I read somewhere once, a few years ago, that init actually could support run
    >> levels 7, 8 and 9, but that nothing had ever been standardized for these
    >> levels. Now I actually have a use for one of them. The question is, can it
    >> actually be done as run level 7? Or if not as 7, what about using another
    >> run level like 5?

    >
    >The init man pages imply it can:
    >
    > Runlevels 7-9 are also valid, though not really docu-
    > mented. This is because "traditional" Unix variants don't
    > use them.


    The meaning of the runlevel characters is entirely by convention. There is
    no inherent meaning to any of the characters. I was going to assert that
    ANY ASCII character could be used, but I see that some versions of Linux
    assign a special meaning to 'A', 'B', and 'C'.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  6. Re: init run level 7

    On Fri, 10 Nov 2006 07:25:49 GMT Tim Roberts wrote:
    | Clifford Kite wrote:
    |
    |>phil-news-nospam@ipal.net wrote:
    |>> I read somewhere once, a few years ago, that init actually could support run
    |>> levels 7, 8 and 9, but that nothing had ever been standardized for these
    |>> levels. Now I actually have a use for one of them. The question is, can it
    |>> actually be done as run level 7? Or if not as 7, what about using another
    |>> run level like 5?
    |>
    |>The init man pages imply it can:
    |>
    |> Runlevels 7-9 are also valid, though not really docu-
    |> mented. This is because "traditional" Unix variants don't
    |> use them.
    |
    | The meaning of the runlevel characters is entirely by convention. There is
    | no inherent meaning to any of the characters. I was going to assert that
    | ANY ASCII character could be used, but I see that some versions of Linux
    | assign a special meaning to 'A', 'B', and 'C'.

    I went ahead and set up run level 7 to invoke "/sbin/kexec -e" and it worked
    just fine as long as a kernel has been loaded with "kexec -l" prior to that.
    I might add something as a run level 7 task to check for a special symlink
    to do the kernel load at that time prior to all the filesystems unmounting.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-11-11-1313@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread