From 5e17662d138fc9c9f70a4422eab059c2bdc9432d Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Sun, 19 Jan 2020 00:35:34 +0000 Subject: Add -C and -B options, prepare for 1.0.4.0 --- doc/s6-linux-init-maker.html | 120 +++++++++++++++++++++++++++++++++---------- 1 file changed, 93 insertions(+), 27 deletions(-) (limited to 'doc/s6-linux-init-maker.html') diff --git a/doc/s6-linux-init-maker.html b/doc/s6-linux-init-maker.html index 7fe963b..d8c1432 100644 --- a/doc/s6-linux-init-maker.html +++ b/doc/s6-linux-init-maker.html @@ -62,6 +62,8 @@ machine. If it is not the case, the system will fail to boot. [ -n | -N ] \ [ -f skeldir ] \ [ -U utmp_user ] \ + [ -C ] \ + [ -B ] \ dir @@ -102,13 +104,20 @@ the machine should be brought to, traditionally default for OpenRC and 2 or 5 for sysv-rc), and the rest of the command line is made of the kernel's command line except for the kernel arguments of the key=value form, -which have been stored into env_store. +which have been stored into env_store. If the -C +option has been given to s6-linux-init-maker and the +system is indeed running in a container, the rest of the +command line is just the command line that has been given to +the container's init (e.g. for Docker: the CMD). Note +that the runlevel script should not be invoked in a +container, which does not have a notion of runlevels.
  • rc.shutdown: this script will be run as the shutdown sequence, when the administrator runs the shutdown, halt, poweroff or reboot -command. (As well as init 0, init 6, -telinit 0 and telinit 6 for compatibility -reasons.) It should ask the service manager to bring all the +command. (As well, for non-containerized systems, +as init 0, init 6, telinit 0 and +telinit 6 for sysvinit compatibility reasons.) +It should ask the service manager to bring all the services down, and exit when it's done (in other words: it should not try to perform a hard halt/poweroff/reboot itself.) No arguments are given to this script.
    • @@ -117,7 +126,8 @@ No arguments are given to this script. given one argument: the name of the runlevel to change to. Typically, the runlevel script should just invoke the service manager, asking it to bring the machine state to the -wanted runlevel. +wanted runlevel. In a containerized system, this script should +not be used at all.
  • Copy the dir directory to the place declared as basedir (/etc/s6-linux-init/current by default). @@ -312,6 +322,60 @@ available when the s6-linux-init package has been built with the utmps package. The option defines the user that the utmpd and wtmpd services will run as. Default is utmp.

    • + +

  • -C : create a set of scripts that is suitable +for running in a container. This modifies some behaviours: +
    • + +
  • -B : run the system without a catch-all logger. +On a non-containerized system, that means that all the logs from the +s6 supervision tree will go to /dev/console, and that +/dev/console will also be the default stdout and stderr for +services running under the supervision tree: use of this option is +discouraged. On a containerized system (when paired with the -C +option), it simply means that these outputs go to the default stdout and +stderr given to the container's init - this should generally +not be the default, but might be useful in some cases.

    • Organization of the created directory

    @@ -349,7 +413,8 @@ subdirectories it contains are the following:
  • uncaught-logs: this is the directory where the catch-all logger will store and rotate the error messages produced by the s6 supervision tree and the services that do not redirect -their own logs.
    • +their own logs. Not present if the -B option has been +given.
  • service: /run/service will be the scandir. It initially contains a .s6-svscan subdirectory that tells s6-svscan @@ -359,24 +424,26 @@ also contains a list of early services, i.e. s6 services that will be run at boot time as soon as s6-svscan is executed. These services are:
    • @@ -400,7 +467,9 @@ providing secure utmp functionality.

    A directory created by s6-linux-init-maker is only valid on the machine it has been created on. Pre-creating init directories for -other machines is not supported. +other machines is not supported. Of course, the scripts are editable, +so advanced users can run s6-linux-init-maker to create a +basic template, and then make their own modifications.

    @@ -430,22 +499,19 @@ is difficult: in particular, the mechanisms around the shutdown procedure are fundamentally different from about any other init system, so even a simple command such as reboot needs an ad-hoc implementation. +

  • Even for simple systems such as containerized ones, making +sure that the wanted commands only run when s6-svscan is ready +requires a bit of manipulation.

    • The main benefit of s6-linux-init-maker is that it offers -transparent compatibility while automating the tricky technical part. -That means that s6-linux-init-maker has been designed for -real hardware, or at least full-fledged Linux systems, -where the above issues apply. If you are building an init system for a -container, or anything similar that does not -have the /dev/console issue, the read-only rootfs issue, -or the need for sysvinit compatibility, -you will probably not reap much benefit from using s6-linux-init-maker: -you could probably invoke -s6-svscan -directly as your process 1, or build a script by hand, which -would result in a simpler init with less dependencies. +transparent compatibility while automating the tricky technical parts. +Whether it is used for real hardware or for containers, +s6-linux-init-maker gives you a turnkey init system that +frees your mind from the details of getting a +s6 supervision tree running +prior to everything else.

    -- cgit v1.2.3