How Does Linux Boot? Part 6: Replacing init With systemd – What You Need to Know

Last week I mentioned that systemd has replaced the traditional init program in Linux. Let’s see some capabilities it adds!

Systemd organizes tasks into units which can include initializing hardware, mounting file systems, and starting services that will daemonize and run in the background. The active units are those which are enabled (that is, configured to be started within the current run state) and which should have successfully run to completion or still be running as a daemon.

You can list all the active units with this command:

$ systemctl list-units

Some of the units are targets. These are analogous to the run levels in SVR4, but you can tell the system to go to a state combining arbitrarily many targets of arbitrary complexity. The basic ones are rescue.target, multi-user.target, and graphical.target, analogous to the traditional run levels 1, 3, and 5, respectively. These will require (or “want”) other targets to have happened first. Maybe multi-user.target wants nfs-server.target, which in turns needs network.target, and before that, basic.target to do the basic system initialization, local-fs.target to mount the local file systems, and more. You can view a list of the available targets:

$ systemctl --type=target --all
UNIT                   LOAD   ACTIVE   SUB    JOB DESCRIPTION
basic.target           loaded active   active     Basic System
cryptsetup.target      loaded active   active     Encrypted Volumes
emergency.target       loaded inactive dead       Emergency Mode
final.target           loaded inactive dead       Final Step
getty.target           loaded active   active     Login Prompts
graphical.target       loaded active   active     Graphical Interface
local-fs-pre.target    loaded active   active     Local File Systems (Pre)
local-fs.target        loaded active   active     Local File Systems
multi-user.target      loaded active   active     Multi-User
network.target         loaded active   active     Network
nfs.target             loaded active   active     Network File System Client and
nss-lookup.target      loaded active   active     Host and Network Name Lookups
nss-user-lookup.target loaded inactive dead       User and Group Name Lookups
printer.target         loaded active   active     Printer
remote-fs-pre.target   loaded inactive dead       Remote File Systems (Pre)
remote-fs.target       loaded active   active     Remote File Systems
rescue.target          loaded inactive dead       Rescue Mode
rpcbind.target         loaded active   active     RPC Port Mapper
shutdown.target        loaded inactive dead       Shutdown
sockets.target         loaded active   active     Sockets
sound.target           loaded active   active     Sound Card
swap.target            loaded active   active     Swap
sysinit.target         loaded active   active     System Initialization
syslog.target          loaded active   active     Syslog
time-sync.target       loaded active   active     System Time Synchronized
umount.target          loaded inactive dead       Unmount All Filesystems

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

26 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

One of the more impressive commands has a simple directive. Try it on your system, ask about the fundamental network service:

$ systemctl show network

Wow! What a lot of information that command will show! It would take a lot of commands to track down as much of this as really practical on a traditional init system, and you would have to carefully analyze all the output.

You would still end up way short of what you can get with systemctl because, among many other things, systemd has integrated the restriction of resource use through control groups or cgroups into the service control system. We have just started showing people how to control resource utilization with cgroups in Learning Tree’s new Linux optimization and troubleshooting course.

It’s an advanced course and it just started running, I’ve taught the second North American run in New York in January. While many organizations are holding off on moving the Red Hat Enterprise Linux 7 (or the corresponding CentOS 7), I found it interesting how many people wanted to do some bonus exercise work in setting up systemd services controlled by cgroups.

The change from init to systemd is an enormous one. It completely changes system configuration, service control, hardware detection, and more. I have tried to capture the basics in what has turned into a rather large web page. Check out my “phrase book” comparing the syntax of classic init (RHEL 5), Upstart (RHEL 6), and systemd (RHEL 7, Ubuntu, Mageia, SuSE, and most of the other mainstream distros).

And, I hope to see you in one of the Linux courses soon!

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.