Chapter 4: Controlling systemd Services
Now that we've seen what systemd services are, it's time to learn how to control them. In this chapter, we're going to do just that. Specifically, we'll cover the following skills:
- Verifying the status of a service
- Starting, stopping, and reloading services
- Enabling and disabling services
- Killing a service
- Masking services
These are good skills to have, because you'll be practicing them a lot in your routine as a Linux server administrator. So, if you're ready, let's get started.
Technical requirements
All you need for this chapter is a virtual machine of some sort, with full sudo privileges for your own user account. For my demos, I'll be using the brand-new AlmaLinux 8 for the Red Hat (RHEL) side of things and Ubuntu Server 20.04 for the Ubuntu side.
Check out the following link to see the Code in Action video: https://bit.ly/3oev29P
A word about CentOS Linux
I know, you're probably used to seeing CentOS Linux for these demos. But, at the end of 2020, the Red Hat company announced that they would end support for the enterprise-ready version of CentOS 8 at the end of 2021. Its replacement, CentOS Stream, is a rolling-release distro that you might not want to use in the enterprise. Fortunately, there are suitable enterprise-ready replacements for CentOS 8 from other organizations, which include Oracle Enterprise Linux 8, Springdale Linux 8, and Alma Linux 8. At the time of writing, Rocky Linux 8 is in the planning stages and will eventually be released by a founder of the original CentOS project. At this point, it's impossible to know which one will become the most popular replacement for CentOS. (Of course, there's also Red Hat Enterprise Linux 8 (RHEL 8), but you'll need to purchase a subscription in order to do anything meaningful with it.)
This is going to be hands-on, folks. So, if you're feeling spry, fire up a virtual machine and follow my lead.
Verifying the status of a service
I'll be using Alma Linux for this first demo, for a reason that will become clear in just a moment. First, let's install the Apache web server by doing the following:
sudo dnf install httpd
Before you can start using Apache, you'll want to know whether it's enabled, so that it will automatically start when you reboot the machine. You'll also want to know whether it's active, which just means that it's running.
To see whether it's enabled, do the following:
[donnie@localhost ~]$ systemctl is-enabled httpd
[sudo] password for donnie:
disabled
[donnie@localhost ~]$
Here, you see why I'm using a RHEL-type distro for this. When you install a service on any RHEL-type machine, it's normally disabled by default. When you install a service on Ubuntu, it's normally enabled by default. So, by doing this on Alma Linux, I can give you more to look at.
Next, let's see whether Apache is running, by doing the following:
[donnie@localhost ~]$ systemctl is-active httpd
inactive
[donnie@localhost ~]$
Okay, it isn't. Now, let's look at both things at once:
[donnie@localhost ~]$ systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: man:httpd.service(8)
[donnie@localhost ~]$
There are a couple of things that I want you to note about these commands. Firstly, if you just want to view information about services, you don't need sudo privileges. Secondly, if you want to do anything with a service, you don't need to append the .service filename extension. I mean, you can if you want to, and it won't hurt anything, but you don't have to. If there are multiple types of unit files with the same name, systemctl will always invoke the .service unit by default. For example, the Common Unix Printing System (CUPS) has a .service unit, a .path unit, and a .socket unit, as you can see here:
[donnie@localhost ~]$ ls -l /lib/systemd/system/cups.*
-r--r--r--. 1 root root 142 Aug 27 2020 /lib/systemd/system/cups.path
-r--r--r--. 1 root root 248 Aug 27 2020 /lib/systemd/system/cups.service
-r--r--r--. 1 root root 136 Aug 27 2020 /lib/systemd/system/cups.socket
[donnie@localhost ~]$
Without a filename extension, systemctl will show information about cups.service, as shown next:
[donnie@localhost ~]$ systemctl status cups
cups.service - CUPS Scheduler
Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-03-30 16:37:18 EDT; 33min ago
Docs: man:cupsd(8)
Main PID: 989 (cupsd)
Status: "Scheduler is running..."
Tasks: 1 (limit: 11274)
Memory: 3.2M
CGroup: /system.slice/cups.service
└─989 /usr/sbin/cupsd -l
Mar 30 16:37:18 localhost.localdomain systemd[1]: Starting CUPS Scheduler...
Mar 30 16:37:18 localhost.localdomain systemd[1]: Started CUPS Scheduler.
Mar 30 16:38:14 localhost.localdomain cupsd[989]: REQUEST localhost - - "POST / HTTP/1.1" 200 362 Create-Printer-Subscriptions successful-ok
[donnie@localhost ~]$
This shows a lot more information about a running service than what the is-active option does. The cups.service - CUPS Scheduler line at the top comes from the Description=CUPS Scheduler line in the [Unit] section of the cups.service file, and information about the man page comes from the Documentation=man:cupsd(8) line. The Main PID: line shows that the main CUPS process has a Process Identification Number (PID) of 989. Verify that with this handy ps aux command:
[donnie@localhost ~]$ ps aux | grep 'cups'
root 989 0.0 0.5 340316 10196 ? Ss 16:37 0:00 /usr/sbin/cupsd -l
donnie 8352 0.0 0.0 221904 1072 pts/1 R+ 18:02 0:00 grep --color=auto cups
[donnie@localhost ~]$
Yes indeed, it is PID 989.
Don't worry about that CGroup: line for now. We'll talk about cgroups later.
The final thing you see is system log entries that got created when the service started. On a RHEL-type system, you'll see them in the /var/log/messages file. On Debian and its offspring, such as Ubuntu, you'll see them in the /var/log/syslog file.
To see information about the other types of units, you'll need to append the filename extension, as shown:
[donnie@localhost ~]$ systemctl status cups.path
cups.path - CUPS Scheduler
Loaded: loaded (/usr/lib/systemd/system/cups.path; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-03-30 16:37:12 EDT; 1h 16min ago
Mar 30 16:37:12 localhost.localdomain systemd[1]: Started CUPS Scheduler.
[donnie@localhost ~]$
This makes for a shorter display, since there's less to show about .path units.
All right, we're off to a good start. Let's get back to that Apache service and see what we can do with it.
Starting, stopping, and reloading services
We've already seen that when you install a service on a RHEL-type distro, such as Alma Linux, the service is normally disabled and not active by default. So now, I'll give you three guesses about what the command is to start a service.
Give up? Okay, here's how we start Apache:
[donnie@localhost ~]$ sudo systemctl start httpd
[sudo] password for donnie:
[donnie@localhost ~]$
Well, that's easy enough. Let's take a look at the status. Here's the first part of the command output:
[donnie@localhost ~]$ sudo systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2021-03-30 18:35:05 EDT; 1min 8s ago
Docs: man:httpd.service(8)
Main PID: 8654 (httpd)
Status: "Running, listening on: port 80"
. . .
. . .
You see here that the service is active, but that it's also still disabled. This means that if I were to reboot the machine, the service won't automatically start. To see more information, use the ps aux command, as follows:
[donnie@localhost ~]$ ps aux | grep httpd
root 8654 0.0 0.6 275924 11196 ? Ss 18:35 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8655 0.0 0.4 289796 8160 ? S 18:35 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8656 0.0 0.5 1347588 10032 ? Sl 18:35 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8657 0.0 0.5 1347588 10032 ? Sl 18:35 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8658 0.0 0.6 1478716 12080 ? Sl 18:35 0:00 /usr/sbin/httpd -DFOREGROUND
donnie 8924 0.0 0.0 221904 1044 pts/1 R+ 18:39 0:00 grep --color=auto httpd
[donnie@localhost ~]$
The first process listed here as PID 8654 belongs to the root user and is the main process that we see in the systemctl status output. The next four processes, with PIDs 8655 through 8658, are used whenever someone connects to a website on this server and belong to the non-privileged apache user. This is a security feature that's been built into Apache for pretty much forever and has nothing to do with systemd. Running these processes under a non-privileged user account helps prevent attackers from taking over the system for their own nefarious purposes.
Note
If you want to see what the rest of the ps output means, view the ps man page by doing:
man ps
To stop the Apache service, just do sudo systemctl stop httpd. (Yeah, I bet you didn't see that one coming.)
If you change the configuration of a running service, you'll need to reload it. You can do that with the restart option, which will restart the service and cause the new configuration to be reloaded. Certain services, such as Apache, also have the reload option. This will read in the new configuration without interrupting the running service. Be aware, though, that you can't always use reload. With Apache, for example, you can use reload to reload changes to website configuration files, but you'll need to use restart to read in certain changes to the Apache configuration, such as when you enable or disable an Apache module. To see whether reload works for any particular service, try consulting the documentation for that service.
The specific commands to start, stop, restart, or reload a service can be defined in its associated .service file. Here are the relevant lines from the httpd.service file on the Alma machine:
[Service]
. . .
. . .
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
. . .
. . .
For now, don't worry about what the start and reload options you see here mean, because that knowledge is specific to Apache, rather than to systemd. What I do want you to notice is the ExecReload= line. We see here that Apache has its own built-in way of reloading its configuration. Contrast that with what you see in this sshd.service file, which is also from the Alma machine:
[Service]
. . .
. . .
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
. . .
. . .
Here, we see that the Secure Shell service doesn't have its own internal mechanism for reloading its configuration. Instead, it relies on the old-fashioned kill utility that's been in Linux almost forever. Realize though that kill doesn't always mean to kill. When you use the kill utility, it sends a signal to a process to make it do something. Normally, you would send a signal that really would kill the process. But you can also use it to send the HUP signal to a service, which will cause the service to reload its configuration without service interruption. (In case you're wondering, HUP is an acronym for Hang Up. The original purpose of this signal was to inform running programs when a serial line was dropped. However, the purpose of the HUP signal has since been changed to what it is now.) The $MAINPID instance that you see is an environmental variable that systemd uses to access the PID number of the main Secure Shell process.
Optionally, you can have a line that defines what happens when you issue a stop command. You don't see that here on Alma Linux, but you do see it in the apache2.service file on Ubuntu as shown here:
[Service]
. . .
. . .
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl stop
ExecReload=/usr/sbin/apachectl graceful
. . .
. . .
You haven't seen an ExecRestart= parameter, because there isn't one. Restarting a service just consists of stopping it, and then starting it again.
Next up, we'll look at how to enable and disable services.
Enabling and disabling services
It's all well and good that we have Apache running, but if we were to reboot our Alma Linux machine, Apache won't start until you start it manually. To begin this demo, first stop Apache with this:
sudo systemctl stop httpd
Now, enable it by doing this:
[donnie@localhost ~]$ sudo systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[donnie@localhost ~]$
When we enable the Apache service, we create a symbolic link in the /etc/systemd/system/multi-user.target.wants/ directory that points back to the httpd.service file. Now, I've been telling you all along that the unit files are in the /lib/systemd/system/ directory. But the eagle-eyed among you will notice that the symbolic link points to the service file in the /usr/lib/systemd/system/ directory. That's because the newer versions of many Linux distros have gotten rid of certain top-level directories and now just use the corresponding directories that have always been under the /usr/ directory. But the Linux gurus in the sky have been nice enough to accommodate old codgers like me who are used to having those top-level directories. They did this by creating symbolic links in the root level of the filesystem, which you can see here:
[donnie@localhost /]$ pwd
/
[donnie@localhost /]$ ls -l lib*
lrwxrwxrwx. 1 root root 7 Aug 14 2020 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Aug 14 2020 lib64 -> usr/lib64
[donnie@localhost /]$
So, if you're like me and keep forgetting that those top-level directories are no longer there, it's okay. The symbolic links work just fine. But, I digress.
Go into the /etc/systemd/system/multi-user.target.wants/ directory, and you'll see the symbolic link that got created with our systemctl enable command, as shown here:
[donnie@localhost ~]$ cd /etc/systemd/system/multi-user.target.wants/
[donnie@localhost multi-user.target.wants]$ ls -l httpd.service
lrwxrwxrwx. 1 root root 37 Mar 30 19:22 httpd.service -> /usr/lib/systemd/system/httpd.service
[donnie@localhost multi-user.target.wants]$
Okay, so you're now wondering what that multi-user.target.wants thing is all about. Well, I'll cover the .target concept in detail later. For now, just accept that the multi-user target is the runlevel in which the operating system is fully booted and is ready for normal operations. The /etc/systemd/system/multi-user.target.wants/ directory contains the symbolic links for units that will automatically start whenever the operating system goes into multi-user mode. This directory mostly contains symbolic links to service units, but it can sometimes have links to other types of units. On this Alma Linux machine, there's also a link to the cups.path unit, as shown here:
[donnie@localhost multi-user.target.wants]$ ls -l cups*
lrwxrwxrwx. 1 root root 33 Feb 11 18:14 cups.path -> /usr/lib/systemd/system/cups.path
lrwxrwxrwx. 1 root root 36 Feb 11 18:14 cups.service -> /usr/lib/systemd/system/cups.service
[donnie@localhost multi-user.target.wants]$
To determine where a symbolic link should be created, the systemctl enable command pulls in the setting from the [Install] section of the service file. At the bottom of the httpd.service file on the Alma machine, you see this:
. . .
. . .
[Install]
WantedBy=multi-user.target
At the bottom of the accounts-daemon.service file, you'll see this:
. . .
. . .
[Install]
WantedBy=graphical.target
The symbolic link for this service, when it's enabled, is in the /etc/systemd/system/graphical.target.wants/ directory.
Be aware that when you enable a service that isn't already running, the service doesn't automatically start until you reboot the machine. You can see that here:
[donnie@localhost multi-user.target.wants]$ systemctl is-enabled httpd
enabled
[donnie@localhost multi-user.target.wants]$ systemctl is-active
httpd
inactive
[donnie@localhost multi-user.target.wants]$
You can issue a separate start command to start the service, or you can use the enable --now option to enable and start the service with just a single command, as shown here:
[donnie@localhost multi-user.target.wants]$ sudo systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[donnie@localhost multi-user.target.wants]$
When you disable a unit, the symbolic link for it gets removed. We can see that here with the Apache service:
[donnie@localhost multi-user.target.wants]$ sudo systemctl disable httpd
[sudo] password for donnie:
Removed /etc/systemd/system/multi-user.target.wants/httpd.service.
[donnie@localhost multi-user.target.wants]$ ls -l httpd*
ls: cannot access 'httpd*': No such file or directory
[donnie@localhost multi-user.target.wants]$
If the service is running, it will remain running after you issue the disable command. You can issue a separate stop command or use the disable --now option to disable and stop the service at the same time.
Now, for you Ubuntu fans, here's the command to install Apache on your Ubuntu machine:
sudo apt install apache2
If you look at the official documentation on the Apache website, you'll see that the official way of doing business is to have httpd as the name of the Apache service. For some strange reason that I've never figured out, Debian developers have always marched to the beat of a different drummer in a few different ways. Ubuntu is derived from Debian, so Ubuntu developers generally carry on with Debian traditions. At any rate, you can try out the preceding commands on an Ubuntu machine and just replace httpd with apache2. The only real difference you'll see is that after you initially install Apache on Ubuntu, the service will already be enabled and running.
Another cool thing you can do is to disable the manual start, stop, and restart functions of a service. The best example of this is the auditd service on RHEL-type machines. In the [Unit] section of the auditd.service file on my Alma machine, we see the line that does that:
[Unit]
. . .
. . .
RefuseManualStop=yes
. . .
. . .
Trying to restart the service gives me the following error message:
[donnie@localhost ~]$ sudo systemctl restart auditd
Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status auditd.service' for details.
[donnie@localhost ~]$
Curiously, though, I can manually stop or restart the auditd service just fine if I use the old-fashioned service command from the SysV days, as we see here:
[donnie@localhost ~]$ sudo service auditd restart
Stopping logging: [ OK ]
Redirecting start to /bin/systemctl start auditd.service
[donnie@localhost ~]$
I can understand why we'd want to restrict the ability to stop or restart auditd, since it is related to system security. But I've never understood why RHEL maintainers prevent users from doing it with systemctl, yet still allow us to do it with service. It's just one of those things that makes you go Hmmmmm. It's also interesting to note that when you install auditd on Ubuntu, you won't see the line that disables these functions. So, on Ubuntu, you can stop and restart auditd with systemctl in the normal manner.
Next, let's look at the proper way to kill a service.
Killing a service
It's sad, I know, but even on Linux things can sometimes crash. A great example is the Firefox web browser. Have you ever accidentally landed on a malicious web page that completely locked up your browser? I mean, you can't close the tab, there's an obnoxious noise blaring out of your computer speakers, and you can't close the browser in the normal way. You're just stuck. (Don't be embarrassed about it if you have, it's happened to all of us.) On a Linux machine, you'd get out of that by opening a terminal, using ps aux | grep firefox to find the PID for Firefox, and then issuing a kill command. For example, let's say that the PID for Firefox is 3901. To kill it, just do:
kill 3901
By default, this will send a number 15, or SIGTERM, signal to Firefox, which will give the process a chance to clean up after itself by shutting down any associated files or network connections. Sometimes, if a process is locked up really badly, the number 15 signal won't do the trick. For times like these, you'll need to pop the cork off a bottle of strong medicine and use the number 9, or SIGKILL, signal, like so:
kill -9 3901
The number 9 signal is something you don't want to use unless you absolutely have to. It stops processes dead in their tracks, without giving them time to clean up after themselves.
Note
For more information about the various Linux signals, you'll want to look at the signal man page on your Ubuntu machine. (For some reason, the man page on the Alma Linux machine doesn't have nearly as much information.) The command is:
man signal
Back in the SysV days, you would use the same method to kill troublesome services, except that you'd need sudo privileges to do it, because services don't run under your own user account. The problem with that is that some services spawn more than one active process, and a normal kill command might not shut them all down. Those services might linger on as zombie processes until the operating system finally reaps them and gets rid of them. (When I say reaps, think of the Grim Reaper who drives stakes into the hearts of zombies to finally kill them off. Oh, wait. The stake in the heart thing is for vampires, so never mind.) A good example of this would be the Apache service. We've already seen that the Apache service spawns multiple processes when it starts, and that's just on a machine that isn't yet running active websites. On an actual production web server, Apache might spawn multiple other processes for CGI scripts, PHP scripts, or whatever else. If you ever need to kill Apache, you'll want to make sure that those script processes also get killed, especially if they might be doing something malicious. On my Ubuntu machine with systemd, I'll do that with the sudo systemctl kill apache2 command. The results should look like this:
donnie@ubuntu2004:~$ systemctl is-active apache2
active
donnie@ubuntu2004:~$ sudo systemctl kill apache2
donnie@ubuntu2004:~$ systemctl is-active apache2
inactive
donnie@ubuntu2004:~$
As with the normal kill command, this sends a number 15, or SIGTERM, signal by default. If you need to send another signal, use the -s option along with the signal name. To see what happens with that, I'll start Apache back up on my Ubuntu machine, and send it the number 9, or SIGKILL signal, like this:
donnie@ubuntu2004:~$ systemctl is-active apache2
active
donnie@ubuntu2004:~$ sudo systemctl kill -s SIGKILL apache2
donnie@ubuntu2004:~$ systemctl is-active apache2
active
donnie@ubuntu2004:~$
Oh, dear. That didn't do anything for us, did it? To see why, let's look in the apache2.service file. In the [Service] section, you'll find the answer:
[Service]
. . .
. . .
Restart=on-abort
The last line in the [Service] section, the Restart=on-abort line, causes Apache to automatically restart if it receives an unclean kill signal. It so happens that SIGKILL is considered unclean. You can see the explanation for this in the systemd.service man page. Open the page and scroll down to Table 2, and you'll find the different options for the Restart= parameter as follows:
Figure 4.1 – Table 2 from the systemd.service man page
In the paragraphs just above and just below Table 2, you'll see explanations for the different options and how they affect using the various kill signals.
Back on the Alma Linux machine, things are a bit different. In its httpd.service file, there's no Restart= line. Instead, we see these lines:
[Service]
. . .
. . .
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
The KillSignal= line changes the default kill action from SIGTERM to SIGWINCH. This is curious, because SIGWINCH is supposed to kill a process only if the terminal window from which the process is running gets resized. Apache normally doesn't run from a terminal window. Still, somebody at Red Hat apparently decided that SIGWINCH would be the appropriate signal for killing Apache gracefully, so that's how it is. The KillMode=mixed line tells systemd to send a SIGTERM signal to the main Apache process but to send SIGKILL to the remaining processes in the Apache control group. The systemd.kill man page doesn't say what this line does when the preceding KillSignal= line is set to SIGWINCH, but I would assume that it will replace SIGTERM with SIGWINCH. Anyway, let's try to kill Apache on the Alma machine, just to see what happens:
[donnie@localhost ~]$ systemctl is-active httpd
active
[donnie@localhost ~]$ sudo systemctl kill httpd
[sudo] password for donnie:
[donnie@localhost ~]$ systemctl is-active httpd
inactive
[donnie@localhost ~]$
It looks just the same as it did on the Ubuntu machine. Send Apache a SIGKILL though, and you'll see something different as shown here:
[donnie@localhost ~]$ sudo systemctl kill -s SIGKILL httpd
[donnie@localhost ~]$ systemctl is-active httpd
failed
[donnie@localhost ~]$
Without the Restart=on-abort line that Ubuntu has in its apache2.service file, the Apache service on Alma won't automatically restart when it receives the SIGKILL signal. Note that the is-active output shows failed rather than inactive, as it does when you use SIGTERM or SIGWINCH. Either way, the service isn't running, so the end result is the same.
Okay, that's all good. But what if you want to prevent a service from ever running? Well, you'd mask it, which is what we'll look at next.
Masking a service
Now, let's say that you have a service that you never want to start, either manually or automatically. You can accomplish this by masking the service, like this:
[donnie@localhost ~]$ sudo systemctl mask httpd
Created symlink /etc/systemd/system/httpd.service → /dev/null.
[donnie@localhost ~]$
This time, instead of creating a symbolic link that points back to the service file, we've created one that points to the /dev/null device. Let's try to start our masked Apache service to see what happens:
[donnie@localhost ~]$ sudo systemctl start httpd
Failed to start httpd.service: Unit httpd.service is masked.
[donnie@localhost ~]$
If you change your mind, just use the unmask option.
Summary
We've covered a good bit of ground in this chapter, and even got to do some cool hands-on stuff. We looked at how to start, stop, restart, and reload services. We also looked at how to enable and disable services and looked at the symbolic links that get created when we enable a service. We wrapped things up by showing how to kill a service, and then how to mask a service. As a side benefit, we saw what some service parameters can do for us and how the maintainers of different Linux distros can set up services to behave differently on different distros.
But what if you don't like the way that a service is set up on the distro that you're using? No worries. We'll discuss that in the next chapter, when we talk about editing and creating service unit files. I'll see you there.
Questions
- When you run the sudo systemctl enable httpd command, what will that do for you?
a. It will start the httpd service.
b. It will cause httpd to start when you boot the machine and will also do an immediate start.
c. It will only cause httpd to start when you reboot the machine.
d. It creates a symbolic link in the /lib/systemd/system/ directory.
- What is the effect of using the normal kill command on a service?
a. It will shut down the service cleanly.
b. It will shut down the main service process, but it might not shut down the spawned processes.
c. It won't shut down a service.
d. You can use kill without sudo privileges to shut down a service.
- What is the SIGTERM signal?
a. It kills a process dead in its tracks without giving it a chance to clean up after itself.
b. It kills a process when it detects that a terminal window has been resized.
c. It restarts a process.
d. It kills a process gracefully, giving it time to clean up after itself.
- How would you enable and start the httpd service with just one command?
a. You can't
b. sudo systemctl enable httpd
c. sudo systemctl start httpd
d. sudo systemctl start --now httpd
e. sudo systemctl enable --now httpd
- What does the ExecRestart= parameter do for us?
a. It defines how to restart the service.
b. It defines how to reload the service configuration.
c. Nothing, because this parameter doesn't exist.
d. It defines how to start a service.
Answers
- c
- b
- d
- e
- c
Further reading
My Managing Services video: https://youtu.be/IuDmg75n6FU
How to manage systemd services: https://www.howtogeek.com/216454/how-to-manage-systemd-services-on-a-linux-system/