A service runs after I start it but is gone after a reboot — diagnose and fix.
A teammate started a new service by hand and it worked. After the next reboot it is not running. You inspect it:
$ systemctl status myapp
● myapp.service - My App
Loaded: loaded (/etc/systemd/system/myapp.service; disabled; preset: disabled)
Active: inactive (dead)
$ systemctl is-enabled myapp
disabled
$ journalctl -b -u myapp
-- No entries --
Explain why it did not come back after the reboot, and give the exact fix.
The unit is disabled, so nothing pulled it in at boot — start had run it for that session only. start runs a unit now but does not survive reboot; enable creates the WantedBy symlink so it boots but not now. The empty journalctl -b shows it never started. Fix: systemctl enable --now myapp.
- ✗Confusing
start(run now) withenable(start at boot) - ✗Re-running
startafter every reboot instead of enabling once - ✗Reading an empty
journalctl -bas a crash rather than never starting
- →What symlink does
systemctl enablecreate, and in which directory? - →How does a
maskedunit differ from a merelydisabledone?
Solution
Cause. The key word in systemctl status is disabled, and is-enabled confirms disabled. The unit is loaded (Loaded: loaded) but not enabled, so nothing pulled it in at boot — there is no symlink in any ….target.wants/. The teammate ran systemctl start, which launched the service for the current session only; that state does not survive a reboot. The empty journalctl -b -u myapp (-- No entries --) is not a crash — it means the service never started this boot at all.
start versus enable (the confusion):
systemctl start myapp # run NOW; does not survive a reboot
systemctl enable myapp # start at boot (WantedBy symlink); does NOT run it now
systemctl enable --now myapp # both
Fix:
systemctl enable --now myapp
systemctl is-enabled myapp # → enabled