Skip to main content
What is systemctl? - Virtarix Blog

What is systemctl?

November 28, 2025 · Blog / Technical Guides

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.

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.

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 service unit

Define the Nginx unit dependencies
[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.

[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

Enable a unit under the multi-user target
[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:

Show the Nginx service status
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):

Start Nginx
systemctl start nginx

No output indicates success. To start and enable simultaneously:

Enable and start Nginx
systemctl enable --now nginx

Stopping services

Stop running the service gracefully:

Stop Nginx gracefully
systemctl stop nginx

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

Safety check: Confirm the target and keep a recent backup or snapshot. Preview the affected resources where possible, and document a tested recovery or rollback path before running this command.

Force-kill Nginx with SIGKILL
systemctl kill -s SIGKILL nginx

Restarting services

Restart service to apply configuration changes:

Restart Nginx
systemctl restart nginx

Verify the configuration before restarting critical services to avoid disruption.

Reloading configuration

Apply new settings without stopping the service:

Reload the Nginx configuration
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:

Enable Nginx at boot
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:

Disable Nginx at boot
systemctl disable nginx

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

Checking service state

Verify boot configuration:

Check whether Nginx is enabled
systemctl is-enabled nginx

Check active status:

Check whether Nginx is active
systemctl is-active nginx

Check failure status:

Check whether Nginx has failed
systemctl is-failed nginx

These commands return simple yes/no responses, suitable for scripts and automation.

Listing units

View all loaded services:

List the loaded service units
systemctl list-units --type=service

View all installed unit files regardless of status:

List the installed unit files
systemctl list-unit-files

Show only failed units:

List the failed units
systemctl --failed

Viewing unit files

Display complete configuration in use:

Show the Nginx unit file and drop-ins
systemctl cat nginx

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

Editing unit files

Open the editor to modify the service:

Edit an Nginx service override
systemctl edit nginx

Creates override files safely. For complete replacement:

Replace the complete Nginx unit file
systemctl edit --full nginx

systemd automatically reloads after saving changes.

Masking services

Completely prevent service execution:

Mask the Nginx service
systemctl mask nginx

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

Unmask the Nginx service
systemctl unmask nginx

Use masking to guarantee service remains disabled.

Reloading systemd configuration

Reload all unit files:

Reload the systemd manager configuration
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:

List active systemd timers
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:

Define a custom application service
[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:

Load start and enable the custom application service
systemctl daemon-reload
systemctl start myapp
systemctl enable myapp

Viewing logs with journalctl

journalctl queries the systemd journal for detailed logs:

Show the Nginx journal logs
journalctl -u nginx

Follow logs in real-time:

Follow the Nginx journal logs
journalctl -u nginx -f

Show recent entries only:

Show the latest 50 Nginx journal entries
journalctl -u nginx -n 50

Filter by time:

Show Nginx logs from the past hour
journalctl -u nginx --since "1 hour ago"

Managing system state

Control server power states:

Power off reboot suspend or hibernate the system
systemctl poweroff
systemctl reboot
systemctl suspend
systemctl hibernate

Troubleshooting common issues

Service failures

Check service status first:

Show the status of a named service
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:

Validate Nginx Apache and SSH configurations
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:

Find processes listening on port 80
ss -tlnp | grep :80
netstat -tlnp | grep :80

Permission issues appear as "permission denied" errors. Verify file ownership matches the User directive:

Inspect and correct a file's permissions
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:

Show service status and resource usage
systemctl status service-name

Restart loops

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

Show the active unit and restart policy
systemctl cat service-name

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

View detailed error logs:

Show error-level service logs
journalctl -u service-name -p err

Resolve root cause before clearing failed state:

Reset and restart a failed service
systemctl reset-failed service-name
systemctl start service-name

Unit file changes not applied

After manual file edits, reload systemd:

Reload systemd and restart a changed service
systemctl daemon-reload
systemctl restart service-name

Verify active file location:

Show the active service unit path
systemctl show -p FragmentPath service-name

Permission and SELinux issues

Check file permissions:

Check a file's permissions
ls -l /path/to/file

Correct ownership and permissions:

Set file ownership and executable permissions
chown user:group /path/to/file
chmod 755 /path/to/executable

On SELinux-enabled systems, verify security contexts:

Show a file's SELinux context
ls -Z /path/to/file

Restore default contexts:

Restore the default SELinux context
restorecon -v /path/to/file

For permanent context changes:

Assign and restore a permanent SELinux context
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:

List a service's dependencies
systemctl list-dependencies service-name

Check for configuration problems:

Verify a systemd service unit
systemd-analyze verify service-name.service

Finding all failed units

View all failed services:

List all failed units
systemctl --failed

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

Reset all failures after repairs:

Reset all failed unit states
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.

Peter French
About the Author Peter Frenchis the Managing Director at Virtarix, with over 17 years in the tech industry. He has co-founded a cloud storage business, led strategy at a global cloud computing leader, and driven market growth in cybersecurity and data protection.