TopicLinux →
⌚ About 2 min read
systemctl gives the immediate state of the service while journalctl often explains why the main process has stopped.
Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.
Étapes à suivre
-
1
Read the status
Run systemctl status on the service.
-
2
View the dedicated logs
Use journalctl -u for the period of the incident.
-
3
Check configuration
Run the service specific test command if it exists.
-
4
Control of dependencies and ports
Check files, permissions, DNS and occupied ports.
-
5
Restart after correction
Re-launch only after identifying and correcting the error.
Commands utiles
systemctl status nginx
journalctl -u nginx -- (1989) '-30 min'
ss -intup
À retenir
- A repeat ROUND can erase the useful context of the first failure.
- Use journalctl --(3) to reduce noise.
- Check configuration changes just before the incident.
systemd: state, journal, dependencies and timers
Technical checkpoints
- systemctl status gives the latest state, while journalctl -u shows chronology and full service messages.
- Restart= can create a loop that hides the first error; read the journal from boot or the initial timestamp.
- For a timer, distinguish the .timer unit from the triggered .service unit and compare LAST/NEXT.
Service / timer
Read state, dependencies and journal before restarting.
systemctl status myservice
journalctl -u myservice --since today
systemctl list-timers --allTopic-specific pitfalls
- daemon-reload reloads unit definitions but does not automatically restart the service.
- A successful timer can trigger a service that fails: inspect both units.
How to validate
- The service remains active/running across several cycles or the timer triggers the expected execution.
- The journal no longer contains the original failure after a representative test.