Cette antisèche systemctl et journalctl met les commandes que vous tapez vraiment tout en haut, parce qu'un truc est tombé, un service censé tourner ne tourne pas, et vous avez un terminal ouvert et une vague boule au ventre. Vous n'avez pas envie d'une visite guidée de la philosophie de systemd, là, maintenant. Vous voulez savoir si nginx est vivant, pourquoi il est mort, et comment le relancer. Voilà donc exactement ce qui est ici : status, restart, reload, enable --now, daemon-reload après avoir édité un unit, et journalctl pour suivre les logs en direct. Copiez une commande, remplacez le nom du service, repartez.
The short answer
Le duo qui fait presque tout le boulot : systemctl status nginx pour l état actif, le
PID principal et les dernières lignes de log, systemctl restart nginx pour lui donner un
coup de pied (ou reload pour éviter de couper les connexions), systemctl enable --now nginx
pour démarrer maintenant et au boot, systemctl daemon-reload après avoir édité un unit, et
journalctl -u nginx -f pour regarder les logs en direct.
Un truc est tombé. Un service censé tourner ne tourne pas, vous avez un terminal ouvert et une vague boule au ventre. Vous n'avez pas envie d'une visite guidée de la philosophie de systemd, là, maintenant. Vous voulez savoir si nginx est vivant, pourquoi il est mort, et comment le relancer. Voilà donc ce qui est tout en haut : status, restart, et suivre les logs. Vous copiez, vous remplacez le nom du service, vous repartez.
Deux outils font presque tout le boulot ici. systemctl pilote les services : les démarrer, les arrêter, les brancher au démarrage. journalctl lit les logs que systemd collecte pour chacun de ces services. C'est un duo. Vous tapotez un service avec l'un, puis vous lisez ce qu'il a eu à dire avec l'autre.
Il tourne ? Et pourquoi il s'est arrêté ?
C'est la première chose que vous tapez, à chaque fois. systemctl status nginx vous dit si le service est actif, quand il a démarré ou planté la dernière fois, le PID du processus principal, et (la partie que les gens loupent) les dix dernières lignes de log juste en dessous. Une fois sur deux, la raison de la mort est là, en clair, et vous n'avez même pas encore besoin de journalctl.
| Commande | Ce qu'elle fait |
|---|---|
systemctl status nginx | L'image complète : actif ou mort, le PID, le temps de fonctionnement, et les logs récents |
systemctl is-active nginx | Un seul mot en retour : active ou inactive. Parfait dans un script |
systemctl is-enabled nginx | Va-t-il remonter au boot ? enabled, disabled, ou masked |
systemctl list-units --type=service --state=running | Tous les services actuellement en marche, un seul écran |
La sortie de status est colorée. Une pastille verte veut dire actif, une rouge veut dire qu'il a échoué et que vous avez de la lecture devant vous. Si vous ne retenez qu'une commande de toute cette page, que ce soit celle-là. Tout le reste, c'est de la suite.
Démarrer, arrêter, redémarrer, recharger
Les verbes que vous devineriez sont les verbes qui marchent. La seule subtilité à trimballer : restart arrête et redémarre complètement le processus (il coupe les connexions en cours une fraction de seconde), alors que reload demande au service de relire sa config sans mourir. Reload est plus doux. Mais tous les services ne le gèrent pas, donc ce n'est pas gratuit.
| Commande | Ce qu'elle fait |
|---|---|
systemctl start nginx | Démarrer le service maintenant (ne touche pas au boot) |
systemctl stop nginx | L'arrêter maintenant |
systemctl restart nginx | Arrêt puis démarrage, la solution brute qui débloque la plupart des états bizarres |
systemctl reload nginx | Relire la config sans redémarrage complet, si le service le permet |
Quand vous n'êtes pas sûr qu'un service gère le reload, faites un restart. Un restart marche toujours et la coupure n'est en général qu'une fraction de seconde. Reload, c'est le geste plus élégant sur une machine de prod chargée où couper les connexions compte vraiment, genre un serveur web en plein trafic. Sur votre portable ? Honnêtement, redémarrez et arrêtez de vous prendre la tête.
Faire en sorte qu'il survive à un reboot
Voilà la distinction qui piège tout le monde une fois. start lance un service tout de suite mais l'oublie au reboot. enable le branche au démarrage mais ne le lance pas dans la seconde. Vous voulez presque toujours les deux, et c'est pour ça que enable --now existe : l'activer et le démarrer en une seule ligne.
| Commande | Ce qu'elle fait |
|---|---|
systemctl enable --now nginx | Démarrer maintenant et à chaque boot. Celle que vous voulez neuf fois sur dix |
systemctl enable nginx | Le régler pour démarrer au boot seulement, le laisser tranquille jusque-là |
systemctl disable nginx | L'empêcher de remonter au boot (il continue de tourner jusqu'à un stop) |
systemctl disable --now nginx | Désactiver et arrêter d'un coup |
Oublier enable, c'est le grand classique. Vous installez un truc, vous le démarrez à la main, vous testez, vous considérez que c'est plié. Puis la machine reboote trois semaines plus tard et le service a simplement disparu, et vous passez dix minutes perplexe avant de vous souvenir que vous ne l'avez jamais activé. Vous construisez un unit de zéro et vous voulez le squelette correct ? Notre générateur de fichier service systemd écrit l'unit et vous donne la commande enable assortie.
Après avoir édité un unit : daemon-reload
C'est l'étape oubliée, et elle mérite toute une section parce que la sauter fait perdre plus de temps que n'importe quelle autre erreur de cette page. Systemd garde chaque fichier unit en mémoire. Éditez /etc/systemd/system/truc.service et vos changements restent sur le disque à ne rien faire, parce que systemd fait toujours tourner l'ancienne copie d'avant votre modification.
| Commande | Ce qu'elle fait |
|---|---|
systemctl daemon-reload | Relire chaque fichier unit depuis le disque. À lancer après toute modif d'un .service |
systemctl restart nginx | Puis redémarrer le service pour qu'il tourne vraiment avec la nouvelle config |
L'ordre compte. On recharge le démon d'abord pour que systemd prenne le nouveau fichier, puis on redémarre le service pour que les nouveaux réglages s'appliquent. Loupez le daemon-reload et vous allez jurer que votre modif ne marche pas, redémarrer cinq fois, douter de votre santé mentale, et finir par retomber sur cette note exacte. J'y suis passé. L'indice, c'est un petit avertissement que systemd affiche quand vous redémarrez avec un unit périmé, mais ça défile vite et personne ne le lit.
Lire les logs avec journalctl
journalctl, c'est votre fenêtre sur tout ce que systemd a enregistré. L'astuce pour ne pas se noyer, c'est de filtrer, parce que par défaut il déverse le journal entier depuis la nuit des temps de la machine. Donc vous le cadrez : par service, par boot, par période, par gravité. Le flag -u (pour unit) est celui sur lequel vous vous appuierez le plus fort.
| Commande | Ce qu'elle fait |
|---|---|
journalctl -u nginx | Tous les logs d'un service, du plus ancien au plus récent, paginés |
journalctl -u nginx -f | Suivre en direct. La combinaison qui tue, défile dès qu'une ligne tombe |
journalctl -u nginx -n 100 | Juste les 100 dernières lignes pour ce service |
journalctl -b | Tout depuis ce boot, la machine entière |
journalctl -b -p err | Ce boot, erreurs seulement (priorité err et pire) |
journalctl --since "1 hour ago" | Les logs de la dernière heure. Accepte aussi --since today |
journalctl -xe | Sauter à la fin avec des indices explicatifs en plus, le réflexe après un démarrage raté |
Elles s'empilent, et c'est là que ça devient bon. journalctl -u nginx --since today -p err veut dire « erreurs de nginx, aujourd'hui seulement », et cette ligne-là transforme un mur de bruit en les trois lignes qui vous intéressent vraiment. Les priorités -p vont de emerg en descendant par err, warning, info, jusqu'à debug, et nommer un niveau affiche ce niveau et tout ce qui est plus grave.
Quand un service refuse de démarrer, lancez journalctl -xe
Un démarrage échoue et systemctl vous dit juste que l'unit est entré en état failed, ce qui est désespérément inutile tout seul. journalctl -xe est le geste réflexe juste après. Le e vous propulse aux entrées les plus récentes, le x ajoute un texte de catalogue qui explique parfois ce que veut dire un message cryptique et quoi essayer. Ça ne résout pas toujours l'enquête, mais c'est le bon premier réflexe après tout démarrage raté, et ça vaut mieux que de fixer la sortie de status nue en la suppliant d'avouer.
Trouver ce qui est cassé, et l'option nucléaire
Quand quelque chose cloche mais que vous ne savez pas encore quoi, list-units --failed est le tableau de bord. Il montre chaque unit en état d'échec dans une seule liste courte, donc au lieu de vérifier les services un par un, vous voyez tout le bazar d'un coup d'oeil. Et puis il y a le masquage, le cousin plus méchant de disable, pour quand un service refuse de rester couché.
| Commande | Ce qu'elle fait |
|---|---|
systemctl list-units --failed | Chaque unit en échec dans une liste. Commencez ici quand vous ignorez ce qui a cassé |
systemctl mask nginx | Bloquer en dur un service pour que rien, pas même une dépendance, ne puisse le démarrer |
systemctl unmask nginx | Annuler le masque pour que le service puisse tourner à nouveau |
Mask, c'est le gros marteau. disable empêche un service de démarrer au boot, mais autre chose peut quand même le tirer vers le haut comme dépendance. mask relie l'unit vers nulle part, donc il ne peut physiquement pas démarrer tant que vous ne le démasquez pas. Pratique pour un service qui n'arrête pas de renaître alors que vous voulez juste qu'il dégage un moment. Rappelez-vous juste que vous l'avez masqué, sinon vous passerez une demi-heure ahuri plus tard à vous demander pourquoi start refuse net.
Quand le journal dévore votre disque
Le journal grossit, et sur un serveur qui vit longtemps il peut avaler des gigaoctets en douce avant que vous le remarquiez. Deux commandes le tiennent à l'oeil : l'une vous dit combien de place il prend, l'autre élague les vieilles entrées par âge.
| Commande | Ce qu'elle fait |
|---|---|
journalctl --disk-usage | Combien de disque le journal occupe actuellement |
journalctl --vacuum-time=7d | Supprimer les entrées de plus de 7 jours et récupérer la place |
Je lance --disk-usage quand une machine manque mystérieusement de place, et plus souvent que je le voudrais le journal est le coupable. --vacuum-time=7d garde la dernière semaine et jette le reste. Pour un plafond permanent, vous régleriez SystemMaxUse dans /etc/systemd/journald.conf, mais pour récupérer de la place vite fait là maintenant, vacuum fait le job et vous repartez bosser.
Et après ?
Voilà l'ensemble de travail. Status pour voir ce qui est vivant, start, stop, restart et reload pour le piloter, enable --now pour que ça tienne, daemon-reload après chaque édition d'unit, et journalctl pour lire ce que tout ça a réellement enregistré. Ça couvre vraiment presque tout ce que je fais avec systemd dans une semaine normale. Les recoins profonds, je les cherche comme tout le monde.
Toujours plongé dans le shell ? Le même réflexe copier-au-lieu-de-mémoriser paie partout sous Linux. Pour écrire le fichier unit que ces commandes gèrent, le générateur de service systemd le construit pour vous. À la poursuite des connexions qu'un service a ouvertes ? Voyez nos commandes réseau Linux avec ip et ss. À la chasse à un fichier de config ou de log égaré ? L'antisèche de la commande find regroupe ces recettes de la même façon. Et quand un unit échoue parce que les permissions d'un fichier sont mauvaises, le calculateur de permissions chmod détaille ce que 644 contre 755 accorde vraiment.
Questions fréquentes
Comment vérifier qu un service tourne avec systemctl ?
Lancez systemctl status nginx, en remplaçant nginx par votre service. Il montre si le service est actif ou mort, le PID du processus principal, depuis combien de temps il tourne, et les dernières lignes de log en dessous, qui expliquent souvent un plantage à elles seules. Pour une réponse en un mot dans un script, utilisez plutôt systemctl is-active nginx.
Quelle est la différence entre restart et reload ?
Restart arrête et redémarre complètement le processus, donc il coupe brièvement les connexions en cours mais marche toujours. Reload demande au service de relire sa config sans s arrêter, ce qui est plus doux mais ne marche que si le service le gère. Sur une machine de prod chargée, faites reload quand vous pouvez. Partout ailleurs, faites restart sans vous prendre la tête.
Pourquoi ma modification systemd ne s applique pas ?
Vous avez probablement édité le fichier unit mais sauté systemctl daemon-reload. Systemd garde les fichiers unit en mémoire, donc vos changements restent sur le disque à ne rien faire tant que vous ne rechargez pas. Lancez systemctl daemon-reload d abord, puis systemctl restart nginx pour que le service prenne la nouvelle config. C est l étape la plus oubliée de systemd.
Comment suivre les logs d un service en direct ?
Lancez journalctl -u nginx -f. Le flag -u filtre sur un seul service et le -f suit le log en direct, qui défile dès qu une nouvelle ligne arrive. C est la commande la plus utile de toute la boîte à outils : ouvrez-la dans un terminal, reproduisez le bug dans un autre, et regardez l erreur apparaître instantanément. Ajoutez -p err pour n afficher que les lignes de niveau erreur.
Comment empêcher journalctl de remplir mon disque ?
Vérifiez la taille avec journalctl --disk-usage, puis élaguez les vieilles entrées avec journalctl --vacuum-time=7d, qui supprime tout ce qui a plus de sept jours et récupère la place. Pour un plafond permanent, réglez SystemMaxUse dans /etc/systemd/journald.conf. Pour une récupération ponctuelle rapide, vacuum-time fait le job tout seul.