init (system)

init (system)
Name	init (system)
Title	init
Developer	Ken Thompson, Dennis Ritchie, Eric S. Raymond, The Linux Foundation, Red Hat, Canonical (company), Debian, systemd developers, Software in the Public Interest
Released	1970s
Latest release	varies
Programming language	C (programming language), Assembly language
Operating system	Unix, Linux kernel, BSD (operating system), MINIX, AIX, HP-UX, Solaris (operating system), FreeBSD
Genre	System software
License	BSD license, GNU General Public License, proprietary

init (system) is the parent process and first user-space program started by the kernel on many Unix-like operating systems, responsible for system initialization, service supervision, and the transition between operational states. It orchestrates boot-time setup, invokes initialization scripts or units, and adopts orphaned processes, forming a critical part of the startup sequence on platforms such as Linux kernel, FreeBSD, NetBSD, OpenBSD, AIX, Solaris (operating system), and MINIX. Implementations vary from classic SysV-style init to modern supervisors like systemd, each reflecting distinct design philosophies and administrative models.

Overview

Init is the canonical ancestor of all user processes, occupying process ID 1 and acting as the bootstrap for higher-level facilities such as cron, sshd, X.Org Server, system logging, and service managers. In traditional Unix systems, init reads configuration from files like /etc/inittab and invokes scripts to start subsystems including networking, filesystem mounting, login (Unix), cron, and udev. Modern implementations integrate with kernel features like cgroups, udev (device manager), and namespaces to provide service isolation, dependency resolution, and parallel startup for desktop environments such as GNOME, KDE, and server stacks like LAMP. As PID 1, init must handle signals, reap zombies from programs like apache httpd, mysqld, and postgresql, and provide a stable environment for long-running daemons including docker, kubelet, and systemd-journald.

History and Evolution

Init origins trace to the early UNIX (1969) heritage created by Ken Thompson and Dennis Ritchie at Bell Labs, evolving through the Sequent and Berkeley Software Distribution lines into diverse implementations. The System V (Unix System V) init model standardized runlevels and /etc/inittab policy used by vendors such as AT&T, Sun Microsystems, and IBM. The BSD (operating system) lineage developed alternatives like simple rc scripts used by FreeBSD and OpenBSD. In the 2000s and 2010s, projects such as upstart from Canonical (company), systemd from Lennart Poettering and Kay Sievers (backed by Red Hat), and runit from smarden introduced event-driven, parallel, and small-footprint approaches respectively. Debates around init design engaged communities at Debian, Ubuntu, Fedora Project, and Gentoo and influenced init adoption in distributions and vendors including Arch Linux, SUSE, CentOS, Red Hat Enterprise Linux, and Alpine Linux.

Design and Operation

Init implementations implement core responsibilities: PID 1 ownership, process reaping, signal handling, dependency resolution, service supervision, and state transitions. Traditional SysV init follows a sequential script model invoking scripts under directories like /etc/rc.d or /etc/init.d to manage services such as sshd, cron, syslogd, dhclient, and NetworkManager. Event-driven designs like upstart react to kernel or userspace events such as udev device notifications, while service managers like systemd model units with explicit dependencies, sockets, timers, and cgroups for deterministic ordering, parallel startup, and resource control. Lightweight supervisors like runit, s6, and daemontools emphasize small codebase, supervision trees, and process restart semantics beneficial for container platforms such as Docker (software) and orchestration systems like Kubernetes. Init must integrate with logging systems like rsyslog, syslog-ng, and journald (systemd), and with authentication services such as PAM and display managers like LightDM.

Implementations and Examples

Notable init implementations include the System V-style sysvinit, the event-based upstart, the extensive systemd, the small-footprint runit, the supervision-focused s6 (software suite), and BSD rc variants in FreeBSD, OpenBSD, and NetBSD. Commercial systems use proprietary or vendor-tuned init systems on AIX, HP-UX, and Solaris (operating system) via SMF (Service Management Facility). Distributions choose implementations to satisfy project goals: Debian and Ubuntu transitioned to systemd after community processes, Gentoo supports both OpenRC and systemd, Alpine Linux prefers OpenRC or runit, and Void Linux uses runit as default. Embedded distributions and real-time variants in fields like automotive and telecommunications often employ minimal supervisors such as busybox init or systemd-embedded forks.

Configuration and Initialization Scripts

Configuration models differ: SysV init uses /etc/inittab and /etc/init.d scripts with runlevel directories like /etc/rc2.d; systemd uses unit files in /etc/systemd/system and /lib/systemd/system with explicit Unit, Service, Socket, and Target sections; upstart uses event-job configuration in /etc/init; runit and s6 use per-service run scripts under /etc/service or /etc/sv. Init scripts commonly invoke utilities like start-stop-daemon, killall, mount(8), ifup, and ifdown to manage services such as cron, ntpd, postfix, exim, dovecot, and cupsd. Administrators interact via tools such as systemctl, service (command), invoke-rc.d, rc-update, and sv to enable, disable, or query unit states, and integrate with package managers including dpkg, apt, rpm, Pacman, and apk (Alpine).

Process Management and Runlevels/Targets

Init defines system states: SysV runlevels (0–6) map to halt, single-user, multiuser, and reboot, while systemd replaces runlevels with targets like graphical.target, multi-user.target, rescue.target, and reboot.target. Supervision semantics determine whether services are transient, forking, or simple, and whether they are respawned on failure; examples include systemd Restart= policies, runit svstat supervision, and s6 service scripts. PID 1 responsibilities include reaping zombies, handling SIGCHLD, propagating SIGTERM for shutdown sequences, and coordinating with kernel facilities such as ACPI events and kexec for advanced transitions. Clustered and cloud environments integrate init behavior with orchestration platforms like Kubernetes, Cloud-init, OpenStack, and configuration management systems such as Ansible, Puppet, Chef, and SaltStack.

Security and Reliability Considerations

As an integral trusted component, init must be secure against privilege escalation, race conditions, and DoS via PID 1 overload. Hardening strategies include minimizing code within PID 1 (as in runit and s6), sandboxing and capabilities with systemd and Linux namespaces, cryptographic verification of unit files and scripts, and SELinux or AppArmor policies developed by NSA-backed projects and distributions like Fedora Project and Ubuntu. Reliability mechanisms include process supervision, automatic restarts, crash loops analysis, and integration with monitoring tools like Nagios, Prometheus, and systemtap. Incident response involves controlled teardown via signals, journaling for forensic logs, and rollback of unit changes coordinated with package rollbacks via rpm-ostree or Timeshift.

Category:Operating system daemons