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.

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

“`systemd title="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

```systemd title="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:

“`bash title="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):

```bash title="Start Nginx"
systemctl start nginx

No output indicates success. To start and enable simultaneously:

“`bash title="Enable and start Nginx" systemctl enable –now nginx

### Stopping services

Stop running the service gracefully:

```bash title="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.

“`bash title="Force-kill Nginx with SIGKILL" systemctl kill -s SIGKILL nginx

### Restarting services

Restart service to apply configuration changes:

```bash title="Restart Nginx"
systemctl restart nginx

Verify the configuration before restarting critical services to avoid disruption.

Reloading configuration

Apply new settings without stopping the service:

“`bash title="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:

```bash title="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:

“`bash title="Disable Nginx at boot" systemctl disable nginx

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

### Checking service state

Verify boot configuration:

```bash title="Check whether Nginx is enabled"
systemctl is-enabled nginx

Check active status:

“`bash title="Check whether Nginx is active" systemctl is-active nginx

Check failure status:

```bash title="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:

“`bash title="List the loaded service units" systemctl list-units –type=service

View all installed unit files regardless of status:

```bash title="List the installed unit files"
systemctl list-unit-files

Show only failed units:

“`bash title="List the failed units" systemctl –failed

### Viewing unit files

Display complete configuration in use:

```bash title="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:

“`bash title="Edit an Nginx service override" systemctl edit nginx

Creates override files safely. For complete replacement:

```bash title="Replace the complete Nginx unit file"
systemctl edit --full nginx

systemd automatically reloads after saving changes.

Masking services

Completely prevent service execution:

“`bash title="Mask the Nginx service" systemctl mask nginx

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

```bash title="Unmask the Nginx service"
systemctl unmask nginx

Use masking to guarantee service remains disabled.

Reloading systemd configuration

Reload all unit files:

“`bash title="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:

```bash title="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:

“`systemd title="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:

```bash title="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:

“`bash title="Show the Nginx journal logs" journalctl -u nginx

Follow logs in real-time:

```bash title="Follow the Nginx journal logs"
journalctl -u nginx -f

Show recent entries only:

“`bash title="Show the latest 50 Nginx journal entries" journalctl -u nginx -n 50

Filter by time:

```bash title="Show Nginx logs from the past hour"
journalctl -u nginx --since "1 hour ago"

Managing system state

Control server power states:

“`bash title="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:

```bash title="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:

“`bash title="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:

```bash title="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:

“`bash title="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:

```bash title="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:

“`bash title="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:

```bash title="Show error-level service logs"
journalctl -u service-name -p err

Resolve root cause before clearing failed state:

“`bash title="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:

```bash title="Reload systemd and restart a changed service"
systemctl daemon-reload
systemctl restart service-name

Verify active file location:

“`bash title="Show the active service unit path" systemctl show -p FragmentPath service-name

### Permission and SELinux issues

Check file permissions:

```bash title="Check a file's permissions"
ls -l /path/to/file

Correct ownership and permissions:

“`bash title="Set file ownership and executable permissions" chown user:group /path/to/file chmod 755 /path/to/executable

On SELinux-enabled systems, verify security contexts:

```bash title="Show a file's SELinux context"
ls -Z /path/to/file

Restore default contexts:

“`bash title="Restore the default SELinux context" restorecon -v /path/to/file

For permanent context changes:

```bash title="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:

“`bash title="List a service's dependencies" systemctl list-dependencies service-name

Check for configuration problems:

```bash title="Verify a systemd service unit"
systemd-analyze verify service-name.service

Finding all failed units

View all failed services:

“`bash title="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:

```bash title="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.