Scroll to navigation

FINIT(8) System Manager's Manual (smm) FINIT(8)

NAME

finit — Fast init for Linux systems

SYNOPSIS

/sbin/finit [--] [debug] [finit.cond=foo[,bar[,baz]]] [finit.config=/path/to/alt/finit.conf] [finit.debug] [finit.fstab=/etc/fstab.alt] [finit.status=<on,off>] [finit.status_style=<classic,modern>] [loglevel=<0-7>] [panic=SEC] [quiet] [rescue | recover] [single | S]

/sbin/telinit [-hv] [q | Q | 0-9]

DESCRIPTION

Fast init for Linux systems. Reverse engineered from the EeePC fastinit, 10+ years ago by Claudio Matsuoka, "gaps filled with frog DNA ...". Focus is on small and embedded systems, although Finit is fully usable on server and desktop systems as well.

Features include:

  • Runlevels, defined per service
  • One-shot tasks, services (daemons), or SysV init start/stop scripts
  • Runparts and /etc/rc.local support
  • Process supervision similar to systemd(8)
  • Sourcing environment files
  • Conditions for network/process/custom dependencies
  • Process readiness notification for synchronizing system startup as well as reconfiguration at runtime. Natively PID files are used, but systemd sd_notify() and s6 notification is also supported.
  • Limited support for tmpfiles.d(5), no aging, attributes, or subvolumes
  • Pre/Post script actions
  • Tooling to enable/disable services
  • Built-in getty
  • Built-in watchdog, with support for hand-over to watchdogd
  • Built-in support for Debian/BusyBox /etc/network/interfaces
  • Cgroups v2, both configuration and monitoring in `initctl top`
  • Plugin support for customization
  • Proper rescue mode with bundled `sulogin` for protected maintenance shell

BOOTPARAM

finit support the following command line parameters to alter the behavior at boot. Notice the -- separator needed to tell the kernel which paramters should be given to PID 1. For more information on this, and available kernel command line options, see bootparam(7).

Enable kernel debug. Debug messages are printed to the console until Finit starts up, unless loglevel=7 (below) is used.
set <boot/foo> condition, optionally multiple conditions can be set using the same option, separated with a comma. Alternatively, multiple foo.cond=arg can be given. Each will result in a <boot/arg> condition being set to control the rest of the system bootstrap.

Very useful for selecting different boot modes, e.g. manufacturing test, firmware upgrade, or rescue mode.

Note: <boot/...> conditions cannot be cleared with initctl!

override the compile-time bootstrap config file, default:
Useful when starting up in various rescue mode, factory, or production test setups. Use the top-level configuration file directive rcsd /path/to/finit.d to override the default rcS.d directory.
Enable Finit debug messages on system console and log. Sometimes useful when doing board bringup. Before the system log daemon has started, Finit use the kernel ring buffer, /dev/kmsg.
Tell finit to use an alternate fstab to mount the file system from. Remember, this file must be on the root=... file system provided to Finit from the kernel. If this file is missing, finit falls back to its built-in default, which can be changed at build time using the --with-fstab=/path/to/footab configure option. It is even possible to completely disable the built-in using --without-fstab, meaning finit be started with the finit.fstab option.

Should finit discover that there is no fstab file available, including the fallback, it triggers the same failure mode as when fsck fails, starting sulogin(8), if that is availble. When sulogin is missing, or when the user exits from sulogin, the system is rebooted.

Default fstab, unless changed at build-time: /etc/fstab

Control finit boot progress, including banner. This used to be called finit.show_status, which still works but is deprecated.
Set Finit boot progress style, when enabled.
set the kernel's log level, which is more granular than debug. Also, when loglevel=7, Finit will kernel logs to the console. This is very useful when debugging the kernel at system bring-up. Since loglevel=7 is the same as debug this means you have to use quiet for a quiet boot, until sysklogd takes over logging of kernel events.
By default the kernel does not reboot after a kernel panic. This setting will cause a kernel reboot after SEC seconds.
Suppress kernel logging to console, except for warnings and errors. Also, see loglevel and quiet above.
|
Start rescue/maintenance mode. If your system comes with the bundled sulogin program (Finit, or from util-linux/Busybox), you will be given a root login to a maintenance shell. However, if sulogin is missing, the file /lib/finit/rescue.conf is read and the system booted in a limited fallback mode. See finit.conf(5) for more information.
|
Single user mode, runlevel 1, in Finit. Useful to debug problems with the regular runlevel. All services and TTYs in [1] will be started, e.g., a tty [1] @console nologin configuration presents you with a root console without login.

Note: by definition, single user mode does not have networking enabled. This is also true for runlevel 1.

BOOTING

Before laucnhing services, the system needs to be bootstrapped. This involves mounting all filesystems (not already mounted by an initramfs) in /etc/fstab, or any alternate fstab file provided on the Finit command line using finit.fstab, ensuring that necessary filesystems like: /dev, /proc, /sys, and /run are available and can provide the system with the services required.

With that out of the way, a set of plugins take over:

Cleans up stale files from previous boots and default directories are created in tmpfs filesystems
Probes kernel modules required by the system
Set kernel variables from /etc/sysctl.conf et al

When the plugins are done, finit reads /etc/finit.conf and all other enabled services in /etc/finit.d/*. First all services, run/tasks in runlevel S (bootStrap) are started, When all run/tasks have completed, Finit changes to the configured runlevel (default 2), Processes are started in parallel, in dependency order according to their conditions.

When all services and run/tasks have been started, the console progress is disabled and all configured getty services are started.

CONDITIONS

The condition subysystem in Finit was initially created to track PID files of daemons. If service/task B requires service A to have started, Finit waits for the PID file of service A to be created/updated before it starts service B. Conversely, if service A is stopped and its PID file removed, service B is also stopped.

The following condition families are available today:

Linux netlink events, e.g. net/route/default, net/eth0/up, and net/et0/running
PID files based on the service declaration name:id, gives the condition pid/name:id
Tracks run/task/service state stansitions, including readiness. E.g., service/foo/ready can be used as a condition for service bar, provided foo properly signals its readiness to Finit.
System conditions, e.g. sys/key/ctrlaltdel and sys/pwr/fail
User conditions, assert and deassert using initctl cond [set|clr] foo

SIGNALS

PID 1 is the only process that by default blocks all signals. Finit allows for the following signals to control operation, but recommends instead using the initctl(8) tool.

HUP
Tell finit to reload its configuration file(s), same as initctl reload
USR1
Restart API (initctl) socket.
USR2
Tell finit to perform a system shutdown, same as initctl poweroff
TERM
Like SIGUSR2 but performs a reboot, same as initctl reboot
INT
Sent from kernel when Ctrl-Alt-Del is pressed (on the console), this asserts the sys/key/ctrlaltdel condition, which can be used to start tasks or services
PWR
Sent from a a power daemon on changes to UPS status, Finit asserts the sys/pwr/fail condition

FILES

/etc/finit.conf
Main configuration file
/etc/finit.d/*.conf
Static service definitions
/etc/finit.d/available/*.conf
Available services
/etc/finit.d/enabled/*.conf
Symlinks from available
/run/finit/
Runtime files, including the condition subsystem

SEE ALSO

finit.conf(5) initctl(8) tmpfiles.d(5)

AUTHORS

finit was conceived and reverse engineered by Claudio Matsuoka. Since v1.0, maintained by Joachim Wiberg, with contributions by many others.

April 22, 2023 Linux