init

Set the system to run a graphical environment

$ sudo init 5

$ sudo init 3

$ init 0

$ init 6

$ sudo init 1

init [ RUNLEVEL ]
init [ OPTIONS ] (as a symlink to modern init systems)

RUNLEVEL (0-6, s/S)
    Specifies the desired system runlevel. On modern systems, these are mapped to systemd targets.

0
    Halts the system (poweroff.target).

1, s, or S
    Enters single-user mode for maintenance (rescue.target).

2
    Multiuser mode without network filesystems (SysVinit specific, typically multi-user.target).

3
    Full multiuser mode with text-based login (multi-user.target).

4
    Not typically used; user-definable.

5
    Full multiuser mode with graphical login (graphical.target).

6
    Reboots the system (reboot.target).

The init command, short for initialization, is the very first process launched by the kernel during a Unix-like operating system's boot sequence, always assigned Process ID (PID) 1. Historically, it was responsible for reading the /etc/inittab file to determine the system's runlevel and then launching all necessary services and processes based on that configuration. It acted as the parent of all other processes, supervising them and cleaning up after orphaned processes. If init were to terminate, the system would typically panic and halt.

In modern Linux distributions, the traditional SysVinit implementation has largely been superseded by more advanced init systems like systemd (the de-facto standard) or Upstart. On these systems, the init command itself is often a symbolic link to the newer init system's executable (e.g., /sbin/init -> /lib/systemd/systemd). While it retains its PID 1 status and core responsibility for system initialization and service management, the underlying mechanisms and configuration files have evolved. systemd manages system startup, services, logging, device management, and more in a highly parallelized and efficient manner, using "targets" instead of numerical runlevels.

On most contemporary Linux distributions, init is a symbolic link to systemd. Direct invocation of init with runlevel arguments will typically trigger systemd's corresponding target switch. Executing init directly after system boot (e.g., init 6) requires root privileges and will initiate a system-wide action (like rebooting), potentially disrupting user sessions or ongoing processes. Exercise caution.

The init process is unique in that it is always assigned Process ID (PID) 1. This special status means it is the first user-space process and serves as the parent of all other processes. If any process becomes orphaned (its parent terminates), init inherits it.

Historically, init systems like SysVinit used numerical "runlevels" (0-6) to define distinct system states (e.g., single-user, multi-user, graphical). Modern systemd replaces these with named "targets" (e.g., rescue.target, multi-user.target, graphical.target). For backward compatibility, init often still accepts runlevel numbers, which systemd then maps to the appropriate target.

The concept of init originates from early Unix systems developed at Bell Labs, designed to be the first process after the kernel boots. The most widely adopted implementation for many decades was SysVinit (System V init), which relied on the /etc/inittab file and the concept of runlevels to manage services sequentially. While robust, SysVinit's sequential nature could lead to slower boot times.

Starting in the late 2000s, new init systems emerged to address perceived limitations, notably Upstart (developed by Ubuntu) and systemd (primarily by Red Hat). systemd, with its parallelization, cgroups integration, and comprehensive suite of tools, rapidly gained traction and became the default init system for the majority of mainstream Linux distributions (including Fedora, Debian, Ubuntu, CentOS, RHEL, Arch Linux) by the mid-2010s, largely replacing SysVinit and Upstart.

systemd(1), systemctl(1), telinit(8), shutdown(8), reboot(8), runlevel(8)