INIT(8)

📦
version 3.14 · 5 versions
, in debian trixie

🎀 NAME 🎀

init, telinit — process control initialization 💅

okay so this is init(8), straight out of the Linux System Administrator's Manual, and bestie… this one is a big deal. it's the main character of your whole system. let's get into it 🫶

📜 SYNOPSIS 📜

/sbin/init [ -a ] [ -s ] [ -b ] [ -z xxx ] [ 0123456Ss ]
/sbin/init [ --version ]
/sbin/telinit [ -t SECONDS ] [ 0123456sSQqabcUu ]
/sbin/telinit [ -e VAR[=VAL] ]

look at her. four whole forms. she's booked and busy ✨

🌸 DESCRIPTION 🌸

✨ Init ✨

init is the parent of all processes. literally the mother of every process on your box, no cap. her primary role is to create processes from a script stored in the file /etc/inittab (go read inittab(5) when you're done here, bestie).

that file usually has entries that make init spawn gettys on every line users can log in on. and she also controls the autonomous processes that any particular system needs. she's running the whole group chat 💅

🌈 RUNLEVELS 🌈

a runlevel is a software configuration of the system that allows only a selected group of processes to exist. the processes init spawns for each runlevel are defined in /etc/inittab.

init can be in one of eight runlevels: 0–6 and S (a.k.a. s). the runlevel gets changed by having a privileged user run telinit, which sends the appropriate signals to init telling her which runlevel to switch to. sending signals instead of DMs, iconic behavior 🦋

runlevels S, 0, 1, and 6 are reserved:

  • S is used to initialize the system on boot.
  • when starting runlevel S (on boot) or runlevel 1 (switching from a multi-user runlevel), the system is entering “single-user mode”, after which the current runlevel is S.
  • 0 is used to halt the system.
  • 6 is used to reboot the system.

after booting through S, the system automatically enters one of the multi-user runlevels 2 through 5 — unless there was some problem that needs fixing by the administrator in single-user mode. normally, after entering single-user mode, the administrator does some maintenance and then reboots the system. that's the vibe 🎀

for more info, see the manpages for shutdown(8) and inittab(5).

runlevels 7–9 are also valid, though not really documented. why? because “traditional” Unix variants don't use them. quirky 💀

runlevels S and s are the same thing. internally they're aliases for the same runlevel. twins, not sisters 🌸

🚀 BOOTING 🚀

after init is invoked as the last step of the kernel boot sequence, she looks for the file /etc/inittab to see if there's an entry of the type initdefault (again: inittab(5)). that initdefault entry determines the initial runlevel of the system.

if there's no such entry (or no /etc/inittab at all), a runlevel must be entered at the system console. you're on your own, bestie 😭

runlevel S or s initializes the system and does not require an /etc/inittab file.

in single user mode, /sbin/sulogin is invoked on /dev/console.

when entering single user mode, init initializes the consoles' stty settings to sane values. Clocal mode is set. hardware speed and handshaking are not changed. she sets the vibe but doesn't touch the hardware, periodt ✨

when entering a multi-user mode for the first time, init performs the boot and bootwait entries so file systems can be mounted before users log in. then all entries matching the runlevel get processed.

when starting a new process, init first checks whether the file /etc/initscript exists. if it does, she uses that script to start the process. cute little detour 🎀

every single time a child terminates, init records the fact and the reason it died in /var/run/utmp and /var/log/wtmp — provided those files exist. she's keeping receipts 📝

🔄 CHANGING RUNLEVELS 🔄

after she's spawned all the processes specified, init waits for one of three things:

  1. one of her descendant processes to die,
  2. a powerfail signal, or
  3. being signaled by telinit to change the system's runlevel.

when one of those three conditions happens, she re-examines the /etc/inittab file. new entries can be added to that file at any time. but — plot twist — init still just waits for one of the above three conditions to occur. so if you want an instantaneous response, the telinit Q or telinit q command can wake her up to re-examine (reload) the /etc/inittab file. wake her up politely 💅

if init is not in single user mode and receives a powerfail signal (SIGPWR), she reads the file /etc/powerstatus. then she starts a command based on the contents of that file:

  • F(AIL) — power is failing, the UPS is providing the power. execute the powerwait and powerfail entries.
  • O(K) — the power has been restored. execute the powerokwait entries.
  • L(OW) — the power is failing and the UPS has a low battery. execute the powerfailnow entries.

if /etc/powerstatus doesn't exist, or contains anything other than the letters F, O or L, init will behave as if she read the letter F. default behavior, we love consistency 🫶

usage of SIGPWR and /etc/powerstatus is discouraged. someone wanting to interact with init should use the /run/initctl control channel instead — see the initctl(5) manual page for more documentation about this. do it the modern way bestie, the old way is giving deprecated 😭

when init is asked to change the runlevel, she sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. then she waits 3 seconds before forcibly terminating those processes with the SIGKILL signal.

note that init assumes all these processes (and their descendants) remain in the same process group which init originally created for them. if any process changes its process group affiliation, it will not receive these signals. such processes need to be terminated separately. she can't kill what she can't find, bestie 💀

💅 TELINIT 💅

/sbin/telinit is linked to /sbin/init. she takes a one-character argument and signals init to perform the appropriate action. the following arguments serve as directives to telinit:

  • 0, 1, 2, 3, 4, 5 or 6 — tell init to switch to the specified run level.
  • a, b, c — tell init to process only those /etc/inittab file entries having runlevel a, b or c.
  • Q or q — tell init to re-examine the /etc/inittab file.
  • S or s — tell init to switch to single user mode.
  • U or u — tell init to re-execute itself (preserving the state). no re-examining of the /etc/inittab file happens. the runlevel should be one of Ss0123456, otherwise the request would be silently ignored. silent treatment, brutal 🙈

telinit can tell init how long she should wait between sending processes the SIGTERM and SIGKILL signals. the default is 3 seconds, but this can be changed with the -t option.

telinit -e tells init to change the environment for the processes it spawns. the argument of -e is either:

  • of the form VAR=VAL, which sets variable VAR to value VAL, or
  • of the form VAR (without an equality sign), which unsets variable VAR.

telinit can be invoked only by users with appropriate privileges. sorry bestie, not everyone gets the aux cord 🔥

the init binary checks if it's init or telinit by looking at its process id; the real init's process id is always 1. from this it follows that instead of calling telinit one can also just use init instead as a shortcut. she contains multitudes ✨

🌱 ENVIRONMENT 🌱

init sets the following environment variables for all its children:

  • PATH — /bin:/usr/bin:/sbin:/usr/sbin
  • INIT_VERSION — as the name says. useful to determine if a script runs directly from init.
  • RUNLEVEL — the current system runlevel.
  • PREVLEVEL — the previous runlevel (useful after a runlevel switch).
  • CONSOLE — the system console. this is really inherited from the kernel; however, if it is not set, init will set it to /dev/console by default.

giving the kids everything they need before they leave the house 🎀

🥾 BOOTFLAGS 🥾

it is possible to pass a number of flags to init from the boot monitor (e.g., LILO or GRUB). init accepts the following flags:

  • -s, S, single — single user mode boot. in this mode /etc/inittab is examined and the bootup rc scripts are usually run before the single user mode shell is started.
  • 1–5 — runlevel to boot into.
  • -b, emergency — boot directly into a single user shell without running any other startup scripts. straight to business, no small talk 💅
  • -a, auto — the LILO boot loader adds the word "auto" to the command line if it booted the kernel with the default command line (without user intervention). if this is found, init sets the "AUTOBOOT" environment variable to "yes".
note that you cannot use this for any security measures — of course the user could specify "auto" or -a on the command line manually. not a lock, bestie, just a vibe check 🔒💀
  • -z xxx — the argument to -z is ignored. you can use this to expand the command line a bit, so that it takes some more space on the stack. init can then manipulate the command line so that ps(1) shows the current runlevel. sneaky, but iconic ✨
  • --version — this argument, when used on its own, displays the current version of init to the console/stdout. it's a quick way to determine which init software and version is being used. after the version information is displayed, init immediately exits with a return code of zero. in and out, no notes 🎀

🔌 INTERFACE 🔌

init listens on a fifo as, /run/initctl, for messages. Telinit uses this to communicate with init. the interface is not very well documented or finished. those interested should study the initreq.h file in the src/ subdirectory of the init source code tar archive. it's giving work-in-progress, but we respect the hustle 🫶

📡 SIGNALS 📡

Init reacts to several signals:

  • SIGHUP — has the same effect as telinit q.
  • SIGUSR1 — on receipt of this signal, init closes and re-opens its control fifo, /run/initctl. useful for bootscripts when /dev is remounted.
  • SIGUSR2 — when init receives SIGUSR2, init closes and leaves the control fifo, /run/initctl, closed. this may be used to make sure init is not holding open any files.
however, it also prevents init from switching runlevels. which means commands like shutdown no longer work. 😭 the fifo can be re-opened by sending init the SIGUSR1 signal. so like… know what you're doing, bestie.
  • SIGINT — normally the kernel sends this signal to init when CTRL-ALT-DEL is pressed. it activates the ctrlaltdel action.
  • SIGWINCH — the kernel sends this signal when the KeyboardSignal key is hit. it activates the kbrequest action.

📖 CONFORMING TO 📖

init is compatible with the System V init. she works closely together with the scripts in the directories /etc/init.d and /etc/rc{runlevel}.d. if your system uses this convention, there should be a README file in the directory /etc/init.d explaining how these scripts work. go read it, bestie, it's literally right there 🦋

📁 FILES 📁

  • /etc/inittab
  • /etc/initscript
  • /dev/console
  • /var/run/utmp
  • /var/log/wtmp
  • /run/initctl

the whole squad, accounted for 💖

⚠️ WARNINGS ⚠️

init assumes that processes and descendants of processes remain in the same process group which was originally created for them. if the processes change their group, init can't kill them and you may end up with two processes reading from one terminal line. that's not a vibe, that's a horror movie 💀

on a Debian system, entering runlevel 1 causes all processes to be killed except for kernel threads and the script that does the killing and other processes in its session. as a consequence of this, it isn't safe to return from runlevel 1 to a multi-user runlevel: daemons that were started in runlevel S and are needed for normal operation are no longer running. the system should be rebooted. no take-backs, no rewind, just reboot 🔥

💥 DIAGNOSTICS 💥

Okay so bestie, listen — init is not gonna let a broken entry ruin the whole vibe. It's lowkey a helicopter parent and honestly? Iconic of it. 🫶

If init peeps that it's continuously respawning an entry more than 10 times in 2 minutes, it goes "hmm. that's not a program, that's a typo" and assumes there's an error in the command string. Then it does three things, no hesitation:

  1. Generates an error message on the system console 📢
  2. Refuses to respawn this entry until either 5 minutes has elapsed or it receives a signal
  3. Just. Stops. Feeding the chaos. ✋
And why, you ask? Because it prevents init from eating up system resources when someone makes a typographical error in the /etc/inittab file or the program for the entry is removed. 💀 Fr fr, one missing letter and the whole box is fighting for its life — init said not on my watch.

So yeah. If your console is screaming at you, that's not a glitch, that's init doing damage control. Respect the boundaries. 💅

👑 AUTHOR 👑

The masterminds behind all of this, the ones who looked at process supervision and said "bet":

  • Miquel van Smoorenburg
  • Michael Haardt

Legends. Absolutely ate. No notes. 🌟

🔍 SEE ALSO 🔍

The extended universe, if you wanna keep the rabbit hole going (and you should):

And that's the whole page, bestie!! You made it to the end, I'm so proud of you 😭💖 This little masterpiece is from the sysvinit package, dated 29 Jul 2004, and it lives at INIT(8). Go forth and init responsibly. Slay, reboot, repeat. 🦋✨🎀

📦 where this page comes from