ADR crinit as secondary init

[[TOC]]

Problem

crinit is an init system. Usually it acts in the same role as e.g. systemd or a SysV-style init. In this case crinit receives the pid 1.

But crinit can also be used as secondary init started by another init. In that situation crinit receives a pid greater than 1 (pid!=1).

If crinit is used as a secondary init (pid!=1), some default features of init need to be implemented in a different way. This ADR discusses the options to handle such default features.

The features are:

zombie reaper

(from man PR_SET_CHILD_SUBREAPER)

When a process becomes orphaned (i.e., its immediate parent terminates), then that process will be reparented to init (pid=1) or to the nearest still living ancestor subreaper, if defined.

Subsequently, calls to getppid in the orphaned process will now return the PID of the subreaper process, and when the orphan terminates, it is the subreaper process that will receive a SIGCHLD signal and will be able to wait on the process to discover its termination status.

If crinit is running as pid=1, handling of such processes must be fulfilled by crinit. If crinit is running as secondary init (pid!=1), a decision needs to be taken how to handle orphaned child processes.

default minimum mounts

Mounting of the important filesystems such as /proc and /sys shall be done by crinit or have already been done by the previous init (pid=1).

Following mounts are deemed as minimal by crinit:

#

mount

mount point

mandatory for crinit

1

devtmpfs

/dev/

2

procfs

/proc/

yes, for kernel cmd-line reading

3

sysfs

/sys/

4

devpts

/dev/pts/

5

tmpfs

/run/

yes, for socket interface

If crinit is running as pid=1 these mount operations need to be fulfilled by crinit, if crinit is running as secondary init (pid!=1) a decision needs on what occasions these filesystems shall be

Influencing factors

Debugging and development aids of systems are not addressed here.

Assumptions

pid-name spaces

If crinit is started in a pid name space (using flag CLONE_NEWPID) it runs under pid=1, therefor it can not detect that it is in fact running as a secondary init. This way crinit will do the same operations for mount and zombie-reaping as if it was started directly from kernel as the primary init.

mount - Considered alternatives in case crinit is secondary init

1.1) no mounts if pid!=1

crinit does not do the minimal mounts if it detects a pid!=1, it expects mandatory mounts to be done by primary init.

pros

  • current behavior, no changes needed

  • double mounting and subsequent error messages are avoided

  • older integrations will not experience a breaking change

cons

  • if operated in a mount-namespace (but not a pid-namespace) other tools (e.g. crinit tasks) need to do the mounts

1.2) mount if not found

crinit tries to detect and mount the filesystems in case of unsuccessful detection.

pros

  • the minimal filesystem are always there

  • double mounting and subsequent error messages are avoided

cons

  • needs careful design to not cause any race-condition etc.

  • older integrations might experience a breaking change

1.3) mount if configured

The crinit configuration is extended to define the requested behavior. Default is to mount the filesystems, if pid=1, otherwise mount is skipped. Mandatory mounts are done anyhow.

option

description

sys-mounts

mounts the minimal fs

no-sys-mounts

does not do any mounts

The configuration is done via commandline argument. Configuration via kernel-commandline is not needed, as default fits to pid=1. Configuration via config-file is not yet considered.

pros

  • all needs can be covered

cons

  • implementation/documentation effort

  • older integrations might experience a significant breaking change

zombie reaper - Considered alternatives in case crinit is secondary init

2.1) reap all terminating child processes (zombies), if pid=1

If crinit detects to have pid=1, it acknowledges the termination of each if its child processes using ‘wait()’. If crinit has a pid different from 1 (pid!=1) it does nothing.

pros

  • implements the required activity of init

  • simple

  • works fine as overall primary init

  • works fine as primary init in a pid-namespace

  • older integrations will not experience a breaking change

cons

  • as secondary init, orphaned processes will be re-parented to an init above crinit. Hence an ancestor of crinit will need to care about processes that were orphaned in the process hierarchy of crinit.

2.2) request use of pid-namespace

The integrator using crinit is requested to always start crinit in a new pid-namespace to force it to pid=1.

pros

  • no code changes needed, see above alternative

  • older integrations will not experience a breaking change

cons

  • doc changes needed

  • making crinit dependent on kernel feature is not ideal

  • debugging might become more complicated

  • obstructs view of system “above” the secondary init

2.3) crinit to become CHILD_SUBREAPER if pid!=1

If crinit detects pid=1 normal handling of terminated child processes is committed. If crinit detects pid!=1, it sets the PR_SET_CHILD_SUBREAPER flag, see above.

pros

  • limited changes

  • no pid namespace needed, but still possible

cons

  • the flag is set unconditionally

  • older integrations might experience a breaking change

2.4) configure crinit to become CHILD_SUBREAPER if pid!=1

As before, but the flag PR_SET_CHILD_SUBREAPER is only set in case it is configured. The configuration defaults to not setting the flag. If crinit detects being pid=1 it always handles terminating children.

option

description

child-subreaper

Make crinit register itself as child subreaper

no-child-subreaper

Inverse of above

The configuration is done via commandline argument. Configuration via kernel-commandline is not needed, as default fits to pid=1. Configuration via config-file is not yet considered.

pros

  • all options possible

cons

  • more implementation/documentation effort

Decision

After checking for completeness of alternatives and taking all pros and cons to account following decision was taken:

For mount:

1.3 mount if configured

For Zombie-Reaping

2.4 configure crinit to become CHILD_SUBREAPER if pid!=1

Hint: no further rationale for the decision is given here! If you feel the need to add a rationale here consider to add it as pros and cons to the above lists.

Open Point

Following points are identified as open after the decision was taken.

none