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.
