If you’re a Linux admin, you probably remember the old runlevels, which defined a state of initialization the operating system is running in. For example, runlevel 0 was a system halt, runlevel 1 was single-user mode, runlevel 2 was multi-user mode with no network file system, run level 3 was multi-user mode with a text-only interface, run level 4 was user-definable, runlevel 5 was multi-user mode with a GUI and runlevel 6 was reboot.
That was with sysvinit. Now that most Linux distributions have migrated to systemd, you might be curious as to the equivalent run levels. There isn’t a per-level equivalent, because opts to go with target levels, instead of run levels. Because there are only five targets, it doesn’t quite map out perfectly.
SEE: Kubernetes: A cheat sheet (free PDF) (TechRepublic)
However, systemd takes a much more logical approach to runlevels. Here’s how systemd targets track with the old-school runlevels. poweroff.target is shutdown or power off, so it’s akin to runlevel 0. rescue.target launches the rescue shell session, so it’s like runlevel 1. multi-user.target launches the system in non-GUI, multi-user mode, so it’s like run levels 2, 3, and 4. graphical.target launches the system into a GUI, multi-user mode, so it’s like runlevel 5.
Finally, reboot.target shuts down or reboots the system, so it’s like runlevel 6. Most of your systems will use runlevels 3, 4 or 5, which translates to either multi-user.target or graphical.target.
These targets are defined in the systemd startup scripts in /etc/systemd/system and are generally found in the install section, as in WantedBy=multi-user.target.
And those are the systemd equivalents of sysvinit runlevels. Hopefully, this helps to demystify systemd just a bit for you.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.