cicid/2019-05-29-blog-26.md at main

jassim/cicid

Fork 0

Jazze7 7058509e00 modified jenkinsfile

2024-11-05 16:27:23 +05:30

19 KiB

Raw Permalink Blame History

slug

title

authors

tags

Managing Systemd Services and Units with Systemctl A Guide

slorber

hola

docusaurus

import CodeBlock from '@site/src/components/CodeBloack';

Introduction

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!

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.

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!

Managing Services with Systemctl

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!

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.

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!

Getting Services Going and Turning Them Off

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:

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:

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.

To turn off a service that's currently running, use the stop command instead:

sudo systemctl stop application.service

Refreshing and Rebooting Services

To give a running service a fresh start, you can use the restart command:

If the program you're using can update its settings without needing to restart, you can use the reload command to make that happen:

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.

Turning Services On and Off

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.

To make a service start automatically when you boot up your computer, use the enable command:

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).

Now, if you change your mind and don't want a service to start automatically anymore, you can type:

This will simply undo the special link that makes the service start automatically.

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.

Checking How Services Are Doing

To see how a service is doing on your computer, you can use the status command:

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.

For example, if you check the status of an Nginx server, you might see something like this:

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.

If you want to check if a unit (like a service) is currently doing its job (running), you can use the is-active command:

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.

To check if the unit is set to start automatically, you can use the is-enabled command:

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.

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:

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.

Understanding Your System's Situation

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.

Checking What's Going On

To check out everything that's currently running on your computer, you can use the list-units command:

This will give you a list of everything that systemd is currently managing on your computer. It'll look something like this:

The information you'll see is organized into columns:

UNIT: The name of the thing systemd is managing.
LOAD: 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.
ACTIVE: 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
SUB: 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.
DESCRIPTION: A short description of what that thing is or what it does.

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.

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:

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.

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.

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:

Viewing All Unit Files

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:

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.

The state you see will typically be one of these: enabled, disabled, static or masked.

In this case:

Enabled: The unit can be turned on.
Disabled: The unit is turned off.
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.

We'll talk about what "masked" means in just a bit.

Controlling Units

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!

Viewing Unit Details

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:

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).

Checking Dependencies

If you want to check all the things a unit depends on, you can use the list-dependencies command:

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.

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.

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.

Inspecting Unit Details

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.

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:

Blocking and Unblocking Units

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:

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.

If you look at the list of unit files, you'll now see that the service is marked as "masked":

19 KiB Raw Permalink Blame History Unescape Escape

19 KiB

Raw Permalink Blame History