init/docs/bootup.md

System Bootup Process

Initial Ram Disk to Rootfs transition

After mounting the root filesystem, either the kernel or the initial ram disk startup process is expected to exec the init program from the root filesystem.

At the current time, there is no support for re-scanning the service files yet, so when init is started, the final configuration in /etc/init.d has to be present. As a result, we currently cannot perform mounting of /etc/ or packing init into the initial ram disk and doing the rootfs transition.

Also, as a result of this, changing the service configuration requires a system reboot to be effective.

This will change in the future.

Processing Service Descriptions

The init process reads service description files from /etc/init.d which are usually symlinks to actual files in /usr/share/init.

The exact locations may be changed through configure flags when compiling init.

Service files specify a target which is basically like a SystemV runlevel and can be one of the following:

• boot
• reboot
• shutdown
• ctrlaltdel

After parsing the configuration files, the init process starts running the services for the boot target in a topological order as determined by their before and after dependencies.

Services can be of one of the following types:

• wait
• once
• respawn

Services of type wait are started exactly once and the init process waits until they terminate before continuing with other services.

The type once also only runs services once, but immediately continues starting other services in the mean time without waiting.

Services of type respawn also don't stall the init process and are re-started whenever they terminate.

Service Process Setup

If a service description contains only a single exec line, the init process forks and then execs the command directly in the child process.

If the service description contains a tty field, the specified device file is opened in the child process and standard I/O is redirected to it before calling exec. Also, a new session is created.

If a service description contains multiple exec lines, the init process forks off to a single child process that does the same setup as above, and then runs the command lines sequentially by forking a second time for each one, followed by an exec in the grand child and a wait in the original child.

If a single command line returns something other than EXIT_SUCCESS, processing of multiple command lines is immediately stopped and the offending exit status is returned to init.

The init process reads environment variables from /etc/initd.env.