Process & Resource Monitoring (Top/Htop/Ps/Systemd)

Stop your custom systemd services from silently eating their own exit status

🧩 The Challenge

Dealing with a service that crashes intermittently is a nightmare when systemd just shows a generic “failed” status and dumps the logs into a void. You end up guessing why it died instead of knowing if it was a segmentation fault or just a bad config parse.

💡 The Fix

Flip a specific setting in your unit file to force the service to keep its process state around long enough for you to actually see what happened. It saves you from tailing journalctl for ten minutes just to catch a flicker of an error.

[Service]
Restart=on-failure
RemainAfterExit=yes
StartLimitIntervalSec=0

⚙️ Why It Works

By setting RemainAfterExit, systemd treats the service as active even after the main process dies, which keeps the exit code pinned to the status report. This prevents the cleanup logic from scrubbing the state before you’ve had a chance to run systemctl status.

🚀 Pro-Tip: Pair this with RestartSec=5 to keep the service from hammering your CPU during a boot-loop.

Linux Tips & Tricks | © ngelinux.com | 8/1/2026