INITTAB(5)

📦
version 3.14 · 3 versions
, in debian trixie

💖 NAME 💖

inittab — the format of the inittab file that the sysv-compatible init process reads, bestie. It's the blueprint, the vibe document, the main character of your boot sequence.

✨ DESCRIPTION ✨

Okay so real talk: the inittab file is literally the group chat where your system decides which processes get started at bootup and during normal operation. We're talking stuff like /etc/init.d/boot, /etc/init.d/rc, gettys, all of it. 🎀

init(8) distinguishes multiple runlevels, and each one can have its own little set of processes that get started. Valid runlevels are 0-6 plus A, B, and C for ondemand entries. No cap. 💅

An entry in the inittab file has this format:

id:runlevels:action:process

Lines beginning with # are ignored (they're just, like, commentary — the notes app of the file).

  • id — a unique sequence of 1-4 characters that identifies an entry in inittab. Heads up though: for versions of sysvinit compiled with the old libc5 (< 5.2.18) or a.out libraries, the limit is 2 characters. Tragic but true.

Note: traditionally, for getty and other login processes, the value of the id field is kept the same as the suffix of the corresponding tty, e.g. 1 for tty1. Some ancient login accounting programs might expect this, though honestly I can't think of any. 🙈

  • runlevels — lists the runlevels for which the specified action should be taken.
  • action — describes which action should be taken.
  • process — specifies the process to be executed. If the process field starts with a + character, init will not do utmp and wtmp accounting for that process. This is needed for gettys that insist on doing their own utmp/wtmp housekeeping. This is also a historic bug, fr fr. The length of this field is limited to 253 characters. Anything beyond 253 will result in a log warning and the process command line being skipped/ignored. 😭

Please note that including certain characters in the process field will result in init attempting to launch a shell to interpret the command contained in the process field. The characters which will trigger a shell are:

~`!$^&*()=|}[];"'<>?

On systems which do not have a shell to be launched, or which do not wish to use a shell to interpret the process field, the process field can be prefixed with the @ symbol. The @ will be ignored and everything followed will be treated as a command to be launched, literally, by the init service. 🫶

In cases where both a + and @ sign are to be used (to turn off logging and shell interpretation), place the + sign before the @ symbol. Both flags will be handled and then everything following the @ will be handled by init.

The runlevels field may contain multiple characters for different runlevels. For example, 123 specifies that the process should be started in runlevels 1, 2, and 3. The runlevels for ondemand entries may contain an A, B, or C. The runlevels field of sysinit, boot, and bootwait entries is ignored.

⚠️ When the system runlevel is changed, any running processes that are not specified for the new runlevel are killed — first with SIGTERM, then with SIGKILL. It's giving eviction notice, then it's giving no notice. 💀

🦋 Valid actions for the action field 🦋

  • respawn — the process will be restarted whenever it terminates (e.g. getty). It simply refuses to stay gone. Iconic behaviour honestly.
  • wait — the process will be started once when the specified runlevel is entered, and init will wait for its termination.
  • once — the process will be executed once when the specified runlevel is entered.
  • boot — the process will be executed during system boot. The runlevels field is ignored.
  • bootwait — the process will be executed during system boot, while init waits for its termination (e.g. /etc/rc). The runlevels field is ignored.
  • off — this does nothing. Literally nothing. The void entry. 🕳️
  • ondemand — a process marked with an ondemand runlevel will be executed whenever the specified ondemand runlevel is called. However, no runlevel change will occur (ondemand runlevels are a, b, and c).
  • initdefault — an initdefault entry specifies the runlevel which should be entered after system boot. If none exists, init will ask for a runlevel on the console. The process field is ignored.
  • sysinit — the process will be executed during system boot. It will be executed before any boot or bootwait entries. The runlevels field is ignored.
  • powerwait — the process will be executed when the power goes down. init is usually informed about this by a process talking to a UPS connected to the computer. init will wait for the process to finish before continuing.
  • powerfail — as for powerwait, except that init does not wait for the process's completion.
  • powerokwait — this process will be executed as soon as init is informed that the power has been restored.
  • powerfailnow — this process will be executed when init is told that the battery of the external UPS is almost empty and the power is failing (provided that the external UPS and the monitoring process are able to detect this condition).
  • ctrlaltdel — the process will be executed when init receives the SIGINT signal. This means that someone on the system console has pressed the CTRL-ALT-DEL key combination. Typically one wants to execute some sort of shutdown, either to get into single-user level or to reboot the machine.
  • kbrequest — the process will be executed when init receives a signal from the keyboard handler that a special key combination was pressed on the console keyboard.

The documentation for this function is not complete yet; more documentation can be found in the kbd-x.xx packages (most recent was kbd-0.94 at the time of this writing). Basically you want to map some keyboard combination to the "KeyboardSignal" action. For example, to map Alt-Uparrow for this purpose use the following in your keymaps file:

alt keycode 103 = KeyboardSignal

🌈 EXAMPLES 🌈

This is an example of a inittab which resembles the old Linux inittab:

# inittab for linux
id:1:initdefault:
rc::bootwait:/etc/rc
1:1:respawn:/etc/getty 9600 tty1
2:1:respawn:/etc/getty 9600 tty2
3:1:respawn:/etc/getty 9600 tty3
4:1:respawn:/etc/getty 9600 tty4

This inittab file executes /etc/rc during boot and starts gettys on tty1-tty4. Simple, clean, slay. ✨

A more elaborate inittab with different runlevels (see the comments inside):

# Level to run in
id:2:initdefault:

# Boot-time system configuration/initialization script.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# What to do at the "3 finger salute".
ca::ctrlaltdel:/sbin/shutdown -t1 -h now

# Runlevel 2,3: getty on virtual consoles
# Runlevel   3: getty on terminal (ttyS0) and modem (ttyS1)
1:23:respawn:/sbin/getty tty1 VC linux
2:23:respawn:/sbin/getty tty2 VC linux
3:23:respawn:/sbin/getty tty3 VC linux
4:23:respawn:/sbin/getty tty4 VC linux
S0:3:respawn:/sbin/getty -L 9600 ttyS0 vt320
S1:3:respawn:/sbin/mgetty -x0 -D ttyS1

🎀 FILES 🎀

  • /etc/inittab

👑 AUTHOR 👑

init was written by Miquel van Smoorenburg. This manual page was written by Sebastian Lederer and modified by Michael Haardt. Giving credit where credit is due, periodt. 🫶

🔥 SEE ALSO 🔥

okay bestie that's the whole thing, you're officially an inittab girlie now 💜 this was sysvinit, dated Dec 4, 2001, and yes it's INITTAB(5) — go forth and boot responsibly, mwah 😘

📦 where this page comes from