Some systemctl Tricks I Wish I Knew Earlier

Evan Lee — Fri, 17 Apr 2026 15:54:30 +0000

Some Less Obvious systemctl Tricks I Only Learned After Using It for a While

I’ve been using systemd for a while now, mostly just the usual start, stop, status, nothing fancy.

But after running into a few annoying issues, I realized there are a bunch of systemctl things that aren’t obvious at first but end up being pretty useful.

Just writing a few of them down so I don’t forget.

1. `systemctl restart` is not always what you want

I used to blindly run:

systemctl restart myservice

But that actually does a full stop + start. If your service supports reload, sometimes this is better:

systemctl reload myservice

Or even:

systemctl reload-or-restart myservice

This one is nice because it tries reload first, and only restarts if reload isn’t supported.

2. Checking logs without guessing the journal

Instead of manually digging into logs, you can just do:

journalctl -u myservice -f

It basically acts like tail -f but scoped to the service.

I didn’t use this at first and kept checking random log files. This is much cleaner.

3. Why your service “fails instantly”

This one confused me for a while.

If your service runs something quick (like a script that exits), systemd might mark it as failed even though nothing is actually wrong.

The fix is usually in the service file:

Type=oneshot

or adding:

RemainAfterExit=yes

Otherwise systemd expects a long-running process.

4. `systemctl daemon-reexec` vs `daemon-reload`

I always used:

systemctl daemon-reload

which reloads unit files.

But there’s also:

systemctl daemon-reexec

This one actually restarts systemd itself (without rebooting the system).

I don’t use it often, but it’s good to know when systemd itself gets into a weird state.

5. Masking a service (stronger than disable)

I used to think disable was enough:

systemctl disable myservice

But it can still be started manually or by dependencies.

If you really want to prevent it from ever running:

systemctl mask myservice

This basically links it to /dev/null.

Took me a while to realize this existed.

6. Seeing why something started

Sometimes a service starts and you have no idea why.

This helps:

systemctl list-dependencies --reverse myservice

It shows what depends on it, which usually explains why it got pulled in.

Final note

None of these are super advanced, but they’re the kind of things I wish I knew earlier.

Most of my interaction with systemd is still just start/stop, but once you run into edge cases, these commands start to matter a lot more.

DEV Community: Evan Lee