Managing Services with systemctl and journalctl

Short introduction (2–3 sentences)

Systemd is the init system on most modern Linux distributions, and systemctl and journalctl are the primary tools for managing services and inspecting their logs. This tutorial gives practical, beginner-friendly explanations and examples to help you start, stop, inspect, enable, and troubleshoot services using these tools.

Understanding systemctl basics

systemctl is the control interface for systemd. It manages units (services, sockets, timers, mounts, etc.), and most day-to-day service work uses a small set of commands: start, stop, restart, status, and enable/disable. Remember most systemctl commands require root privileges, so use sudo where required.

Example: check the status of the nginx service

# show status (active, loaded, last few logs)
sudo systemctl status nginx.service

Common unit types:

• .service — a service unit (daemons)
• .socket — socket activation units
• .timer — scheduled units (replacement for cron in many cases)

List active services and their states:

# list currently active services (shows only units that are loaded and active)
sudo systemctl list-units --type=service

List all installed unit files (including disabled):

# shows whether unit files are enabled, disabled, static, masked, etc.
sudo systemctl list-unit-files --type=service

Key output fields in status:

• Active: whether running (active), exited (one-shot), failed
• Loaded: where unit file was read from and whether enabled
• Main PID: process id of service process
• Recent logs: shows a few journal lines for quick diagnostics

Managing the service lifecycle

Starting, stopping and restarting are the basic lifecycle operations. Use restart for applying configuration changes that require a process restart; use reload when the service supports reloading configuration without a full restart.

Basic commands:

sudo systemctl start myservice.service    # start immediately
sudo systemctl stop myservice.service     # stop immediately
sudo systemctl restart myservice.service  # stop then start
sudo systemctl reload myservice.service   # ask service to reload config (if supported)

Testing before enabling at boot:

# start and check quickly
sudo systemctl start apache2.service
sudo systemctl status apache2.service
# if logs show a problem, stop and investigate
sudo systemctl stop apache2.service

Check if a service is running and its recent logs:

sudo systemctl status postgresql.service
# or use journalctl for more logs (see next section)

Using systemctl kill to send signals:

# send SIGTERM to main process of unit
sudo systemctl kill -s SIGTERM myservice.service
# send SIGKILL to all processes in the unit's cgroup
sudo systemctl kill -s SIGKILL --kill-who=all myservice.service

Enabling services and boot-time behavior

Enable or disable controls whether a unit is started automatically at boot. There are also mask and unmask to block units entirely.

Enable a service to start at boot:

sudo systemctl enable sshd.service
# check its symlink and status
sudo systemctl is-enabled sshd.service

Disable a service:

sudo systemctl disable cups.service
sudo systemctl is-enabled cups.service  # should print 'disabled' or 'static'

Mask to prevent accidental starts:

# mask replaces the unit with /dev/null symlink so it cannot be started
sudo systemctl mask some-service.service
# unmask when you want to allow starts again
sudo systemctl unmask some-service.service

Inspecting boot ordering and dependencies:

# see the target dependencies for multi-user runlevel
systemctl list-dependencies multi-user.target

If you change unit files or install new ones, reload the manager configuration:

# after creating or editing unit files
sudo systemctl daemon-reload
# then restart or enable as needed
sudo systemctl restart myservice.service

Inspecting logs with journalctl

journalctl reads logs gathered by systemd-journald and is the go-to tool for troubleshooting service problems. You can filter by unit, boot, priority, time ranges, and follow logs in real time.

Basic usage:

# show logs for a specific unit
sudo journalctl -u nginx.service
# follow logs in real time, like tail -f
sudo journalctl -u nginx.service -f

Filter by priority (show errors and above):

# priorities: emerg, alert, crit, err, warning, notice, info, debug
sudo journalctl -p err -u sshd.service

Filter by time range:

# since today at midnight
sudo journalctl --since "2025-10-30 00:00:00" -u myapp.service
# last 1 hour
sudo journalctl --since "1 hour ago" -u myapp.service

Inspect logs from the current boot:

sudo journalctl -b
# only logs from the last boot
sudo journalctl -b -1   # previous boot

Improve readability:

# remove journald's metadata formatting; show raw message text
sudo journalctl -u myservice.service -o cat
# avoid pager (useful in scripts)
sudo journalctl -u myservice.service --no-pager

Rotate or vacuum old journals (to free space):

# remove journal files until total size <= 500M
sudo journalctl --vacuum-size=500M
# remove all logs older than 2 weeks
sudo journalctl --vacuum-time=2weeks

Troubleshooting and editing unit files

If a service fails to start, look at status and full journal. Common causes: missing dependencies, incorrect executable path, permission issues, or wrong environment variables.

Inspect a unit's properties:

# show detailed unit properties
systemctl show myservice.service
# view only ExecStart
systemctl show -p ExecStart myservice.service

Edit a unit safely using drop-in files (recommended) or full file edits:

# create an override (drop-in) to add or change options
sudo systemctl edit myservice.service
# this opens an editor and creates /etc/systemd/system/myservice.service.d/override.conf
# after editing, always reload
sudo systemctl daemon-reload
sudo systemctl restart myservice.service

Example override to set environment variable:

[Service]
Environment="MY_ENV=production"

If you must edit the shipped unit file, use --full with edit or copy the file to /etc/systemd/system, then daemon-reload. Always check syntax and logs after restart.

Debugging tips:

• Use journalctl -u service -b to see logs from the current boot.
• Run the service's binary manually if possible to see immediate errors.
• Check file permissions and SELinux/AppArmor denials (audit logs).

Commands table

Below is a compact reference table for common systemctl and journalctl commands.

Common Pitfalls

• Forgetting to run sudo or being root: many systemctl/journalctl actions require elevated privileges.
• Editing unit files without daemon-reload: changes won’t take effect until systemctl daemon-reload is run.
• Masking units unintentionally: mask prevents starts and can be confusing; unmask when needed.

Next Steps

• Practice: try starting, stopping, enabling, and checking the logs of a non-critical service on a test machine.
• Learn unit files: read and create simple .service files to understand ExecStart, Restart, and Environment settings.
• Automate checks: write a small script that uses systemctl/is-active and journalctl to alert on service failures.

👉 Explore more IT books and guides at dargslan.com.