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.

Troubleshooting common issues

Service failures

Check service status first:

systemctl status service-name

Read the reported process result and journal together. Exit-code meanings depend on the application; systemd also reports its own execution failures, such as 203/EXEC. The exit status of systemctl status is separate from the service process exit code.

Common problems and solutions:

Configuration errors result from syntax issues. Validate with service-specific commands:

nginx -t
apachectl configtest
sshd -t

Missing dependencies occur when required services aren't running. Check requirements:

systemctl list-dependencies service-name

Port conflicts happen when another process uses the port. Identify the process:

ss -tlnp | grep :80
netstat -tlnp | grep :80

Permission issues may appear as "permission denied" errors. Inspect ownership, directory traversal, and the access needed by the service account. The following ownership and mode changes are examples; do not apply 644 to secrets or executable files without checking their requirements:

ls -l /path/to/file
chown user:group /path/to/file
chmod 644 /path/to/file

Resource pressure or limits can cause slow responses, failed allocations, or killed processes. Check the status output and journal, then compare them with host metrics and configured limits:

systemctl status service-name

Restart loops

Services that crash and restart repeatedly require underlying problem resolution. Check restart policy:

systemctl cat service-name

Review RestartSec and StartLimitBurst settings controlling restart frequency and attempt limits.

View detailed error logs:

journalctl -u service-name -p err

Resolve root cause before clearing failed state:

systemctl reset-failed service-name
systemctl start service-name

Unit file changes not applied

After manual file edits, reload systemd:

systemctl daemon-reload
systemctl restart service-name

Verify active file location:

systemctl show -p FragmentPath service-name

Permission and SELinux issues

Check file permissions:

ls -l /path/to/file

Set ownership and executable permissions only when they match the application's needs. Replace these example paths and accounts:

chown user:group /path/to/file
chmod 755 /path/to/executable

On SELinux-enabled systems, verify security contexts:

ls -Z /path/to/file

Restore default contexts:

restorecon -v /path/to/file

For a path that should contain content readable by an SELinux-confined HTTP service, a permanent mapping might use the following type. Choose the type required by the application; do not apply it to unrelated files:

semanage fcontext -a -t httpd_sys_content_t "/path/to/file"
restorecon -v /path/to/file

Dependency errors

Services fail when starting before requirements are met. Verify dependencies:

systemctl list-dependencies service-name

Check for configuration problems:

systemd-analyze verify service-name.service

Finding all failed units

View all failed services:

systemctl --failed

Prioritize critical services. Single failures often cascade to multiple failures. Resolving root causes typically fixes multiple issues.

Reset all failures after repairs:

systemctl reset-failed

A routine for service changes

Check the unit state and logs before changing anything. Validate the application configuration, make a focused override with systemctl edit, and apply the change using the service's supported reload or restart procedure. Check both the systemd state and an actual application request afterward.

Use daemon-reload after manual unit-file edits and check enablement separately from runtime state. For behavior specific to your installed release, consult man systemctl and man systemd.