How to Transition from init to systemd: Controlling Services

Liunx AdministrationLast week I showed you how to determine your current run state and figure out what that really means. Let’s control some services to tune the state of our system!

The systemctl command is the master tool for controlling and querying the systemd system and service manager. Both it and the related journalctl command truncate their very long lines of output, so start by stretching your terminal emulator to the full width of your display.

Systemd deals with units, which include what we normally think of as persistent running services such as the SSH daemon or the Rsyslog daemon, plus events needed for booting like detecting hardware or mounting file systems or configuring network interfaces. Some of our init scripts in the past handled events that are supposed to complete quickly and be done, so there’s nothing new so far.

Units also manage sockets, file system conventional mount points and automounting, initialization of swap areas, timers, temporary system state snapshots, resource management slices, and groups of externally created processes. That is certainly different!

Most of these units are defined by configuration files called unit files. (exceptions can be created automatically by system state or by running programs) Those files, primarily stored in /lib/systemd/system/, are simple ASCII text files based on the syntax of Windows *.ini files. To get the details, see the systemd.unit(5) manual page and the manual pages it references for the twelve specific unit types.

An active unit is one that is running, initialized, plugged in, whatever “active” means for its type, while an inactive one isn’t running or hasn’t otherwise carried out its task. It’s possible that it’s inactive because it started but then failed, something we would like to learn about.

Now for the Syntax!

Let’s investigate! The output can be pretty enormous, so I will show you the syntax of what to try on your system, but I will leave the detailed output for you to discover. You will need to be root for some of these, so go ahead and run su - now.

First, just run systemctl with no options or parameters. You will find that it sends the output through less, so you can page forward and back.

# systemctl

The default action is to list the loaded units. That is, those that successfully completed and exited, plus those that successfully started and continued running as daemons.

Right away we are seeing more than we easily could with the old init system!

You may have noticed some failed services, and if you did notice those among all that output it was probably thanks to the nice color highlighting. Now that you have noticed that some exist, you can ask for a list of just the units in the failed state:

# systemctl --state=failed

To see a list of all available unit files, also including those that weren’t configured to have started, simply ask for them:

# systemctl list-unit-files

Maybe you are working with network services on your system, and you wonder about the status of a few of them. You can get a simple one-word answer with the is-active directive, or more details with the status directive. Make one of those requests while listing just one or as many services as you care to know about. You might start by listing the available choices. You will have to try this sequence on your system to appreciate what it does:

# cd /lib/systemd/system
# ls *.service
# systemctl is-active sshd
# systemctl is-active dhcpd
# systemctl is-active httpd 
# systemctl status sshd dhcpd httpd

The is-active directive would make for a nice test within a shell script. The status output tells us quite a bit more. For example, the httpd service reports total requests and current requests per second and traffic.

The status also opens the door for troubleshooting, as the report is followed by some lines that look like syslog messages. They are, effectively, although they are taken from a closely related mechanism called the journal.

I’ll tell you about the journal next week.

For controlling services right now, you may already anticipate what the syntax will look like:

# systemctl stop httpd
# systemctl start httpd
# systemctl restart httpd
# systemctl reload httpd

That last one signals the service to continue running but re-read its configuration file in order to change how it’s running.

Those commands are very much like running the old init scripts with the same parameters, or using Red Hat’s service command. All of that is to control things right now, stopping and starting and checking the current state.

What about enabling and disabling services for the future, configuring whether they are automatically started after the next reboot? We used to do that with chkconfig but now it’s just further use of systemctl:

# systemctl enable httpd
# systemctl disable dhcpd
# systemctl is-enabled httpd
# systemctl is-enabled dhcpd

There’s much more that you can do with systemctl but this will get you started. The Linux server administration course can give you hands-on experience with this on a server of your own.

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.