Systemd Services & Process Management
systemctl • service files • journalctl
Production Linux systems
Created: 2026‑03‑17
Running Services Reliably with systemd

Systemd is the init system and service manager used by modern Linux distributions. This guide covers systemctl basics, NGINX and Apache2 service management, custom service files, restart policies, logging with journalctl, understanding targets, and when to reload vs restart.

systemctl nginx apache2 journalctl
root@server
# systemctl start myapp
# systemctl enable myapp
# nano /etc/systemd/system/myapp.service
[Service]
ExecStart=/usr/local/bin/myapp
Restart=always
1. systemctl Basics
Core commands

Start, stop, restart

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

Enable at boot

sudo systemctl enable nginx
sudo systemctl disable nginx

Check status

systemctl status nginx

Reload configuration without stopping

sudo systemctl reload nginx

Reload is for re-reading config files. Restart fully stops and starts the service.

2. NGINX Service Management Examples
Real‑world: nginx

NGINX is a common reverse proxy and web server. These examples show how to manage it with systemd and safely apply configuration changes.

Start, stop, restart NGINX

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

Enable NGINX at boot

sudo systemctl enable nginx
sudo systemctl disable nginx

Reload NGINX after config changes

sudo systemctl reload nginx

Use reload after editing /etc/nginx/nginx.conf or files in /etc/nginx/sites-available. Existing connections are preserved.

Test NGINX configuration before reload

sudo nginx -t

Always run nginx -t before reload or restart. It prevents bad configs from taking NGINX down.

Check NGINX service status

systemctl status nginx

View NGINX logs with journalctl

# Full log
journalctl -u nginx

# Follow in real time
journalctl -u nginx -f

# Since last boot
journalctl -u nginx -b

NGINX service file location

/lib/systemd/system/nginx.service

You normally do not edit this file directly. Use a drop‑in override instead.

Create an override for NGINX

sudo systemctl edit nginx

This opens a drop‑in file such as:

[Service]
Restart=always
RestartSec=3

Drop‑in overrides survive package updates and are the correct way to customize NGINX’s systemd behavior.

Reload systemd and apply override

sudo systemctl daemon-reload
sudo systemctl restart nginx
3. Apache2 Service Management Examples
Real‑world: apache2

Apache2 is another widely deployed web server. These examples show how to manage it with systemd, test configuration, and use overrides safely.

Start, stop, restart Apache2

sudo systemctl start apache2
sudo systemctl stop apache2
sudo systemctl restart apache2

Enable Apache2 at boot

sudo systemctl enable apache2
sudo systemctl disable apache2

Reload Apache2 after config changes

sudo systemctl reload apache2

Use reload after editing /etc/apache2/apache2.conf, vhost files in sites-available, or module configs. It avoids dropping active connections.

Test Apache2 configuration before reload

sudo apachectl configtest

Enable/disable Apache2 modules

sudo a2enmod rewrite
sudo a2dismod rewrite

Check Apache2 service status

systemctl status apache2

View Apache2 logs with journalctl

# Full log
journalctl -u apache2

# Follow in real time
journalctl -u apache2 -f

# Since last boot
journalctl -u apache2 -b

Apache2 service file location

/lib/systemd/system/apache2.service

Again, use overrides instead of editing this file directly.

Create an override for Apache2

sudo systemctl edit apache2

This opens a drop‑in file such as:

[Service]
Restart=always
RestartSec=2

Drop‑in overrides are the safe way to customize Apache’s systemd behavior across package updates.

Reload systemd and apply override

sudo systemctl daemon-reload
sudo systemctl restart apache2
4. Creating Custom Service Files
/etc/systemd/system

Custom services let you run your own applications as background daemons with automatic restarts, logging, and dependency management.

Create a service file

sudo nano /etc/systemd/system/myapp.service

Example service

[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/usr/local/bin/myapp
Restart=always
User=www-data
Group=www-data

[Install]
WantedBy=multi-user.target

Enable and start

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

Always run daemon-reload after editing service files.

5. Restart Policies
Reliability

Restart policies determine how systemd reacts when your service exits or crashes.

Common restart options

Restart=no
Restart=on-success
Restart=on-failure
Restart=always

Recommended for production apps

Restart=always
RestartSec=3

Use Restart=always for long‑running daemons. Use on-failure for batch jobs.

6. Logging with journalctl
Logs

Systemd stores logs in the journal. Every service automatically logs stdout and stderr here.

View logs for a service

journalctl -u myapp

Follow logs in real time

journalctl -u myapp -f

Show logs since boot

journalctl -b

Limit output

journalctl -u myapp --since "1 hour ago"
7. Understanding Targets
Boot levels

Targets are systemd’s version of runlevels. They group services and define system states.

Common targets

graphical.target      # GUI
multi-user.target     # CLI multi-user mode
rescue.target         # Single-user rescue
emergency.target      # Minimal environment

Check current target

systemctl get-default

Set default target

sudo systemctl set-default multi-user.target
8. Reload vs Restart
Behavior

Reload tells a service to re-read its configuration without stopping. Restart fully stops and starts the service.

Reload

sudo systemctl reload nginx

Use when:

  • Config file changed
  • Service supports reload (nginx, apache2, sshd)

Restart

sudo systemctl restart nginx

Use when:

  • Binary changed
  • Service is stuck
  • Reload is not supported
9. Real‑World Web Server Patterns
NGINX & Apache2

These patterns tie together systemd, config testing, reload vs restart, and logging for production web servers.

Safe NGINX deploy pattern

# 1. Edit config
sudo nano /etc/nginx/sites-available/example.conf

# 2. Test config
sudo nginx -t

# 3. Reload if OK
sudo systemctl reload nginx

# 4. Check status and logs
systemctl status nginx
journalctl -u nginx -f

Safe Apache2 deploy pattern

# 1. Edit vhost or module config
sudo nano /etc/apache2/sites-available/example.conf

# 2. Enable site or module if needed
sudo a2ensite example
sudo a2enmod rewrite

# 3. Test config
sudo apachectl configtest

# 4. Reload if OK
sudo systemctl reload apache2

# 5. Check status and logs
systemctl status apache2
journalctl -u apache2 -f

The pattern is always: change config → test → reload → verify status/logs. Systemd gives you the control plane; config tests and logs give you confidence.