---
slug: Managing Systemd Services and Units with Systemctl A Guide
title: Managing Systemd Services and Units with Systemctl A Guide
authors: [slorber]
tags: [hola, docusaurus]
---

<!-- truncate -->
import CodeBlock from '@site/src/components/CodeBloack';


<div className="head">Introduction</div>


<div className="text">Systemd is an important part of many Linux computers. It acts like an organizer that helps your computer work smoothly. Understanding systemd might seem a bit challenging at first, but it's a powerful tool that simplifies managing your computer. Learning about systemd and its tools will give you more control and flexibility over your computer. It's like having a reliable assistant that makes your computer tasks easier. So, let's explore systemd together and see how it can become your computer's helpful companion!</div><br/>

<div className="text">In this guide, we'll explore a command called 'systemctl,' a powerful tool for managing how your computer starts and runs programs. We'll cover how to control programs, check their status, make changes and work with special files that control how everything functions.</div><br/>

<div className="text">Just so you know, not all computers use the same tools. If you come across a message like 'bash: systemctl is not installed,' it means your computer has a different setup. No worries, though – you can still learn a lot from this guide!</div><br/>


<div className="head">Managing Services with Systemctl</div>

<div className="text">The init system is like the manager of your computer. Its main job is to get things ready after you turn on your computer, which we call 'userland' components. It also looks after special helpers called services and daemons while your computer is already up and running. Now, let's jump into some simple ways to take care of these services – it's like learning how to manage different tasks on your computer!</div><br/>


<div className="text">In systemd, everything we want to control is called a 'unit.' Units are like different parts of your computer that systemd knows how to handle. Each unit is put into a group based on what it does, and we describe them using files called unit files. You can tell what type of unit it is by looking at the end of its file name.</div><br/>

<div className="text">When you're managing services, you'll mainly deal with something called 'service units.' These units have files with names ending in .service. But here's something cool: most of the time, you can just leave off the .service part when you're giving commands to systemd. It's clever enough to figure out that you're probably talking about a service!</div><br/>


<div className="text" style={{ fontSize:'28px' }}>Getting Services Going and Turning Them Off</div>

<div className="text">To get a systemd service up and running, you use the start command. If you're not the main user of the computer, you'll need to add sudo before the command, because starting a service can change how the computer works:</div>


<CodeBlock code={`sudo systemctl start application.service`} /><br/>

<div className="text">As we mentioned earlier, when you're dealing with services in systemd, you usually don't need to worry about typing the ".service" part. So, you can just type the command like this:</div>

<CodeBlock code={`sudo systemctl start application`} /><br/>

<div className="text">While you can use the simplified command we mentioned earlier for most things, for better clarity in our instructions, we'll include the ".service" part in the following commands.</div><br/>

<div className="text">To turn off a service that's currently running, use the stop command instead:</div>

<div className="text">sudo systemctl stop application.service</div><br/>

<div className="text" style={{ fontSize:'28px' }}>Refreshing and Rebooting Services</div>

<div className="text">To give a running service a fresh start, you can use the restart command:</div>

<CodeBlock code={`sudo systemctl restart application.service`} /><br/>

<div className="text">If the program you're using can update its settings without needing to restart, you can use the reload command to make that happen:</div>

<CodeBlock code={`sudo systemctl reload application.service`} /><br/>

<div className="text">If you're not sure whether the service can update its settings without restarting, you can use the reload-or-restart command. This smart command will try to update the settings in place if possible. If not, it will simply restart the service with the new settings.</div>

<CodeBlock code={`sudo systemctl reload-or-restart application.service`} /><br/>

<div className="text" style={{ fontSize:'28px' }}>Turning Services On and Off</div>

<div className="text">The commands we talked about earlier are handy for turning services on or off while you're using your computer. But if you want a service to start automatically every time you turn on your computer, you need to tell systemd to do that.</div><br/>

<div className="text">To make a service start automatically when you boot up your computer, use the enable command:</div>

<CodeBlock code={`sudo systemctl enable application.service`} /><br/>

<div className="text">When you use the enable command, it basically creates a special link. This link points from where your computer usually keeps track of services (like in /lib/systemd/system or /etc/systemd/system) to the place where systemd checks for things to start automatically (usually /etc/systemd/system/some_target.target.wants).</div><br/>

<div className="text">Now, if you change your mind and don't want a service to start automatically anymore, you can type:</div>

<CodeBlock code={`sudo systemctl disable application.service`} /><br/>

<div className="text">This will simply undo the special link that makes the service start automatically.</div><br/>

<div className="text">Remember, when you enable a service, it doesn't start running right away. If you want it to start now and also whenever you turn on your computer, you'll need to use both the start and enable commands.</div><br/>


<div className="text" style={{ fontSize:'28px' }}>Checking How Services Are Doing</div>

<div className="text">To see how a service is doing on your computer, you can use the status command:</div>


<CodeBlock code={`systemctl status application.service`} /><br/>

<div className="text">This will give you information about the service, like whether it's running or not, where it's organized in the system, and some early details from its logs.</div><br/>

<div className="text">For example, if you check the status of an Nginx server, you might see something like this:</div>

<CodeBlock code={`Output
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
 Main PID: 495 (nginx)
   CGroup: /system.slice/nginx.service
           ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
           └─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
`} /><br/>

<div className="text">This gives you a helpful summary of how the application is doing, letting you know if there are any issues or if anything needs your attention.</div><br/>

<div className="text">If you want to check if a unit (like a service) is currently doing its job (running), you can use the is-active command:</div>

<CodeBlock code={`systemctl is-active application.service`} /><br/>

<div className="text">This will tell you whether the unit (like a service) is currently working (active) or not (inactive). If it's active, you'll get a "0" exit code, which is handy for understanding results in shell scripts.</div><br/>

<div className="text">To check if the unit is set to start automatically, you can use the is-enabled command:</div>

<CodeBlock code={`systemctl is-enabled application.service`} /><br/>

<div className="text">This will show you if the service is set to start automatically or not. It'll also give you a "0" or "1" exit code to help you understand the answer.</div><br/>

<div className="text">Another thing you can check is if the unit (like a service) has run into any issues during startup. This is known as a "failed state," indicating there was a problem getting the unit started:</div>

<CodeBlock code={`systemctl is-failed application.service`} /><br/>

<div className="text">When you check, it will say "active" if everything's running smoothly, or "failed" if there's been a problem. If the unit was stopped on purpose, it might say "unknown" or "inactive." If you see a "0" exit status, it means something went wrong, while a "1" exit status means something else happened.</div><br/>

<div className="head">Understanding Your System's Situation</div>
<div className="text">The commands we've talked about are great for handling individual services, but they don't give us a good picture of what's happening with the whole system. Luckily, there are some other systemctl commands that help with that.</div><br/>

<div className="text" style={{ fontSize:'28px' }}>Checking What's Going On</div><br/>
<div className="text">To check out everything that's currently running on your computer, you can use the list-units command:</div>

<CodeBlock code={`systemctl list-units`} /><br/>

<div className="text">This will give you a list of everything that systemd is currently managing on your computer. It'll look something like this:</div>

<CodeBlock code={`Output
UNIT                                      LOAD   ACTIVE SUB     DESCRIPTION
atd.service                               loaded active running ATD daemon
avahi-daemon.service                      loaded active running Avahi mDNS/DNS-SD Stack
dbus.service                              loaded active running D-Bus System Message Bus
dcron.service                             loaded active running Periodic Command Scheduler
dkms.service                              loaded active exited  Dynamic Kernel Modules System
getty@tty1.service                        loaded active running Getty on tty1
. . .
`} /><br/>

<div className="text">The information you'll see is organized into columns:</div>
<div className="text"><ul><li><strong>UNIT:</strong> The name of the thing systemd is managing.</li><li><strong>LOAD:</strong> It tells you if systemd has read the instructions for that thing. If it's "loaded," it means systemd knows what to do with it.</li><li><strong>ACTIVE:</strong> This gives you a quick summary of whether the thing is up and running. It's a simple way to know if it's working as it should</li><li><strong>SUB:</strong> This is a bit more detailed and specific to the type and state of the thing. It provides extra information about how the thing is doing.</li><li><strong>DESCRIPTION:</strong> A short description of what that thing is or what it does.</li></ul></div><br/>

<div className="text">When you run the list-units command, it usually shows only the units that are currently active. So, in the columns, you'll see "loaded" for whether systemd knows what to do with it, and "active" for whether it's up and running.Actually, when you just type systemctl without adding anything else, it does the same thing – it shows you the active units by default.</div>

<CodeBlock code={`systemctl`} /><br/>

<div className="text">If you want systemctl to show you more detailed information, you can add extra instructions called flags. For example, if you want to see all the units that systemd knows about, whether they're currently active or not, you can use the --all flag like this:</div>

<CodeBlock code={`systemctl list-units --all`} /><br/>

<div className="text">This will display all the units that systemd knows about, whether they're active or not. It includes units that systemd tried to load but couldn't find, as well as units that were active but are now inactive.</div><br/>

<div className="text">If you want to narrow down the results, you can use other flags. For instance, you can use --state= to specify whether you want to see information about what's loaded, active, or in a particular state. Don't forget to keep the --all flag so that systemctl shows units even if they're not currently active.</div>

<CodeBlock code={`systemctl list-units --all --state=inactive`} /><br/>

<div className="text">You can also use another filter called --type= to show only the type of units you're interested in. For instance, if you want to see only active service units, you can use:</div>

<CodeBlock code={`systemctl list-units --type=service`} /><br/>

<div className="text" style={{ fontSize:'28px' }}>Viewing All Unit Files</div><br/>

<div className="text">The list-units command shows only the units that systemd has tried to understand and use. However, this might not include all the units available on your system. To see every single unit file that your system has, even if systemd hasn't looked at them yet, you can use the list-unit-files command instead:</div>

<CodeBlock code={`systemctl list-unit-files`} /><br/>

<div className ="text">Units are like descriptions of things that systemd knows about. When you use list-unit-files, it doesn't show details from all those descriptions, just the names and their current state. The list has two columns: one for the unit file's name and one for its current state.</div>

<CodeBlock code={`Output
UNIT FILE                                  STATE
proc-sys-fs-binfmt_misc.automount          static
dev-hugepages.mount                        static
dev-mqueue.mount                           static
proc-fs-nfsd.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                                  static
var-lib-nfs-rpc_pipefs.mount               static
org.cups.cupsd.path                        enabled
. . .
`} /><br/>

<div className="text">The state you see will typically be one of these: enabled, disabled, static or masked.</div>
<div className="text">In this case:</div>
<div className="text"><ul><li>Enabled: The unit can be turned on.</li><li>Disabled: The unit is turned off.</li><li>Static: This means the unit doesn't have the necessary info to be turned on. It might do a one-time thing or is needed only by another unit.</li></ul></div>

<div className="text">We'll talk about what "masked" means in just a bit.</div><br/>

<div className="head">Controlling Units</div>
<div className="text">Up until now, we've been dealing with services and checking what systemd knows about them. But there's more we can learn about these units using some extra commands. Let's dive into more details!</div><br/>

<div className="text" style={{ fontSize:'28px' }}>Viewing Unit Details</div><br/>

<div className="text">To see the detailed instructions that systemd is using for a particular unit, you can use the cat command. This feature was added starting from systemd version 209. For example, to look at the unit file for the atd scheduling daemon, you could type:</div>

<CodeBlock code={`systemctl cat atd.service`} /><br/>


<CodeBlock code={`Output
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target
`} /><br/>

<div class="text">The output shows the set of instructions systemd is currently using for that unit. This could be useful if you've made changes to unit files or if you've adjusted specific options in a part of a unit file (we'll talk about this later).</div><br/>

<div className="text" style={{ fontSize:'28px' }}>Checking Dependencies</div><br/>
<div className="text">If you want to check all the things a unit depends on, you can use the list-dependencies command:</div>

<CodeBlock code={`systemctl list-dependencies sshd.service`} /><br/>

<div className="text">This will show you a map of dependencies, which are basically the things that need to be taken care of before the unit you're interested in can start. Dependencies include units that are necessary for or wanted by the units above them in the hierarchy.</div>

<CodeBlock code={`Output
sshd.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
. . .
`} /><br/>

<div className="text">If you want to see all the dependencies, including those that keep going down the line, you can use the --all flag. This is particularly handy when dealing with .target units, which represent different system states.</div><br/>

<div className="text">If you're curious about which units depend on the one you're looking at, you can add the --reverse flag. Additionally, there are two more helpful flags: --before shows units that should start before the specified unit, and --after shows units that should start after the specified unit.</div><br/>

<div className="text" style={{ fontSize:'28px' }}>Inspecting Unit Details</div><br/>
<div className="text">If you want to see the detailed properties of a unit, you can use the show command. This will give you a list of settings for that unit, displayed in a key=value format.</div>

<CodeBlock code={`systemctl show sshd.service`} /><br/>

<CodeBlock code={`Output
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .
`} /><br/>

<div className="text">If you only want to see one specific detail, you can use the -p flag with the property name. For example, to find out about conflicts that the sshd.service unit might have, you can type:</div>

<CodeBlock code={`systemctl show sshd.service -p Conflicts`} /><br/>

<CodeBlock code={`Output
Conflicts=shutdown.target`} /><br/>

<div className="text" style={{ fontSize:'28px' }}>Blocking and Unblocking Units</div>

<div className="text">In addition to stopping or disabling a service, systemd allows you to prevent a unit from starting altogether, whether it's done automatically or manually. This is known as "masking" the unit, and you can do it using the mask command:</div>

<CodeBlock code={`sudo systemctl mask nginx.service`} /><br/>

<div className="text">This will make sure that the Nginx service can't start, whether someone tries to start it automatically or manually, as long as it stays masked.</div><br/>

<div className="text">If you look at the list of unit files, you'll now see that the service is marked as "masked":</div>
