Managing Services with Systemd: The Complete Guide to Systemctl

In the systems Linux modern, systemd and its systemctl tool They are the heart of service management and of the service itself. BootIf you work with servers or desktops on a daily basis, mastering these utilities will allow you to start, stop, debug, and automate services with ease.

Throughout this guide you will find a complete and practical summary for manage services with systemd: from the basics (start, stop, enable) to advanced options like isolating targets, editing drives with overrides, analyzing the boot, or even enabling it in WSL. All with nuances regarding compatibility between distributions and other init systems so you don't get caught off guard.

What is systemd and how does it organize the system?

In a nutshell, systemd is the init system and service manager which runs as PID 1 and coordinates the startup and lifecycle of user processes. Within its ecosystem, the key components are "units," which represent manageable resources such as services, sockets, mount points, devices, or targets.

Units are described with unit files with suffixes which indicate their type: .service (services), .socket (sockets), .target (system states), among others. These files live in paths like /lib/systemd/system y /etc/systemd/system, and can be viewed, listed, and modified with systemctl.

In addition to systemctl, the ecosystem is completed with utilities such as journalctl (records), loginctl (sessions), hostnamectl, localectl, timedatectl or inspection tools such as systemd-cgls. Everything adds up to a more refined and centralized administration.

If you need to change default global settings, you can edit /etc/systemd/system.conf (for example, DefaultTimeoutStartSec) and so on override compilation values throughout the system without touching unit by unit.

Starting, stopping, restarting, and reloading services

Everyday life starts with the basics: start and stop services. Uses sudo systemctl start nombre.service to start and sudo systemctl stop nombre.service to stop. The .service suffix is ​​optional; systemd is clever and usually infers it. In environments Windows there commands equivalents for Control processes and services in Windows.

When you make configuration changes, it usually touches restart with sudo systemctl restart nombre.serviceIf the service supports hot recharging, you save an outage with sudo systemctl reloadIf you don't know whether to recharge or not, pull reload-or-restart and ready.

Note that some daemons are intended to reappear after a stop due to its own restart policy. This is common in infrastructure pieces such as systemd-networkd, so don't be surprised if he gets back up.

Be careful with the variants between distros: on Ubuntu desktop it is common to work with NetworkManager, so commands like network status could be queried in NetworkManager.service instead of systemd-networkd.service.

Enable, disable, and check status

For a service auto start with the system, use sudo systemctl enable nombre.service. This creates symbolic links from your unit file to the paths .../target.wants of the corresponding target. In Windows, there are guidelines on which services not to touch, for example Windows 11 services you shouldn't disable.

If you don't want it at startup, disable it with sudo systemctl disableRemember that enable/disable doesn't start or stop the service in the current session; you'll combine enable/disable with start/stop as appropriate.

To check the status in detail, systemctl status It gives you load, activity, PID, cgroup, and the latest log lines for the unit. If you just want a quick verdict: systemctl is-active (running or not), systemctl is-enabled (enabled or disabled) and systemctl is-failed (failed, inactive, unknown) with handy exit codes for scripts.

Explore the system: list-units and list-unit-files

When you need a panoramic view, systemctl list-units displays the active units. You'll see columns UNIT, LOAD, ACTIVE, SUB, and DESCRIPTION to help you see at a glance what's happening. In Windows, the command List processes in Windows with TaskList offers a similar view.

If you want to be more exhaustive, add –all To include inactive, filter by status with --state= and by type with --type=serviceThis way, you can list, for example, all service units regardless of their activity.

To see what is installed and its boot policy, systemctl list-unit-files lists the unit files with a state: enabled, disabled, static, or masked. "Static" indicates units without a section, intended to be dependencies or one-time execution.

Inspect units, outbuildings and properties

With systemctl cat name.service You'll see the exact unit file that systemd has loaded (with overrides merged in). Ideal for checking which directives are actually active.

Dependencies are displayed with systemctl list-dependencies. you can add --all for recursion, --reverse for inverse dependencies, or --before/--after for the relative order between units.

If you need low-level detail, systemctl show dumps key properties in format clave=valor. For something specific, use -p Propiedad and you get only what interests you (e.g. conflicts or order relationships).

When a service should not even be started, mask it sudo systemctl mask nombre.service (points to /dev/null). Then just unmask It returns it to its previous state. A mask blocks manual and automatic startups. In Windows environments, you can also restore damaged services from the Services console, for example. Restore deleted services from services.msc.

Editing units: overrides and daemon reloads

To customize without touching the original file, systemctl edit name.service opens an override in /etc/systemd/system/nombre.service.d/override.confWhatever you put there prevails without losing the supplier's base.

If you want to rewrite the entire unit, use –full and will save a copy in /etc/systemd/system. When removing overrides or custom units, remember reload the daemon sudo systemctl daemon-reload so that it stops referencing them.

If you no longer need your changes, you can delete the .d directory of the override or the complete unit in /etc/systemd/system. After that, a daemon-reload and the system will revert to the base system definitions.

Targets and relationship with runlevels

The targets represent states of the system (e.g., multi-user.target or graphical.target) and group the units needed to achieve that state. They resemble the old runlevels, but are more flexible and composable.

Query the default target with systemctl get-default and change it with set-default (for example, graphical.target to start in a graphical environment). You can list installed targets with list-unit-files --type=target and assets with list-units --type=target.

If you need to make a drastic commute, isolated stops what doesn't belong to the target and activates its dependencies. Before doing so, it's a good idea to review list-dependencies of the target so as not to accidentally knock down something critical.

Additionally, systemctl exposes shortcuts with warnings to logged-in users: rescue (single-user mode), halt, power off y reboot. On many machines, traditional commands like reboot are already linked to systemd.

Create your own service (.service) step by step

For a tailor-made service, create the unit in /etc/systemd/system. For example, ttrssupdate.service It could contain a description, dependencies, the execution user and the command to be launched.

A typical example would be something like this (adjusts actual routes): with Description, After, User, ExecStart and WantedBy you define the essentials to get it started with the multi-user system.

Regarding permits and ownership, it is important that the file belongs to root and have consistent permissions. Avoid overly permissive permissions; although some examples show chmod 777, the recommended practice is more restrictive so as not to open the door to security problems.

After creating or modifying the unit, run sudo systemctl daemon-reload, enables with enable and starts with start. From there, you can stop, restart and consult professional status. To debug, journalctl -u tu-servicio.service will show you the logs associates.

Equivalences with SysV and other inits

If you come from SysV, think about systemctl start/stop/restart/reload/status as substitutes for service nombre start/stop/.... For the starting part, enable/disable replaces chkconfig on/off, and list-unit-files provides an overview of what is activated.

On older systems, you may encounter service –status-all, which lists daemons with flags (up), (down), or (unknown). With Upstart (Ubuntu 14.04, RHEL6) it is used initctl list to see statuses such as running, stopped or waiting.

In environments that use OpenRC (Gentoo, Alpine), rc-status Displays services by runlevel with started/stopped/failed/crashed statuses. You can even check the current runlevel with rc runlevel. For advanced process management tasks in Windows, there are also third-party tools, for example Use Process Hacker to manage priority.

Diagnostics, logs and boot performance

To check definitions, systemd-analyze It has verification and analysis functions. You can get a radiography from the start, see what took the longest and draw an SVG.

Common commands: systemd-analyze blame (times per service), systemd-analyze critical-chain (critical chain of dependencies) and systemd-analyze plot (generates a .svg with the boot timeline).

When a service fails, it starts with journalctl -u name.service to view errors and warnings. You can list failed drives and, if the shutdown or restart takes forever, check for posted works and cancel them before trying again.

If you edit or create new units, don't forget systemd-analyze verify to detect syntax errors or references to non-existent files before enabling and starting the service.

Good management practices

In unit files, always use absolute paths in ExecStart/ExecReload and configuration files. Do not rely on environment variables such as $PATH because systemd won't consider them as your shell would.

Define ExecReload if your service supports dynamic recharge. This way you can use systemctl reload hot without rebooting, which is key for servers with high availability.

setup RestartSec along with Restart policies to avoid frantic restart loops. A small delay helps stabilize dependencies and shared resources.

Document and monitor: save lists as systemctl list-unit-files –type service –all > services.txt, maps dependencies with list-dependencies --reverse and monitors status and consumption. Complement with Prometheus/Grafana or APM solutions if your case requires it.

On critical remote computers, disable the emergency mode It can leave you without a network due to a configuration error. And, of course, validate changes in staging before touching them in production.

Compatibility, adoption and business vision

Although today systemd dominates in most distributions, it's not universal. Fedora incorporated it early; Debian has been using it since version 8; RHEL and CentOS since RHEL 7; Ubuntu adopted it in 15.04; Arch and openSUSE have been using it for years, among others.

Not everything has been applause: his work has been criticized complexity and scope, its potential effect of dependence on the ecosystem and a certain distance from philosophy Unix Minimalist. For novice admins, the learning curve may seem steep.

Among the practical disadvantages: permissions and security If they are not configured correctly, there may be dependency conflicts, slower startups due to poorly adjusted timeouts, or breakages after updates if the units are not maintained.

That said, in corporate environments it contributes homogeneity, telemetry and control. Its modularity, built-in logs, and declarative dependency modeling make it easy to operate at scale and reduce There means of repair.

Systemd in WSL: How to enable it and what it changes

If you're working on Windows with WSL 2, you can now enable systemd to get even closer to a bare-metal Linux. On current Ubuntu installed with wsl --install It already comes by default.

For other distros on WSL 2, edit /etc/wsl.conf and adds: in a line and systemd=true in another. Close and run wsl.exe –shutdown en PowerShell to restart WSL; when you come back, check with systemctl status.

On Debian/Ubuntu/Kali, make sure you have systemd and systemd-sysv installed. Important: By giving PID 1 to systemd, WSL adjusts its internal architecture; however, Services do not keep the WSL instance alive indefinitely, just as before.

For anyone developing with snaps, microk8s, or other components that rely on systemd, this integration reduces friction and brings the behavior closer to what you'll see in production.

It is worth remembering that with systemd you also have complementary utilities such as journalctl for the newspaper, or systemd-analyze to profile the boot and verify units. With a pinch of order and a few good practices, it becomes a very powerful ally for admins and devops.

Related article:

How to modify services in Windows 11: full control, security, and performance

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.