Systemd and Service Management — Start, Stop, Enable Services and Use Journalctl

You just installed an application on your server and need to start it. Or maybe a service stopped responding and you don't know where to check the logs. If you work with Linux, sooner or later you'll face systemd — the init system that manages services, sockets, mounts, timers. Knowing how to use systemd and journalctl can save you from long debugging sessions.

We at Meteora Web have been managing servers since 2017. We've seen services failing to start because of a typo in the unit file, logs piling up without rotation, startup slowdowns. Every time the solution is the same dozen commands. You don't need a sysadmin certification. Just learn the basics of systemd and apply them methodically.

This guide cuts to the chase: starting, stopping, restarting a service; enabling it on boot; checking its status; and – most valuable – reading logs with journalctl. No abstract theory — real commands, real examples, common pitfalls. For a broader view on Linux for developers and sysadmins, start with our dedicated pillar.

How to start and stop a service with systemd?

The core command is systemctl. It controls every service. The pattern is: systemctl [action] [service-name]. The service name is the unit file name (without the .service extension).

Start a service immediately

sudo systemctl start nginx

This starts Nginx right away, but does not enable it on boot. If you reboot the server, the service won't restart. Many forget this and wonder why the site is down after a reboot.

Stop a service

sudo systemctl stop nginx

Stops the process. Dependent services are stopped as well — another convenience of systemd.

Restart a service

sudo systemctl restart nginx

Equivalent to stop + start. Useful after configuration changes. To avoid downtime, use reload if the service supports it:

sudo systemctl reload nginx

This tells Nginx to reload its config without closing active connections.

Check the status

systemctl status nginx

Shows whether it's active, the PID, uptime, and the last lines of logs. This is the first command we run when a client says “the site is down.”

Common mistake: seeing "active (exited)" for services like networking – normal, it's not a long-running daemon.

How to enable a service on boot?

A service started with start won't survive a reboot. To make it persistent:

Enable and disable

sudo systemctl enable nginx

Creates symlinks in the appropriate boot targets. From then on, systemd will start Nginx at every boot. To remove:

sudo systemctl disable nginx

Check enable status

systemctl is-enabled nginx

Returns enabled, disabled or static (for services that can't be individually enabled).

One command that combines start + enable

sudo systemctl enable --now nginx

Enables on boot and starts immediately. Our go-to when setting up a new server: one line, no forgetfulness.

Note: Some services (e.g., Type=oneshot) may not support enable in the classic sense. Check your service's documentation.

How to read logs with journalctl?

Before systemd, logs were scattered across /var/log/syslog, /var/log/messages, etc. systemd centralized everything into journald. The command to read it is journalctl.

Read all system logs

journalctl

Dumps everything – thousands of lines. Useless alone. You need filters.

Logs of a single service

journalctl -u nginx

Shows only logs from the Nginx daemon. Already more useful, but if the service has been running for days, you'll still get hundreds of lines.

Last N lines

journalctl -u nginx -n 50

Last 50 lines. Our default when someone reports a recent error.

Follow logs in real time

journalctl -u nginx -f

Like tail -f, but for systemd logs. Perfect for monitoring while reproducing a bug.

Filter by time interval

journalctl -u nginx --since "2025-12-01 10:00:00" --until "2025-12-01 12:00:00"

Date format YYYY-MM-DD HH:MM:SS. You can also use yesterday, today:

journalctl -u nginx --since yesterday

Show only errors

journalctl -p err -u nginx

The -p (priority) flag filters by level: emerg, alert, crit, err, warning, notice, info, debug.

Common mistake: running journalctl without sudo and seeing only your user logs. System logs require privileges.

How to create and modify a systemd unit file?

You won't always manage existing services. Sometimes you need to create your own daemon – for a Node.js app, a Python script, a worker. Unit files live in /etc/systemd/system/ (for custom) or /lib/systemd/system/ (system ones).

Minimal unit file structure

[Unit]
Description=My Custom Python Service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=always
User=myappuser

[Install]
WantedBy=multi-user.target

[Unit]: description and dependencies (After tells systemd to start after network is up).
[Service]: command, user to run as, restart policy. Restart=always restarts the service if it crashes – essential for a worker.
[Install]: needed for enabling on boot.

Activate the new service

sudo systemctl daemon-reload       # reload unit files
sudo systemctl enable --now myapp  # enable and start

If you edit the unit file after initial activation, run daemon-reload before a restart.

Which systemd commands to diagnose a failing service?

When a service refuses to start, follow this sequence:

1. Check status: systemctl status service-name – the last log lines often contain the error.
2. Read the journal: journalctl -xu service-name – -x adds readable explanations, -u filters by unit.
3. Verify unit file syntax: systemd-analyze verify /etc/systemd/system/service-name.service – reports syntax errors.
4. Check permissions and paths: systemd usually runs services as a specific user. If the script accesses files without proper permissions, it fails.

We once saw a service failing because ExecStart contained an unescaped space. A tiny typo – without journalctl we'd have wasted an hour.

What to do next

You have the tools. Put them into practice now:

1. Log into a Linux server (even a local VM) and start a service like Nginx or Apache with systemctl start.
2. Enable it on boot with systemctl enable --now.
3. Break something intentionally: change a config, stop the service, look at the log with journalctl -u service -n 20.
4. Create a unit file for a simple script (e.g., one that writes "Hello" every minute with a timer) and test it.
5. Read the official documentation of systemd: systemctl man page — it's your best friend.

Systemd is not a monster. It's a precise and powerful set of commands. When a service won't start, you don't need to know everything about Linux – you just need a clear mental sequence. And now you have it.