Poor systemd
has had its share of detractors, but it seems to be here to stay for Linux admins so we might as well get used to it. This handy systemd
command reference will help you keep your sanity when trying to perform normal administrative tasks. So, until we get something that's more usable, palatable, and desirable than systemd
, please enjoy this list of ten handy commands for your convenience. These commands are in no particular order of importance or relevance.
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-files
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount disabled
brandbot.path disabled
systemd-ask-password-console.path static
systemd-ask-password-plymouth.path static
systemd-ask-password-wall.path static
session-1.scope static
arp-ethers.service disabled
auditd.service enabled
autovt@.service enabled
<many more entries>
Of course, you can always pipe to grep
to see just the enabled services.
$ systemctl list-unit-files |grep enabled
auditd.service enabled
autovt@.service enabled
crond.service enabled
dbus-org.fedoraproject.FirewallD1.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
firewalld.service enabled
getty@.service 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 have
been replaced by native systemd services files. Service files provide
very similar functionality to init scripts. To make use of service
files simply invoke "systemctl", which will output a list of all
currently running services (and other units). Use "systemctl
list-unit-files" to get a listing of all known unit files, including
stopped, disabled and masked ones. Use "systemctl start
foobar.service" and "systemctl stop foobar.service" to start or stop a
service, respectively. For further details, please refer to
systemctl(1).
Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into 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.
$ sudo systemctl status sshd
[sudo] password for khess:
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-04-29 07:44:57 CDT; 2h 17min ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1055 (sshd)
CGroup: /system.slice/sshd.service
└─1055 /usr/sbin/sshd -D
Apr 29 07:44:57 centos7 systemd[1]: Starting OpenSSH server daemon...
Apr 29 07:44:57 centos7 sshd[1055]: Server listening on 0.0.0.0 port 22.
Apr 29 07:44:57 centos7 sshd[1055]: Server listening on :: port 22.
Apr 29 07:44:57 centos7 systemd[1]: Started OpenSSH server daemon.
Apr 29 07:51:35 centos7 sshd[1396]: Accepted password for khess from 192.168.1.85 port 56769 ssh2
I like systemd's status because of the detail given. For example, in the above listing, you see the full path to the unit file, the status, the start command, and the latest status changes.
[ Want to try out Red Hat Enterprise Linux? Download it now for free. ]
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. ]
About the author
Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization.
Follow him on Twitter: @kenhess for a continuous feed of Sysadmin topics, film, and random rants.
In the evening after Ken replaces his red hat with his foil hat, he writes and makes films with varying degrees of success and acceptance. He is an award-winning filmmaker who constantly tries to convince everyone of his Renaissance Man status, also with varying degrees of success and acceptance.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit