Managing services (systemctl)

Table of Contents

Understanding `systemctl` Basics

systemctl is the main command-line tool for interacting with systemd. In this chapter, you’ll focus on how to manage services: starting, stopping, inspecting, and controlling how they behave at boot.

You’ll see commands like foo.service. Most of the time you can omit the .service suffix; systemctl assumes it.

# These are equivalent:
systemctl restart ssh
systemctl restart ssh.service

Whenever you see sudo in commands, it means you need administrative privileges.

Inspecting Service State

Checking if a service is active

To see if a service is currently running:

systemctl status ssh

Typical output sections:

Loaded: whether systemd knows about the unit and where it’s defined
Active: active (running), inactive, failed, etc.
Main PID: PID of the main process
Logs: recent log messages via journalctl

To get a short one-line summary:

systemctl is-active ssh

Possible results:

active
inactive
failed
activating / deactivating
unknown (systemd doesn’t know this unit)

Checking if a service is enabled at boot

Whether a service starts automatically at boot:

systemctl is-enabled ssh

Common outputs:

enabled – will start at boot
disabled – will not start at boot
static – cannot be enabled directly (usually a helper unit)
masked – completely disabled (even manual start is blocked)

Listing services

To list all service units known to systemd:

systemctl list-units --type=service

To include inactive and dead services:

systemctl list-units --type=service --all

To list installed service files (even if not currently loaded):

systemctl list-unit-files --type=service

This shows each service and its enablement state (enabled, disabled, masked, etc.).

Starting, Stopping, and Restarting Services

These operations affect the current system state only; they don’t change what happens at boot (that’s controlled with enable/disable, covered later).

Start a service

To start a service immediately:

sudo systemctl start ssh

You can verify:

systemctl is-active ssh
systemctl status ssh

Stop a service

To stop a running service:

sudo systemctl stop ssh

If something depends on that service, stopping it may cause related services to stop or malfunction.

Restart a service

Restart is useful after configuration changes:

sudo systemctl restart ssh

If you want a restart that won’t start the service if it’s currently stopped (more on this below), use try-restart.

Reloading configuration without full restart

Some services support a “reload” operation: they re-read configuration without dropping existing connections.

sudo systemctl reload ssh

If the service doesn’t support reload, this may fail. To “reload or restart” in one command:

sudo systemctl reload-or-restart ssh

This will reload if possible; otherwise, it will do a full restart.

Conditional operations

Sometimes you only want to act if a service is running:

try-restart: restart only if currently running
reload-or-try-restart: reload if possible, otherwise restart, but only if service is running

Examples:

sudo systemctl try-restart ssh
sudo systemctl reload-or-try-restart ssh

Enabling and Disabling Services at Boot

These commands change the persistent boot behavior.

Enable a service to start at boot

To make a service start automatically on system boot:

sudo systemctl enable ssh

This creates symlinks in systemd’s configuration directories (you don’t need to manage these by hand).

To enable and also start it immediately:

sudo systemctl enable --now ssh

Disable a service at boot

To stop a service from starting at boot:

sudo systemctl disable ssh

To disable and also stop it right now:

sudo systemctl disable --now ssh

Disabling does not prevent manual systemctl start ssh.

Masking and unmasking services

Masking is a stronger form of disabling. A masked service cannot be started at all, not even manually:

sudo systemctl mask ssh

Trying to start a masked service:

sudo systemctl start ssh

will fail with an error like “Unit is masked”.

To undo masking:

sudo systemctl unmask ssh

You might mask services that you never want to run (for example, to prevent accidental or automatic activation).

Viewing and Understanding Service Details

Show full service configuration

To display loaded metadata and effective configuration:

systemctl show ssh

This prints many key–value pairs (e.g. ExecStart=, Restart=, After=, etc.).

To filter by specific properties:

systemctl show ssh -p ActiveState -p SubState -p Description

Find the service file on disk

To locate the service unit file:

systemctl status ssh

Look for:

Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)

The path (/lib/systemd/system/ssh.service or /usr/lib/systemd/system/... or /etc/systemd/system/...) tells you where the unit is defined.

You can also use:

systemctl cat ssh

This shows the unit file content, including any overrides.

Managing Service Logs

Although logging is covered more deeply elsewhere, you often need recent logs when managing services.

To see recent logs for a service:

journalctl -u ssh

To see only the latest logs and follow them in real time:

journalctl -u ssh -f

To limit to the current boot:

journalctl -u ssh -b

This is handy immediately after starting or restarting a service to confirm it’s working.

Managing Service Dependencies and Ordering

systemd units have relationships like “requires”, “wants”, “before”, and “after”. You don’t need to master all of this to manage services, but there are a few useful tools.

Check what depends on a service

To see “reverse dependencies” (who wants/requires this service):

systemctl list-dependencies --reverse ssh

This can help you understand what might be affected if you stop a service.

View dependency tree

To see the dependency tree of a service:

systemctl list-dependencies ssh

This lists other units that start along with it.

Service Activation: Manual vs Socket vs Path

Some services aren’t always running; they are started “on demand” by systemd (socket or path activation). As an administrator, you just use systemctl normally, but it’s useful to recognize this pattern.

For example, a service might be started not at boot, but when:

Something connects to a socket (a port or a UNIX socket)
A path changes (a file appears, etc.)

You can see if a service is socket-activated by checking its unit file (with systemctl cat) or by listing sockets:

systemctl list-units --type=socket

Even with socket-activated services, you still manage them with systemctl start/stop/restart in the usual way.

Practical Management Scenarios

Applying changes to a service’s configuration

Edit the service’s configuration file (often under /etc/, such as /etc/ssh/sshd_config).
Check for syntax errors (if the service provides a test command).
Reload or restart the service:

   sudo systemctl reload ssh   # preferred if supported
   # or:
   sudo systemctl restart ssh

Check status and logs:

   systemctl status ssh
   journalctl -u ssh -b -n 20

Recovering from a failed service

If a service shows failed:

Inspect status:

   systemctl status myservice

Read logs:

   journalctl -u myservice -b

Fix configuration or environment.
Try to start again:

   sudo systemctl start myservice

If the problem persists, check enablement:

   systemctl is-enabled myservice

Temporarily stopping a service for maintenance

Example: stopping a web server to update content:

sudo systemctl stop nginx
# Perform maintenance work
sudo systemctl start nginx

If you want to make sure it stays off even across reboots:

sudo systemctl disable nginx
# or for absolute prevention:
sudo systemctl mask nginx

Useful `systemctl` Options and Shortcuts

--now – apply change immediately and affect enablement:

  sudo systemctl enable --now ssh
  sudo systemctl disable --now ssh

--failed – list units that are in a failed state:

  systemctl --failed

daemon-reload – if you change unit files themselves (service definitions), you must tell systemd to reload its configuration:

  sudo systemctl daemon-reload

This is not needed for ordinary application config changes (like /etc/ssh/sshd_config), only for changes to *.service or other unit files.

systemctl help <unit> – open the man page for the unit if installed:

  systemctl help ssh

Summary of Common Service Management Commands

For quick reference:

# Check status
systemctl status NAME
systemctl is-active NAME
systemctl is-enabled NAME
# List services
systemctl list-units --type=service
systemctl list-unit-files --type=service
# Start/stop/restart
sudo systemctl start NAME
sudo systemctl stop NAME
sudo systemctl restart NAME
sudo systemctl reload NAME
sudo systemctl reload-or-restart NAME
# Conditional actions
sudo systemctl try-restart NAME
sudo systemctl reload-or-try-restart NAME
# Boot-time behavior
sudo systemctl enable NAME
sudo systemctl disable NAME
sudo systemctl enable --now NAME
sudo systemctl disable --now NAME
# Strong disable
sudo systemctl mask NAME
sudo systemctl unmask NAME
# Logs
journalctl -u NAME
journalctl -u NAME -f
journalctl -u NAME -b
# Dependencies
systemctl list-dependencies NAME
systemctl list-dependencies --reverse NAME

With these commands, you can confidently manage most systemd-based services on a Linux system.

Comments

Please login to add a comment.

Don't have an account? Register now!