10 handy systemd commands: A reference (2024)

Posted: May 19, 2020 | | by Ken Hess (Sudoer alumni)

10 handy systemd commands: A reference (1)

List unit files

From the systemd man page: A unit file is a plain text ini-style file that encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd, a resource management slice, or a group of externally created processes.

$ systemctl list-unit-filesUNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount staticproc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount disabledbrandbot.path disabledsystemd-ask-password-console.path static systemd-ask-password-plymouth.path static systemd-ask-password-wall.path static session-1.scope static arp-ethers.service disabledauditd.service [email protected] enabled<many more entries>

Of course, you can always pipe to grep to see just the enabled services.

$ systemctl list-unit-files |grep enabledauditd.service enabled [email protected] enabled crond.service enabled dbus-org.fedoraproject.FirewallD1.service enabled dbus-org.freedesktop.nm-dispatcher.service enabled firewalld.service enabled [email protected] enabled irqbalance.service enabled kdump.service enabled lvm2-monitor.service enabled <many more entries>

These unit files, located under /lib/systemd/system, are roughly equivalent to the legacy init scripts that were located under /etc/rc.d/init.d. In fact, if you or your software installation create init scripts, a corresponding systemd unit file is mapped for you. A further explanation is given by /etc/rc.d/init.d/README:

You are looking for the traditional init scripts in /etc/rc.d/init.d,and they are gone?Here's an explanation on what's going on:You are running a systemd-based OS where traditional init scripts havebeen replaced by native systemd services files. Service files providevery similar functionality to init scripts. To make use of servicefiles simply invoke "systemctl", which will output a list of allcurrently running services (and other units). Use "systemctllist-unit-files" to get a listing of all known unit files, includingstopped, disabled and masked ones. Use "systemctl startfoobar.service" and "systemctl stop foobar.service" to start or stop aservice, respectively. For further details, please refer tosystemctl(1).Note that traditional init scripts continue to function on a systemdsystem. An init script /etc/rc.d/init.d/foobar is implicitly mappedinto a service unit foobar.service during system initialization.Thank you!Further reading: man:systemctl(1) man:systemd(1) http://0pointer.de/blog/projects/systemd-for-admins-3.html http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

As you can see, init.d has been removed in favor of systemd. It's here to stay until someone comes up with something better. (I'm hoping that someone is rapidly working on a replacement.)

List units

Listing active units displays a lot of useful information about your loaded and active services. The output is too detailed to demonstrate here, but try the following command on your system to see what I mean.

$ systemctl list-units

The status fields are great to see, but the description field is the most useful to me. It provides detailed information about your services.

Start a service

To get a service name, list your unit files and grep for the one you want. Then use the systemctl command to start your service. I'm using firewalld as the example.

$ sudo systemctl start firewalld

Surprisingly, or maybe not so surprisingly, there's no response from starting, stopping, or restarting a service. To check the status of a service, you must use the status command.

Checking a service status

To check a service's status, use the systemctl status service-name command.

Stop a service

Stopping a running service is as easy as starting one.

$ sudo systemctl stop firewalld

Again, you see no response from issuing this command. Issue a service status to check your success or failure.

Restarting a service

If you want to stop and start a service without issuing two commands (sysadmins are a lazy lot, after all), issue a restart.

$ sudo systemctl restart firewalld

No system response is displayed.

System restart, halt, and shutdown

These three tasks are typical ones that sysadmins need to know and are now under the control of systemd.

Reboot

There are multiple ways to restart your systems, but the old standby, reboot, is actually a link to the systemctl command. I assume that since it works, it links the systemctl command with the reboot switch added as follows:

$ sudo systemctl reboot

The same link applies to the halt and to the shutdown commands.

Shutdown and halt

It doesn't matter how you used to do it with halt -p or shutdown now or whatever, the universal command is now:

$ sudo systemctl poweroff

This command powers down the system.

Set services to run at boot time

You're used to the chkconfig command to enable your services to run at boot time and under a particular runlevel. Well, those days too are gone, and they have been usurped by the ubiquitous systemctl command.

Enabling a service to run at boot time

To set any service to start at boot, issue the following command. I'm using firewalld as the example service.

$ sudo systemctl enable firewalld

Disabling a service from running at boot time

To prevent any service from starting at boot time, issue:

$ sudo systemctl disable firewalld

The firewalld service will not start at boot time.

Wrap up

This brief but handy systemd/systemctl reference guide should take some of the pain out of dealing with systemd. That's the theory, at least. And, as you'll often see in my articles or hear me say out loud, "Everything works on paper." Be sure to let me know on Twitter what you think of my articles and also to suggest new topics.

[ Free online course: Red Hat Enterprise Linux technical overview. ]

Topics: Linux