What is systemctl?

systemctl is the command-line tool for managing systemd, the service manager on modern Linux distributions. It controls system services, including starting, stopping, enabling, disabling, and monitoring processes.

The current stable version is systemd 258 (September 2025). Version 259 is in the release candidate stage as of November 2025. systemd 258 removes cgroup v1 support and requires kernel 5.4 or higher. System V service script support remains deprecated and scheduled for removal in systemd 260.

This guide covers essential systemctl commands, unit file structure, and troubleshooting techniques for system administrators.

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.

Common operations include starting web servers, stopping databases, configuring boot behavior, and monitoring service health. All systemctl operations work with unit files that define service behavior.

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 at specific times, replacing traditional cron jobs with better integration.
• 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:

/lib/systemd/system/ contains system defaults installed with packages.

/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

Unit files consist of three primary sections.

[Unit] Section

This section contains metadata and dependencies:

• Description provides a human-readable name for the service.
• After ensures this service starts after the specified units finish loading.
• Before ensures this service completes, before the specified units start.
• Requires creates hard dependencies. If required units fail, this service won’t start.
• Wants creates optional dependencies. This service starts even if the wanted units fail.

Example configuration:

[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 the stop command. Without this, systemd sends SIGTERM to the main process.

Restart controls automatic restart:

• always – Restart regardless of exit status
• 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.

Example configuration:

[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 service immediately (does not persist across reboots):

systemctl start nginx

No output indicates success. To start and enable simultaneously:

systemctl enable --now nginx

Stopping Services

Stop running the service gracefully:

systemctl stop nginx

The service receives cleanup time before shutdown. For unresponsive services:

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

Reloading maintains connections while applying new settings. Not all services support reload operations.

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

Currently running services remain active. This only affects boot behavior.

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 return simple yes/no responses, suitable for scripts and automation.

Listing Units

View all 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 override files safely. For complete replacement:

systemctl edit --full nginx

systemd automatically reloads after saving changes.

Masking Services

Completely prevent service execution:

systemctl mask nginx

Masking links the unit file to /dev/null. Nothing can start it until unmasked:

systemctl unmask nginx

Use masking to guarantee service remains disabled.

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

Command	Purpose
systemctl status SERVICE	Check service state and logs
systemctl start SERVICE	Start service now
systemctl stop SERVICE	Stop service
systemctl restart SERVICE	Restart service
systemctl reload SERVICE	Reload config without restart
systemctl enable SERVICE	Auto-start at boot
systemctl disable SERVICE	Prevent auto-start
systemctl enable –now SERVICE	Enable and start together
systemctl is-enabled SERVICE	Check boot status
systemctl is-active SERVICE	Check running status
systemctl is-failed SERVICE	Check failure status
systemctl list-units –type=service	List all services
systemctl –failed	Show failed units
systemctl daemon-reload	Reload unit files
systemctl edit SERVICE	Edit with overrides
systemctl cat SERVICE	View unit file
systemctl mask SERVICE	Prevent all starts
systemctl unmask SERVICE	Allow starts again

Advanced Features

Systemd Timers

Timers replace cron jobs with better systemd integration. Implementation requires two files: a .timer unit for scheduling and a .service unit for task definition.

View all active timers and next run times:

systemctl list-timers

Timers provide superior logging and dependency management compared to traditional cron.

Custom Unit Files

Create custom services in /etc/systemd/system/. Basic template:

[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

Control server power states:

systemctl poweroff
systemctl reboot
systemctl suspend
systemctl hibernate

Troubleshooting Common Issues

Service Failures

Check service status first:

systemctl status service-name

Output includes exit codes: 0 indicates success, non-zero indicates errors (1 for general errors, 2 for command misuse, 126 for execution permission issues, 127 for command not found).

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 appear as “permission denied” errors. Verify file ownership matches the User directive:

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

Resource limits cause crashes from insufficient memory or CPU. Check resource usage in the status output:

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

Correct ownership and permissions:

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 permanent context changes:

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

Conclusion

This guide covers essential systemctl functionality for managing Linux services. Core commands (status, start, stop, restart, enable, disable) handle daily operations. Unit file knowledge enables service customization and creation. Troubleshooting techniques provide quick problem diagnosis and resolution.

Key practices: use systemctl edit for safe modifications, check logs with journalctl during failures, verify configurations before restarting critical services, and run daemon-reload after manual edits. For comprehensive information, consult the man pages (man systemctl, man systemd) and official documentation at systemd.io.