Complete tutorial of the systemctl command in Linux

To dominate systemctl and systemd It's practically mandatory these days if you manage modern Linux servers or systems. This tool is the gateway to controlling which services start, how they start, what has failed, and the actual state of your system at any given time. Once you get the hang of it, you'll save yourself a lot of headaches and many unnecessary restarts.

Throughout this guide you will see in an orderly way and with examples how to use systemctl to manage services, units, and goalsHow to list what's happening in the system, how to edit drives without breaking anything, what states like mean enabled, masked o staticAnd also Tricks To shut down, restart, or switch from graphical to text mode with a single command. All using a Spanish from Spain, direct and practical, designed so that you can apply what you read to any systemd-based distro (Ubuntu, Debian, RHEL, CentOS, Fedora, Arch, etc.).

What is systemd and what role does systemctl play?

In most current distributions, systemd acts as a startup system and base infrastructureIt is the process that starts right after the kernel (usually as PID 1) and is responsible for starting the rest of the services, mounting file systems, managing dependencies, controlling sessions, logging events and much more.

systemd is made up of daemons, libraries, and utilities that allow communication with the kernel and user space: manages control groups (cgroups), sockets, timers, mount points, basic network configuration, time synchronization, name resolution, containers, and Virtual machinesand is even compatible with older SysV and LSB scripts, so it can completely replace Classic Sysvinit.

Within this entire ecosystem, systemctl is the "remote control" of systemdIt is the online utility of commands that you use for:

• Start, stop, restart, or reload services and other types of units.
• Enable or disable units so that they can start (or not) with the system.
• Check the status of services, objectives and the system in general.
• Edit drive files or view its dependencies and internal properties.
• Change global state of the system (rescue mode, multi-user, graphical, shutdown, restart…).

Note that not all distributions use systemd. If when running systemctl You see a message like this: bash: systemctl: command not found Or something similar; your system likely uses a different init system (OpenRC, runit, pure SysV, etc.). In that case, The commands in this guide do not apply as it is.

Drives and drive files in systemd

The key concept in systemd is the unitsA unit represents any resource that systemd is capable of managing: a service, a socket, a mount point, a device, a system-global goal, a timer… Each unit type is identified by a suffix in the file name.

Some of the most common types of units you'll see when working with systemctl and systemd are:

• .service: services and daemons (nginx.service, ssh.service, NetworkManager.service…).
• .socket: sockets associated with services started on demand.
• .mount: file system mount points.
• .automount: automatic assemblies activated for use.
• .target: system “states” (multi-user.target, graphical.target, rescue.target…).
• .timer: timers that launch services at specific times.
• .device: devices managed by udev.
• .path: route monitors on disk that trigger services.

Each unit is defined in a unit filewhich is a text file with sections like , , , where the description, dependencies, and commands of are detailed Boot, user running the service, etc. These files are typically stored in:

• /lib/systemd/system/ o /usr/lib/systemd/system/: units that come with the packages.
• / etc / systemd / system /: units defined or overwritten by the administrator.

when you work with systemctlYou almost always refer to units of type .serviceHowever, if you omit the suffix, systemd assumes by default that you are referring to a service. That is, systemctl start ssh y systemctl start ssh.service are equivalent.

There are special units called templates, whose name includes @, for example name@.serviceWhen instantiating a template as name@miinstancia.serviceWhat you're doing is creating a a specific instance passing an identifier; within the unit file, the variable %i It is replaced by that identifier. This is commonly used in SSH tunnels, network interface services, etc.

Check if your system uses systemd

Before you go crazy with the commands, it's a good idea to check if your distro is actually using systemd as PID 1Many guides suggest something as simple as:

pstree | head -5

If at the top of the tree you see a process systemdYou can proceed without any problem. If you see a different init system, you will need to use the specific tools for that startup system.

Basic service management with systemctl

Day-to-day operation with systemd typically focuses on Start, stop, restart, and reload servicesThese commands affect the current state of the service, not whether or not it will start automatically with the system.

To check the status of a service, you can use:

systemctl status nombre_servicio.service

For example, to see how the network service is performing systemd-networkd on a text-mode Ubuntu system:

systemctl status systemd-networkd.service

This command displays fairly detailed information: status (active, inactive, failed…), when it was activated, the main PID, CPU usage, and a few recent log messages that are very useful for diagnosing problems.

If you want something more direct, you can use these specific variations:

• systemctl is-active name.service: indicates whether it is active (running) or not.
• systemctl is-enabled name.service: indicates whether it will start at the beginning.
• systemctl is-failed name.service: checks if it entered a fault state.

For example, to see if systemd-networkd is enabled at startup you can run:

systemctl is-enabled systemd-networkd.service

And to find out if it failed to start at any point:

systemctl is-failed systemd-networkd.service

Starting, stopping, restarting, and reloading services

To stop a service that is runningThe typical order is:

sudo systemctl stop nombre_servicio.service

Keep in mind that since this is an action that affects the system, you will need administration privileges, normally using sudoIn some "stubborn" services, such as systemd-networkd, stopping them will cause them to restart immediately if there is a unit that requires them and has automatic restart policies.

If the service is stopped and you want start itYou use the same pattern with start:

sudo systemctl start systemd-networkd.service

When you have changed a configuration file and want to apply the changes, the most common thing to do is restart service:

sudo systemctl restart nombre_servicio.service

Many demons allow Reload your settings without fully restartingavoiding cutting active connections. In these cases, the following is used:

sudo systemctl reload nombre_servicio.service

If you're unsure whether that service supports top-ups, you can try:

sudo systemctl reload-or-restart nombre_servicio.service

With this command, systemctl attempts to reload first And if the unit doesn't perform a reload, it proceeds to a full reboot. This is very useful when you don't remember the specific behavior of each daemon.

Enable and disable services at startup

Everything we've seen so far only affects the current sessionIf you want a service to start automatically when the system boots, you need to enable itThe basic command is:

sudo systemctl enable nombre_servicio.service

By doing so, systemd creates symbolic links from the system service file (usually in /lib/systemd/system o /etc/systemd/system) up to a directory .wants corresponding to the target where it should be activated. For example, something like:

/etc/systemd/system/multi-user.target.wants/nombre_servicio.service

If you want the exact opposite, that is, prevent a service from starting automatically Disable it on the next startup:

sudo systemctl disable nombre_servicio.service

This removes the symbolic boot links, but It does not stop the service that is already runningSimilarly, enabling a service doesn't start it instantly: it will only be effective after the next reboot, unless you combine the following:

sudo systemctl enable nombre_servicio.service
sudo systemctl start nombre_servicio.service

Some distributions and tools offer shortcuts for enable and start at the same timeHowever, the standard way with systemctl is usually to run both commands.

View the overall status of the units

systemctl is not only useful for touching individual services; it also allows to have an overview of the systemThe most typical command is:

systemctl list-units

This list shows all active units that systemd has in memory. The main columns are:

• UNIT: unit name (for example, sshd.service).
• LOAD: whether the drive file has been loaded correctly (loaded, not-found, error…).
• ACTIVE: general status (active, inactive, failed…).
• SUB: more descriptive substate (running, exited, dead, failed…).
• DESCRIPTION: brief description of the unit.

If you call systemctl without argumentsYou'll see virtually the same list, as that's its default behavior. Since only active units are displayed, almost everything will appear with LOAD=loaded and ACTIVE=active.

To also include inactive units, you can add the indicator --all:

systemctl list-units --all

You can also filter by state with --state=For example, to see only inactive drives:

systemctl list-units --all --state=inactive

Or filter by unit type with --type=For example, to see only active services:

systemctl list-units --type=service

List all installed drive files

The list above only shows units that systemd has attempted to load. If you want to know more. all the drives that exist on the diskWhether you use them or not, you must resort to:

systemctl list-unit-files

Here the focus is on the unit files themselves, not their state in memory. You'll see two main columns: UNIT FILE y STATEIn STATE, values ​​such as the following appear:

• enabledThe unit is configured to start automatically.
• disabled: It is not configured for automatic startup.
• staticThe unit has no section larvae, nymphs, and adults, so cannot enable itselfIt is usually a dependency on other units or to perform a specific action.
• maskedThe unit is completely locked; it cannot be started in any way.

You can also filter by status, for example to see only enabled units:

systemctl list-unit-files --state=enabled

Or combine multiple states into a single query by separating them with commas:

systemctl list-unit-files --state=enabled,failed

View details, properties, and dependencies of a unit

If you would like to view the actual contents of the drive file Since systemd is using the most convenient command, it is:

systemctl cat nombre.service

This shows the file as systemd sees it, including any override fragments from /etc/systemd/systemIt's very useful for confirming that your changes have actually been taken into account.

To inspect the dependency tree From one unit, you can use:

systemctl list-dependencies nombre.service

The output is hierarchical, showing which objectives and services drive the service in question. The units of type .target They act as grouping points and only they recursively show their dependencies by default; if you want to expand the entire tree, add --all.

If what you need to know is which units depend on the one you indicated, Add --reverse to the command. And if you want to focus on the boot order, the flags --before y --after They show units that must start before or after the target unit.

To see all internal properties of a unit in key=value format, use:

systemctl show nombre.service

And if you're only interested in a specific property, you can filter with -pFor example, to view sshd conflicts:

systemctl show sshd.service -p Conflicts

Masking and unmasking units

In addition to disabling, systemd allows mask a unit so that it is completely impossible to boot itThis technique is used when you want to be 100% sure that something won't start, even accidentally. This can be done manually or by relying on another unit.

The masking is implemented by creating a symbolic link to /dev/null instead of the actual drive file. To mask a service, for example nginx:

sudo systemctl mask nginx.service

If you then run systemctl list-unit-files, you will see that nginx.service appears as maskedAnd if you try to start it:

sudo systemctl start nginx.service

You will receive a message like this: Failed to start nginx.service: Unit nginx.service is masked. In other words, the unit is armored. To make it usable again, it is necessary to unmask her:

sudo systemctl unmask nginx.service

After this, the unit returns to its previous state (enabled, disabled, static, etc.) and can then be started or enabled normally.

Edit drive files without breaking the system

Sometimes you need to adjust the behavior of a service: change the user that runs it, add command-line options, modify dependencies… Instead of manually editing the files in /lib/systemd/systemThe safest thing is to use your own systemctl to generate overrides.

The basic command is:

sudo systemctl edit nombre.service

This opens your default editor with a empty fragment fileWhen you save and exit, systemd will create a directory in /etc/systemd/system/nombre.service.d/ and inside a file override.confWhen loading the drive, systemd merges the original file with this fragment, and the override directives they have priority on those of the base file.

If you want to edit the complete drive file Instead of an override, you can do it with:

sudo systemctl edit --full nombre.service

In this case, what you save will be written to /etc/systemd/system/nombre.servicewhich takes precedence over the system version in /lib/systemd/systemIt's a way to "clone" and completely customize a drive without touching the files that come with the package.

If you later decide to undo your changes, simply delete the .d directory of the override or the modified service file in /etc/systemd/system. For example: uterine

sudo rm -r /etc/systemd/system/nginx.service.d
sudo rm /etc/systemd/system/nginx.service

After deleting these items, it is very important to run:

sudo systemctl daemon-reload

This forces systemd to Reload all drive filesForget about the removed overrides and revert to using the original system definitions.

Targets and runlevel adaptation

Los systemd targets are the modern equivalent of runlevels from SysV. They are special units (they end in .target) that group other units to represent “states” or synchronization points of the system.

For example:

• multi-user.target: multi-user console mode, typical of servers without a graphical environment.
• graphical.target: graphical mode; usually depends on multi-user.target and adds the graphical interface layer.
• rescue.target: rescue mode, similar to “single user mode”.
• swap.target: point at which the exchange area is ready for use.

Units can declare relationships such as WantedBy=, RequiredBy=, Wants=, Requires=, After= with these objectives to indicate what they depend on and in what order they should be achieved.

To find out What is the predetermined objective? of your system (the state you want to reach in a normal boot), use:

systemctl get-default

For example, if you prefer the system to always start in graphical mode, you can change it with:

sudo systemctl set-default graphical.target

To see all the targets installed on the system, with their status (enabled, disabled…), you can run:

systemctl list-unit-files --type=target

And if what you want is to see which targets are active right nowYou do it with:

systemctl list-units --type=target

Isolate objectives and change working mode

One of the most powerful things that systemd offers is the ability to changing the system state by “isolating” a targetWhen you execute an isolation, systemd activates all the units necessary for that objective and stops those that no longer fit into its dependency tree.

Imagine you are in a graphical environment (active graphical.targetand you want to move to a text-only, multi-user environment, for example for maintenance tasks. You can first check the dependencies of multi-user.target:

systemctl list-dependencies multi-user.target

And when you're sure you're not going to damage anything critical, you launch:

sudo systemctl isolate multi-user.target

Since graphical.target depends on multi-user.target but not vice versa, isolating the multi-user target will stop it. all services associated with the graphics layerleaving you in text mode. It's quite a radical change, so use it wisely.

For very common events, systemctl offers convenient shortcuts versus writing isolate by hand. Some of the most commonly used are:

• sudo systemctl rescue: switches to rescue mode (equivalent to isolating rescue.target) and alerts connected users.
• sudo systemctl halt: stops the system (similar to turning off the CPU without cutting power).
• sudo systemctl poweroffTurn the machine off completely.
• sudo systemctl reboot: restarts the system.

Typically, classic commands like reboot, poweroff o halt They are internally linked to talk to systemd, so they behave consistently with these shortcuts.

Additional essential systemctl commands

In addition to all of the above, there are some commands for systemctl which you should keep handy because you'll use them frequently when working with units:

Reload systemd configuration (not the services):

sudo systemctl daemon-reload

Every time you modify or add drive files, you need to notify systemd so it can reread them. This command services do not restartIt only reloads the unit database.

Check the status of a service with details (already discussed):

sudo systemctl status nombre_servicio.service

Here you'll see the Loaded, Active status, PID, uptime, and the latest log messages, which is invaluable for debugging errors.

Enable and disable services (also seen):

sudo systemctl enable nombre_servicio.service
sudo systemctl disable nombre_servicio.service

Start, stop, and restart services explicitly:

sudo systemctl start nombre_servicio.service
sudo systemctl stop nombre_servicio.service
sudo systemctl restart nombre_servicio.service

These patterns are repeated with virtually any service, from apache2, nginx or ssh, up to services of databases, impression demons or whatever you can think of.

Service management: start, reload, stop, and monitor

In a real-world setting, you'll use systemctl to keep essential services always up and running: web servers, databases, network services, daemons backupetc. The idea is to minimize There of inactivity and apply configuration changes with the least possible impact.

To start a service that is supposed to be active (for example, Apache), the typical command would be:

sudo systemctl start apache2

If Apache was already running, you won't notice anything unusual; if it was stopped, the daemon will start child processes and begin handling requests. Whenever you're unsure what happened, run the following commands:

sudo systemctl status apache2

When you change the main configuration file or some virtual host, you usually recharge o Reiniciar The service. Recharging is smoother:

sudo systemctl reload apache2

This allows the service to reread configuration files without killing running processes, so users barely notice anything. If, for whatever reason, the service doesn't support reloading, you'll need to:

sudo systemctl restart apache2

In some cases, if the service is having problems or has become unresponsive, a complete reboot may be necessary. frees up resources and cleans up zombie processesIt's one of the typical diagnostic steps before going to look into it. logs in deep.

To temporarily stop a service because you're doing maintenance or because you simply don't need it for a while:

sudo systemctl stop apache2

That doesn't prevent it from restarting on the next reboot if you have it enabled. If you want it to disappear completely until further notice, you combine stop with disable o mask depending on the degree of "prohibition" you want to apply.

After any sensitive surgery, it is highly recommended check status of the service and its latest records with:

sudo systemctl status nombre_servicio

And, if you need more context, with journalctl, For example:

sudo journalctl -u nombre_servicio

Troubleshooting common problems with systemctl

When something goes wrong when starting a service with systemctlIt's normal to see messages like "Job for X failed" or statuses failed in the status exit. The orderly way to proceed is usually:

1. View detailed status of the unit:

sudo systemctl status nombre_servicio

There you'll see if the service isn't starting due to a command failure, a timeout, permission issues, a missing file, etc. Look at lines like "Main PID exited" and the actual error messages from the application.

2. Review the complete records with journalctl:

sudo journalctl -u nombre_servicio

This gives you the log history generated by the unit, which is very useful if the service "dies" right after starting.

3. Check if it is enabled when you expect it to boot:

sudo systemctl is-enabled nombre_servicio

If it appears as disabled, simply:

sudo systemctl enable nombre_servicio

4. Check permissions and userSome services need to run as a specific user or access specific paths. If the unit file specifies a User= o Group= incorrect, or the route in ExecStart= If it doesn't exist or isn't accessible, the service can go down instantly.

5. If you have manually edited the drive file, always remember reload systemd configuration with:

sudo systemctl daemon-reload

Forgetting this step is a classic mistake: you make changes, restart the service, and still see the old behavior because systemd hasn't read the new file yet.

Maintaining this routine of checks and periodically reviewing the status of key units makes it much easier. Maintaining a stable and predictable Linux system.

As you see, systemctl becomes the Swiss Army knife for managing system services, units, and states In any modern distribution with systemd, it allows you to start and stop daemons with precision, control what starts at boot, investigate bugs in considerable detail, tweak configurations without overwriting system files, and switch from a graphical mode to a rescue mode in seconds. Mastering these commands not only makes managing Linux servers or desktops much easier, but also gives you much more confidence when troubleshooting serious production problems, because you know exactly what's running, why, and how to safely stop or modify it.