What Is systemctl? How to Manage Linux Services

systemctl lets you check, start, stop, and configure services on Linux systems that use systemd. You can use it to find out why a web server failed, apply a service override, or choose which services start at boot.

systemd behavior varies by distribution and release. Check your installed version with systemctl --version, then compare it with your distribution’s package notes and the upstream systemd releases before relying on version-specific behavior.

The examples use Nginx; substitute the unit name installed on your server. Commands that change system services require appropriate administrative permission, usually through sudo. Read-only commands may also need elevated access to show all logs or process details.

What is systemctl?

systemctl interfaces with systemd to manage system services. It handles service control while systemd manages boot initialization, dependency resolution, and process supervision.

The tool operates on units – systemd's term for manageable resources. Services (background processes) are the most common unit type. The .service suffix is optional: both systemctl start nginx.service and systemctl start nginx work identically.

A service can be running without being enabled at boot, or enabled but currently stopped. Keep its runtime state separate from its startup configuration when troubleshooting.

Understanding units and unit files

Units

Units are resources managed by systemd. The main types include:

• Services handle background processes like nginx, mysqld, and sshd—the most frequently managed unit type for system administrators.
• Sockets are network listeners that enable socket-based activation, starting services when network requests arrive.
• Timers schedule tasks and can use systemd service dependencies and journal logging.
• Mounts represent filesystem mount points where storage connects.
• Devices manage hardware device resources.

Unit files

Unit files configure how systemd manages each unit. These plain-text configuration files use key-value pairs organized into sections.

Location hierarchy:

Package-provided units usually live in /usr/lib/systemd/system/ or /lib/systemd/system/, depending on the distribution.

/etc/systemd/system/ holds custom configurations and overrides. Files here take priority over system defaults.

Unit files define startup procedures, dependencies, restart behavior, and boot sequence integration.

Unit file structure

Service unit files commonly use these three sections. Other unit types have their own type-specific sections, such as [Timer].

[Unit] section

This section contains metadata and dependencies:

• Description provides a human-readable name for the service.
• After orders startup after the specified units when both are scheduled to start. It does not start those units or guarantee application readiness.
• Before sets the reverse startup ordering.
• Requires pulls in required units. Pair it with After when this service must wait for their activation and should not start if that activation fails.
• Wants creates optional dependencies. This service starts even if the wanted units fail.

Example service unit

[Unit]
Description=Nginx Web Server
After=network.target remote-fs.target
Requires=network.target
Wants=remote-fs.target

[Service] section

This section controls service behavior:

Type defines startup behavior:

• simple – Main process runs directly from ExecStart
• forking – Process creates a child, and the parent exits
• oneshot – Script runs once and completes

ExecStart specifies the command that launches the service.

ExecReload defines the command for reloading the configuration without a full restart.

ExecStop sets a stop command. Without one, systemd normally sends SIGTERM to the service processes; KillMode, signal settings, and timeouts affect shutdown.

Restart controls automatic restart:

• always – Restart after normal or abnormal process exit, subject to service-type and rate-limit rules; an explicit stop does not trigger a restart
• on-failure – Restart only on errors
• no – Never restart automatically

RestartSec sets the delay between restart attempts.

User and Group specify which account runs the service.

WorkingDirectory sets the process execution directory.

[Install] section

This section handles boot integration:

WantedBy specifies which target should pull in this service when enabled. Common targets include multi-user.target for console systems and graphical.target for desktop environments.

Example configuration

[Install]
WantedBy=multi-user.target

Editing best practices

Use systemctl edit service-name to modify services. This creates override files in /etc/systemd/system/service-name.service.d/override.conf instead of modifying system files directly. Changes survive system updates.

For complete replacement, use systemctl edit --full service-name. This copies the entire unit file to /etc/systemd/system/ for editing.

Essential systemctl commands

Checking service status

View service state, process details, and recent activity:

systemctl status nginx

Output shows whether the service is active (running), inactive (stopped), or failed, including recent log entries.

Starting services

Start the service now without changing whether it is enabled at boot:

systemctl start nginx

A successful command often prints nothing. Check its exit status and then systemctl status nginx; the application can still fail after startup. To start and enable it together:

systemctl enable --now nginx

Stopping services

Stop running the service gracefully:

systemctl stop nginx

The unit configuration controls cleanup and the stop timeout. If a service remains unresponsive after normal stopping, inspect its processes and logs before considering a forced kill.

Before force-killing: Confirm the exact unit and affected requests. SIGKILL prevents process cleanup and can interrupt writes, so check backup and recovery options first. This is a last-resort diagnostic action, not a normal restart.

systemctl kill -s SIGKILL nginx

Restarting services

Restart service to apply configuration changes:

systemctl restart nginx

Verify the configuration before restarting critical services to avoid disruption.

Reloading configuration

Apply new settings without stopping the service:

systemctl reload nginx

Reload behavior depends on the application. Some services preserve existing connections; others may behave differently or reject reload entirely. Check the application documentation and validate its configuration first.

Enabling services at boot

Configure service for automatic startup:

systemctl enable nginx

Creates necessary systemd directory links without starting the service immediately. The enable command automatically runs daemon-reload.

Disabling services at boot

Prevent automatic boot startup:

systemctl disable nginx

Disabling removes enablement links and leaves a running service active. It may still start through a dependency, a socket or timer, or a manual request.

Checking service state

Verify boot configuration:

systemctl is-enabled nginx

Check active status:

systemctl is-active nginx

Check failure status:

systemctl is-failed nginx

These commands print states such as enabled, active, or failed and return exit codes that scripts can inspect. Use the command's documented exit status instead of expecting a literal yes or no.

Listing units

View loaded service units that are active, failed, or have a pending job. Add --all to include inactive loaded services:

systemctl list-units --type=service

View all installed unit files regardless of status:

systemctl list-unit-files

Show only failed units:

systemctl --failed

Viewing unit files

Display complete configuration in use:

systemctl cat nginx

Shows the base unit file plus any overrides or drop-ins.

Editing unit files

Open the editor to modify the service:

systemctl edit nginx

Creates a drop-in override. For a complete replacement, which can hide future package changes:

systemctl edit --full nginx

systemctl edit normally reloads the manager configuration after saving. Restart or reload the affected service separately when its changed settings require it.

Masking services

Prevent a unit from being started through systemd:

systemctl mask nginx

Masking links the unit file to /dev/null. The mask blocks systemd activation until it is removed. It does not stop an already running service unless you also request that action, and it does not prevent someone from running the underlying program directly. Unmask it with:

systemctl unmask nginx

Check the result: masking may fail if a locally created unit already occupies the target path. Use it only when blocking dependency and manual activation is intended.

Reloading systemd configuration

Reload all unit files:

systemctl daemon-reload

Required after manually editing unit files. The systemctl edit command handles this automatically.

Quick command reference

Advanced features

systemd timers

A timer can schedule a service without a cron entry. The usual setup has a .timer unit for the schedule and a .service unit for the work.

View all active timers and next run times:

systemctl list-timers

Choose timers when you want the scheduled task to use systemd service configuration, dependencies, and journal logs.

Custom unit files

Create custom services in /etc/systemd/system/. Save this example as myapp.service only after replacing the command and paths and creating the intended appuser account:

[Unit]
Description=My Custom Application
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/myapp
Restart=on-failure
User=appuser
WorkingDirectory=/opt/myapp
[Install]
WantedBy=multi-user.target

Load and start the new service:

systemctl daemon-reload
systemctl start myapp
systemctl enable myapp

Viewing logs with journalctl

journalctl queries the systemd journal for detailed logs:

journalctl -u nginx

Follow logs in real-time:

journalctl -u nginx -f

Show recent entries only:

journalctl -u nginx -n 50

Filter by time:

journalctl -u nginx --since "1 hour ago"

Managing system state

These commands affect the whole host and interrupt remote access. Choose only the action you intend, after checking workloads and console recovery access:

Suspend and hibernation are often unavailable or unsuitable on a VPS.