ShyanJMC

Internal components2-System Init

System Init

In an operative system, the system init (aka; sysinit) is the first program after the kernel start.

The sysinit's responsability is start the programs in the right order to make computer usable by the user.

In Linux systems have the sysinit at; /sbin/init. If the kernel do not have specified the path (place) in which load the sysinit, will load by default in; /sbin/init.

History

At the beggining of portable systems (the operative system; Unix) there was a program with sysinit's responsabilities; sysvinit (“System V” by the AT&T Unix release and “Init”). AT&T Unix System V was released in 1983 and introduced “sysvinit”.

Sysvinit introduce in Unix systems new things;

  • The concept of “daemon” and “service”; a program which start in system's boot.
  • In “/etc/init.d” folder are the files in which sysvinit reads the daemon's configurations (the commands to start, restart, stop and check process).
  • The “/etc/inittab” file is the system startup configuration.

Sysvinit devides the startup process in “runlevels”. A runlevel is a daemon/service group in which is started in a specific order. In Unix, the runlevels are available from 0 (zero) to 6 (six) and not startup one after another (runlevel 1 will not start after runlevel 0). Each runlevel functions depends of the distribution and configuration.

The runlevels standards are;

  • 0 -> turnoff/shutdown.
  • 1 -> single user mode (root), without graphical interface and network.
  • 6 -> reboot.

The rest of runlevels are not standard but generally do this;

  • 2,3,4 -> multi user and network without graphical interface.
  • 5 -> multi user with graphical interface.

At today some linux distributions like Slackware still use sysvinit.

The main commands are;

  • To change runlevel:
init [0-6]
  • To manage services:
service [service_name] [start,stop,restart,reload,condrestart,status,--list,--add]
  • To check system's boot process:
chkconfig [service_name]
chkconfig --list
  • To enable or disable service startup:
chkconfig [service_name] [on,off]

Evolutions

Upstart

At 2006, Canonical (the company behind Ubuntu Linux), with the work of Scott James Remnant, relased a new sysinit; Upstart.

Upstart is a event-based sysinit. Event-based is a paradigm in which the software response to actions (system’s or user’s actions), input information, a message or information from another specific program, hardware actions, etc. The last official commit (changes in the code) was in 2014 and is under maintenance mode since 2016.

From Wikipedia;

Upstart operates asynchronously; it handles starting of the tasks and services during boot and stopping them during shutdown, and also supervises the tasks and services while the system is running.

At today Chrome/Chromium OS (from Google) use upstart.

The main commands are;

  • Check configuration syntax:
init-checkconf -d /etc/init/process_name.conf
  • To manage services:
[start,stop,restart] [job/service_name]
  • To check system's boot process:
initctl list
  • Show environment variables:
initctl list-env
  • Set/Unset environment:
initctl [set,unset]-env foo=bar
  • Reload configuration:
initctl reload-configuration
  • Show relations and dependencies:
initctl2dot

Configurations files are in;

/etc/init/[service_name].conf

Services' Information are in;

/var/log/upstart/[service,job].log

Systemd

In 2011, RedHat developpers Lennart Poettering and Kay Sievers made Systemd with the idea of enhance Sysvinit and Upstart sysinits. The main idea was replace the computational overhead of shell, this is because those sysinits (Sysvinit and Upstart) use shell scripts to start,restart,stop and monitor status. Systemd introduced many new things;

  • Units; like object oriented programming, units services can have states, own configurations, own environments, dependencies (others units, services or events).
  • Parallel start: Systemd using units, can start services in parallel at the same time and enhance the boot speed.
  • The complete change of paradigm; now Systemd absorved many others basic programs like logind, udevd, and others. And most of the community hate it, because breaks with the Unix philosofy; "Do one thing per program, but do it well.".

Now with systemd, you have a very complete sysinit and system manager in your linux. Systemd can manage without external help;

  • Networking; DNS (systemd-resolved) and network interfaces (systemd-networkd).
  • Containers; Something like the next evolution of chroot (systemd-nspawn).
  • Syslog; journal as replacement of syslog.
  • Mount points; systemd.mount as replacement of fstab.
  • Boot; UEFI control (systemd-boot) and first boot (systemd-firstboot).
  • Time Sync; systemd-timesyncd as replacement of ntpd and others.
  • User control; User’s home control (systemd-homed) and User’s session control (systemd-logind).

And many many many others. But, what about if you want change systemd behavior for external program? Well, you can’t. Systemd will stop self module for that task and will the leave control to that external program, but will be using CPU power and some RAM memory. Examples about it are; NetworkManager with systemd-networkd and systemd-resolved.

With this, the most of control about the Linux system is under systemd. Because of that there are many communities that do not like systemd (communities of Devuan, Artix, Gentoo, Slackware and others Linux distributions). Systemd is not bad itself, is just not modular as must be, because of that those communities created alternatives.

At 2021 the mayority of Linux distributions use Systemd as sysinit and system manager; Debian since 2019, Ubuntu since 15.04 version, Arch linux since 2012/3.

The services files are in “/etc/systemd/[user,system]”.

The main commands are;

List units;

systemctl list-units

Administrate services;

systemctl [start,stop,restart,status,enable,disable] [service]

Reload services/targets files;

systemctl daemon-reload

See how much time take each service to start;

systemd-analyze blame

See service’s file contents;

systemctl cat [service]

Power management;

systemctl [reboot,poweroff,suspend,hibernate,hybrid-sleep]

OpenRC

Since the introduction of Systemd, some specifics groups start working in alternatives. In specific Systemd not cause the release and birth of OpenRC but yes grow the development speed.

OpenRC started as sysinit in 2007 by Roy Marples as the orignal author (who sadly have terminal cancer since 2020, good luck friend) who wrote it in C in full complience of POSIX standard (making it usable on BSD and Linux systems). Since the adoption of systemd by the most of mother distributions, OpenRC is the sysinit of distributions like; Gentoo, Alpine Linux, Artix Linux, TrueOS, Funtoo, etc.

OpenRC works in the same way like sysvinit but enhancing it; provide runlevels as services groups, provides a supervise daemon, is semi modular, the services configurations files works like shell scripts, provie parallels boot and dependencies, etc.

Before 0.25 versions, OpenRC depended by sysvinit to start properly but since that version can start as a complete sysinit with the binary; /sbin/openrc-init

Instead of be like Systemd and be a monolithic sysinit, OpenRC follow the philosophy of Unix; do one thing and do well. In this case, OpenRC leave the responsibility to;

  • udev, eudev, xudev, mdev, etc for manage “/dev” pseudo-filesystem.
  • elogind; to manage user sessions and configurations.
    • note; if need suspend must be under elogind scope, the command is this;
loginctl suspend

The configuration file is in; “/etc/rc.conf” The services file are in; “/etc/init.d”

The runlevels in OpenRC are;

  • default: in which must be the user’s services.
  • nonetwork: in which is located the local/loopback network configuration.
  • shutdown: in which are the services will be executed when the shutdown process start.
  • sysinit: in which are the services to execute when the system starts.
  • boot: in which are the services needed to finish the boot up process.

Then exist the dynamic runlevels like “needed/wanted” (the services that depends of another services) and “manual” (the services that you run manually.

The main commands are;

Manage services;

rc-service [service] [start,stop,restart,command in serv file]

Add or delete service from runlevel;

rc-update [add,delete] [service] [runlevel]

List all available services;

rc-update show -v

Power management;

openrc-shutdown [--poweroff,--reboot,--single,--halt,--kexec,etc]

Others

There are others like S6 suite, and probably more sysinits, but I will not speak (for now) of they because are still under a huge alpha/beta state. If in the future they go to a stable release, I will speak here.