Managing Services with systemd: A Practical Guide

Every RHEL-family distribution – AlmaLinux, Rocky Linux, Oracle Linux, VzLinux, Fedora – uses systemd to manage services (also called units). Whether you’re starting nginx for the first time, checking why sshd won’t come up after a config change, or making sure a service survives a reboot, systemctl is the tool you’ll reach for, with journalctl alongside it for reading the logs.

The core systemctl commands

Start a service:

sudo systemctl start nginx

Stop it:

sudo systemctl stop nginx

Restart it (stops then starts – the service is briefly unavailable):

sudo systemctl restart nginx

Reload it (asks the service to re-read its configuration without a full restart – supported by most well-behaved services, and preferable when you want zero downtime, e.g. after changing an nginx vhost):

sudo systemctl reload nginx

If you’re not sure whether a service supports a clean reload, reload-or-restart will reload if it can and fall back to a restart if it can’t:

sudo systemctl reload-or-restart nginx

Check its current status – whether it’s running, when it last started, its process ID, and the last handful of log lines:

systemctl status nginx

Typical output looks like this:

● nginx.service - The nginx HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-08-25 09:02:11 UTC; 3h 12min ago
   Main PID: 1042 (nginx)
      Tasks: 3 (limit: 4653)
     Memory: 5.2M
        CPU: 71ms
     CGroup: /system.slice/nginx.service
             ├─1042 "nginx: master process /usr/sbin/nginx"
             └─1043 "nginx: worker process"

active (running) is what you want to see. Other common states are inactive (dead) (stopped), failed (it tried to start and crashed or exited with an error), and activating (still starting up).

Start on boot: enable vs. start

This is the distinction that catches people out most often: start and enable do different things.

• systemctl start runs the service now. It will not survive a reboot unless it’s also enabled.
• systemctl enable sets the service to start automatically at boot. It does not start the service now.

After installing a new service, you almost always want both. Rather than running two commands, combine them:

sudo systemctl enable --now nginx

The reverse for disabling and stopping in one go:

sudo systemctl disable --now nginx

To check whether a service is currently set to start at boot:

systemctl is-enabled nginx

And a quick way to check whether it’s currently running:

systemctl is-active nginx

This prints the state (e.g. active or inactive) and sets its exit code accordingly – add --quiet if you only want the exit code in a script, without the printed output.

Reading logs with journalctl

systemd captures the output and log messages of every service it manages via the journal, and journalctl is how you read it. This is usually your first stop when a service won’t start.

View all logs for a specific service:

journalctl -u nginx

Follow logs live, as new entries come in – similar to tail -f:

journalctl -u nginx -f

Show only the most recent lines:

journalctl -u nginx -n 50

Filter by time – everything since a given point:

journalctl -u nginx --since "1 hour ago"

Or between two points:

journalctl -u nginx --since "2026-08-25 08:00" --until "2026-08-25 09:00"

Show only logs from the current boot (handy after a reboot, to rule out anything from before it):

journalctl -u nginx -b

Show only warnings and errors, cutting out routine informational noise:

journalctl -u nginx -p warning

And a shortcut worth knowing: journalctl -xe jumps straight to the end of the entire system journal with extra explanatory context added where available – useful as a general “what just went wrong” command when you’re not sure which service to blame.

Worked example: nginx won’t start

Say you’ve just edited an nginx config file and tried to reload it, but something’s wrong:

$ sudo systemctl reload nginx
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.

Start with status, which often shows enough of the error to diagnose it immediately:

systemctl status nginx

● nginx.service - The nginx HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Tue 2026-08-25 12:41:03 UTC; 8s ago
    Process: 2210 ExecReload=/usr/sbin/nginx -s reload (code=exited, status=1/FAILURE)

If that’s not enough detail, pull the fuller log with journalctl, using -xeu as suggested (combining “extra detail”, “jump to end”, and “this unit”):

journalctl -xeu nginx

nginx: [emerg] unexpected "}" in /etc/nginx/conf.d/default.conf:14

Now you know exactly what to fix: a syntax error on line 14 of that config file. For nginx specifically, it’s also worth knowing you can test the config before reloading, which catches this kind of mistake before it takes the service down:

sudo nginx -t

Once the config file is fixed, reload again and confirm it came back up:

sudo systemctl reload nginx
systemctl status nginx

The same troubleshooting flow – status, then journalctl -xeu – applies to any service, including sshd. If you’ve just locked yourself out over SSH after a config change and have console access via your provider’s control panel, this is exactly the sequence to run to find out why sshd rejected the new config.

A quick reference

Task	Command
Start a service now	systemctl start
Stop a service	systemctl stop
Restart a service	systemctl restart
Reload config without downtime	systemctl reload
Check status	systemctl status
Enable at boot and start now	systemctl enable --now
Disable at boot and stop now	systemctl disable --now
Check if enabled at boot	systemctl is-enabled
View a service’s logs	journalctl -u
Follow logs live	journalctl -u -f
View logs with full context	journalctl -xeu

Between systemctl for controlling services and journalctl for reading what they’re telling you, you’ve got everything you need to run and troubleshoot the software on your VPS without guessing.