Redémarrer des services bloqués en toute sécurité (sans redémarrage)

Principes : ce que signifie réellement « redémarrage sûr »

Un « redémarrage sûr » n’est pas « le service revient ». C’est « le service revient et nous n’avons pas corrompu de données, bloqué l’hôte ou déclenché une défaillance en cascade ». Ça paraît évident jusqu’à ce que vous regardiez une unité bloquée à 2 h du matin et que vos mains commencent à taper reboot par réflexe.

1) Ne redémarrez pas avant de comprendre ce qui est bloqué

Quand un service ne veut pas s’arrêter, ce n’est généralement pas de la « stubbornness » du service. Il attend quelque chose : I/O disque, un montage réseau, un verrou du noyau, une dépendance, un hook d’arrêt, un processus enfant qui ne meurt jamais, un fichier PID mensonger, ou systemd qui attend une notification qui ne viendra pas.

Si vous redémarrez aveuglément, vous transformez souvent un seul processus bloqué en scène de crime multi-processus. Surtout si vous avez des clients de base de données, des files de travail, ou des chemins de stockage impliqués.

2) Traitez l’état comme une priorité

Les services sans état sont indulgents. Les services avec état ne le sont pas. Si le service bloqué possède des données (base de données, file, export de système de fichiers, cache persistant), l’arrêter violemment peut entraîner de longs temps de récupération, des rafales de rejouage ou de la corruption. Votre rôle est de peser disponibilité immédiate contre récupération et intégrité, de manière explicite.

3) Comprenez ce que systemd fait, pas ce que vous espérez qu’il fasse

Systemd n’est pas « un script init sophistiqué ». C’est un superviseur de processus avec graphes de dépendances, watchdogs, cgroups et timeouts. Quand vous lui demandez d’arrêter quelque chose, il utilise des signaux spécifiques, dans un ordre précis, vers un ensemble précis de processus. Si c’est bloqué, la raison est généralement décodable — si vous regardez les propriétés de l’unité, l’appartenance au cgroup et le journal.

4) Escaladez la force par étapes, et annoncez ce que vous faites

Vous devriez avoir une échelle d’escalade. Commencez par des signaux gracieux et des vérifications de correction. Passez ensuite à SIGKILL, la terminaison de cgroup, ou la réinitialisation des états failed. Et quand vous le faites, communiquez. Un « redémarrage rapide » qui abandonne le travail en cours est rarement rapide pour les humains en aval.

5) Un reboot n’est pas une solution ; c’est une amputation

Rebooter fonctionne parce que ça efface l’état, réinitialise les pilotes, débloque des ressources du noyau et redémarre tout. C’est aussi pour cela que c’est dangereux : vous perdez la possibilité de diagnostiquer, vous perturbez des services non liés, et vous pouvez déclencher de longs fsck / reconstruction RAID / rejouage de journaux.

Une citation à garder sous la main, car c’est l’état d’esprit qu’il faut sous pression d’incident :

« L’espoir n’est pas une stratégie. » — Vince Lombardi

Oui, c’est issu du sport. L’exploitation est aussi un sport de contact ; l’adversaire est l’entropie.

Mode d’urgence de diagnostic rapide (premier/deuxième/troisième)

Voici la version « j’ai cinq minutes avant que le canal d’incident ne devienne une danse interprétative ». L’objectif est de localiser rapidement la classe de goulot d’étranglement : logique du service, dépendances, ressources système ou noyau/stockage.

Premier : vérifiez ce qui est réellement bloqué

1. Vérifier l’état de l’unité et les logs récents : Est-elle « activating », « deactivating », « failed », ou « running but unhealthy » ?
2. Confirmer le PID principal et les processus du cgroup : Y a‑t‑il des processus enfants ayant survécu au processus principal ?
3. Voir ce que systemd attend : timeouts, notify, watchdog, hooks ExecStop, ou ordre des dépendances.

Second : déterminer si c’est de l’I/O, des verrous ou du réseau

1. Rechercher des processus en état D : le sommeil non interruptible est un gros signal d’alerte ; tuer ne servira à rien.
2. Vérifier la pression disque : iowait élevé, périphérique saturé, multipath bloqué, système de fichiers plein.
3. Vérifier les montages réseau et la résolution de noms : les blocages NFS et les timeouts DNS font geler les scripts d’arrêt.

Troisième : choisir l’intervention à moindre risque

1. Si c’est un blocage logique : redémarrer en douceur, drainer le trafic, faire tourner le processus.
2. Si c’est un blocage de dépendance : réparer d’abord la dépendance (stockage, DNS, montage), puis redémarrer.
3. Si le noyau/stockage est wedgé : ne spamez pas les redémarrages. Choisissez entre isoler l’hôte, basculer la charge, ou redémarrer avec intention.

Petite blague n°1 : Si vous redémarrez un service cinq fois et qu’il « fonctionne aléatoirement », félicitations — vous venez d’inventer un test de charge pour votre chance.

Faits intéressants et contexte historique

• Les signaux Unix ont été conçus pour des arrêts coopératifs. SIGTERM est une demande, pas un ordre. Certains démons y répondent poliment ; d’autres l’ignorent ; certains le prennent comme un défi personnel.
• « Bloqué en état D » est plus ancien que votre pile de supervision. Le sommeil non interruptible existe depuis des décennies pendant que le noyau attend la fin d’un I/O ; c’est un indice que le problème est sous l’espace utilisateur.
• systemd a introduit le suivi par cgroup comme correction pratique du classique problème du démon qui forkait et laissait un orphelin qui hantait les scripts SysV init.
• Les fichiers PID sont un compromis historique. Ils étaient un contournement pour des superviseurs incapables de suivre fiablement des processus. Ils causent encore des incidents quand ils deviennent obsolètes.
• Les timeouts sont une habitude opérationnelle relativement moderne. Les vieux scripts init attendaient souvent indéfiniment ; les gestionnaires de services modernes supposent que « pour toujours » est inacceptable et vont escalader ou échouer.
• NFS fait geler les arrêts depuis les années 1980. Ce n’est pas malveillant ; ce sont simplement les systèmes distribués qui sont honnêtes sur leurs modes de défaillance.
• Les modes d’arrêt rapides des bases de données existent pour une raison. PostgreSQL, MySQL et d’autres distinguent entre « finir le travail », « checkpoint » et « tout lâcher », car le coût de reprise après crash est réel.
• Les watchdogs sont devenus populaires après trop de blocages silencieux. Un service « running » mais qui ne progresse pas est pire qu’un service qui plante rapidement ; les superviseurs ont ajouté des watchdogs pour forcer une décision.

Tâches pratiques : commandes, sorties et décisions

Ci‑dessous, des tâches pratiques que vous pouvez exécuter sur un hôte Linux typique utilisant systemd. Chaque tâche inclut : la commande, un exemple de sortie, ce que cela signifie, et la décision à prendre.

Task 1: Confirm the unit state and why systemd thinks it’s stuck

cr0x@server:~$ systemctl status nginx.service --no-pager
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: deactivating (stop-sigterm) since Tue 2026-02-05 02:11:27 UTC; 1min 32s ago
       Docs: man:nginx(8)
    Process: 18421 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS)
   Main PID: 17102 (nginx)
      Tasks: 5 (limit: 18958)
     Memory: 62.3M
        CPU: 3.114s
     CGroup: /system.slice/nginx.service
             ├─17102 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             ├─17105 nginx: worker process
             └─17106 nginx: worker process

Feb 05 02:11:27 server systemd[1]: Stopping A high performance web server and a reverse proxy server...
Feb 05 02:11:57 server systemd[1]: nginx.service: State 'stop-sigterm' timed out. Killing.
Feb 05 02:11:57 server systemd[1]: nginx.service: Killing process 17102 (nginx) with signal SIGKILL.

Ce que cela signifie : systemd a tenté un arrêt gracieux, a atteint un timeout, et a escaladé. Il est toujours en cours de désactivation, ce qui suggère soit que le processus n’est pas mort, soit que des enfants ont échappé, soit que le noyau ne peut pas le réappliquer.

Décision : Passez de la « vue unité » à la « vue processus ». Identifiez quels PID existent encore et dans quel état ils sont. Ne continuez pas à lancer des redémarrages ; collectez des preuves.

Task 2: Show the unit’s exact stop behavior (timeouts, kill mode)

cr0x@server:~$ systemctl show nginx.service -p TimeoutStopUSec -p KillMode -p KillSignal -p SendSIGKILL -p ExecStop -p ExecStopPost
TimeoutStopUSec=1min 30s
KillMode=control-group
KillSignal=SIGTERM
SendSIGKILL=yes
ExecStop={ path=/sbin/start-stop-daemon ; argv[]=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=18421 ; code=exited ; status=0 }
ExecStopPost=

Ce que cela signifie : systemd tuera tout le cgroup si nécessaire. Le timeout est de 90 secondes. La commande d’arrêt utilise un fichier PID ; c’est un vecteur potentiel de mensonge.

Décision : Si le fichier PID est obsolète ou incorrect, l’arrêt peut se bloquer. Vérifiez le fichier PID et si le cgroup contient encore des processus.

Task 3: Inspect the cgroup membership (what systemd thinks it owns)

cr0x@server:~$ systemd-cgls /system.slice/nginx.service
Control group /system.slice/nginx.service:
├─17102 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─17105 nginx: worker process
└─17106 nginx: worker process

Ce que cela signifie : Ce sont les processus que systemd enverra des signaux lors de l’arrêt. Si vous voyez des processus inattendus, votre service peut forker des helpers qui ne meurent jamais.

Décision : Si le cgroup est vide mais que systemd dit « stopping », vous attendez peut-être des hooks ExecStop ou un montage/DNS bloqué à l’intérieur de ceux-ci.

Task 4: Check if the process is in uninterruptible sleep (D state)

cr0x@server:~$ ps -o pid,ppid,stat,wchan:30,cmd -p 17102
  PID  PPID STAT WCHAN                          CMD
17102     1 D    nfs_wait_bit_killable          nginx: master process /usr/sbin/nginx -g daemon on; master_process on;

Ce que cela signifie : Le processus est en état D, en attente d’une fonction du noyau liée à NFS. En état D, les signaux ne seront pas traités tant que l’appel noyau ne revient pas. SIGKILL ne vous sauvera pas.

Décision : Arrêtez d’essayer de le tuer. Trouvez le montage NFS, le problème réseau/stockage, ou planifiez un basculement. Ce n’est pas un « problème nginx ».

Task 5: Identify open files/sockets that might be hanging stop

cr0x@server:~$ sudo lsof -p 17102 | tail -n 8
nginx   17102 root   10u  IPv4  541233      0t0  TCP *:http (LISTEN)
nginx   17102 root   11u  IPv4  541234      0t0  TCP *:https (LISTEN)
nginx   17102 root   12r  REG   0,37  10485760 917514 /var/log/nginx/access.log
nginx   17102 root   13r  REG   0,37   2097152 917515 /var/log/nginx/error.log
nginx   17102 root   14r  REG   0,41    131072  26233 /mnt/shared/certs/bundle.pem
nginx   17102 root   15r  REG   0,41    131072  26234 /mnt/shared/certs/key.pem

Ce que cela signifie : Le service a des fichiers ouverts sur /mnt/shared qui semblent appartenir à un système de fichiers séparé (device 0,41). Si c’est NFS et qu’il est instable, l’arrêt peut bloquer sur des opérations de fichiers.

Décision : Vérifiez le type de montage et sa santé. Si c’est un montage distant et qu’il est wedgé, réparez-le d’abord ou détachez le trafic et relocalisez.

Task 6: Confirm mount type and whether it’s a network filesystem

cr0x@server:~$ findmnt -T /mnt/shared -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET      SOURCE               FSTYPE OPTIONS
/mnt/shared nfs01:/exports/shared nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys

Ce que cela signifie : C’est NFSv4.1 avec des sémantiques de montage hard. Les montages hard peuvent bloquer les processus lors de problèmes serveur/réseau. Parfois c’est le bon choix ; ce n’est jamais gratuit.

Décision : Si NFS est instable, choisissez entre restaurer NFS, basculer le service vers un autre nœud, ou (en dernier recours) redémarrer le client pour libérer l’I/O — en sachant que le problème peut revenir si NFS reste en panne.

Task 7: Check if the host is under memory pressure or swapping (slow “stop” can be paging)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        29Gi       512Mi       1.2Gi       1.6Gi       745Mi
Swap:            8Gi       6.9Gi       1.1Gi

Ce que cela signifie : Peu de mémoire disponible et swap lourd. Même un arrêt poli peut ramper si le processus est paginé.

Décision : Avant de redémarrer, envisagez d’alléger la pression (arrêter des charges non critiques, scaler, ajouter de la mémoire, ou réduire la charge). Redémarrer un service qui thrash la mémoire peut aggraver les choses s’il recharge des caches et déclenche plus de swap.

Task 8: Check disk I/O saturation (service “hang” can be storage latency)

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 	02/05/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.21    0.00    4.05   38.44    0.00   45.30

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         120.0   4800.0     0.0    0.0  120.22    40.0    95.0   9200.0     2.0    2.1  210.45    96.8   35.20  99.8

Ce que cela signifie : Utilisation quasi à 100% du périphérique, temps d’attente énormes, et iowait élevé. Votre « arrêt bloqué » peut être victime d’un disque saturé.

Décision : Ne redémarrez pas des services dans une file I/O en feu. Identifiez les plus gros consommateurs I/O, allégez la pression, ou basculez. Un redémarrage augmente souvent l’I/O (relecture des logs, réchauffement des caches, réindexation, etc.).

Task 9: Find which processes are hammering the disk

cr0x@server:~$ sudo iotop -oPa -n 1
Total DISK READ: 15.20 M/s | Total DISK WRITE: 42.10 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
22340 be/4 postgres   1.20 M/s   18.30 M/s  12.00 %  85.00 % postgres: checkpointer
22410 be/4 postgres   0.00 B/s   10.20 M/s   0.00 %  60.00 % postgres: wal writer
30112 be/4 root       0.00 B/s    9.80 M/s   0.00 %  55.00 % rsync -a /var/log/ /mnt/backup/

Ce que cela signifie : Des tâches en arrière‑plan (écrivains de base de données, rsync de sauvegarde) dominent l’écriture disque. Votre service bloqué peut être un dommage collatéral.

Décision : Suspendez ou limitez l’I/O non essentielle (jobs de sauvegarde, traitements batch). Si c’est la base de données qui effectue une récupération nécessaire, laissez‑la finir avant d’intervenir sur les services dépendants.

Task 10: Check the journal for stop/start hooks that are blocking

cr0x@server:~$ journalctl -u nginx.service -n 50 --no-pager
Feb 05 02:10:55 server systemd[1]: Stopping A high performance web server and a reverse proxy server...
Feb 05 02:10:55 server start-stop-daemon[18421]: stopping nginx (pid 17102)...
Feb 05 02:11:25 server start-stop-daemon[18421]: waiting for nginx to die...
Feb 05 02:11:55 server start-stop-daemon[18421]: waiting for nginx to die...
Feb 05 02:11:57 server systemd[1]: nginx.service: State 'stop-sigterm' timed out. Killing.

Ce que cela signifie : L’helper d’arrêt attend. Ce n’est pas la preuve d’un bug applicatif ; c’est la preuve que le processus ne peut pas sortir ou ne peut pas être réappliqué.

Décision : Corrélez avec l’état du processus (ps) et les attentes noyau (wchan). Si c’est en état D, réparez l’I/O sous-jacente.

Task 11: Verify DNS health (yes, DNS can hang shutdown too)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.internal

Ce que cela signifie : Vous avez systemd-resolved en mode stub. Si le résolveur est en panne ou lent, des services qui font des reverse lookups pendant l’arrêt (logs, auth, stats) peuvent se bloquer.

Décision : Si vous voyez des délais de résolution dans les logs, testez les requêtes et rétablissez la reachabilité du résolveur avant de redémarrer les services dépendants.

Task 12: See dependency failures and ordering issues

cr0x@server:~$ systemctl list-dependencies --reverse postgresql.service
postgresql.service
● ├─app-api.service
● ├─worker.service
● └─reporting.service

Ce que cela signifie : Ces services dépendent de PostgreSQL. Redémarrer PostgreSQL fera des ondulations — sauf si vous arrêtez/vidangez volontairement les dépendants d’abord.

Décision : Décidez si vous devez redémarrer la dépendance (Postgres) ou le dépendant (app-api). Souvent le symptôme bloqué vit dans le dépendant ; la cause est la dépendance. Gérez l’ordre volontairement.

Task 13: Check for a stale PID file that blocks start/stop

cr0x@server:~$ sudo cat /run/nginx.pid
99999

cr0x@server:~$ ps -p 99999 -o pid,cmd
  PID CMD

Ce que cela signifie : Le fichier PID pointe vers un processus inexistant. Certains scripts d’arrêt attendront ou échoueront ; certains scripts de démarrage refuseront de démarrer, pensant que le démon est toujours vivant.

Décision : Si vous avez confirmé qu’nginx n’est pas en cours, supprimez le fichier PID obsolète et démarrez proprement. S’il tourne mais que le PID a changé, corrigez l’unité pour éviter la fragilité liée au fichier PID (privilégiez le suivi par cgroup de systemd / Type=notify quand c’est approprié).

Task 14: Try a safe reload instead of restart (when possible)

cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

cr0x@server:~$ sudo systemctl reload nginx.service

Ce que cela signifie : Un reload conserve le processus maître et échange la configuration, évitant souvent les coupures de connexion. Ce n’est pas toujours supporté, mais quand c’est le cas, c’est le levier le plus doux.

Décision : Si le problème est lié à la configuration, préférez le reload. Si le processus est wedgé, le reload n’aidera pas ; ne faites pas semblant qu’il le fera.

Task 15: Reset systemd’s “failed” view before retrying (so you see fresh errors)

cr0x@server:~$ systemctl is-failed worker.service
failed

cr0x@server:~$ sudo systemctl reset-failed worker.service

Ce que cela signifie : Réinitialiser failed efface le verrou afin que la supervision et les humains voient la prochaine erreur proprement, pas le fantôme d’hier.

Décision : Faites cela avant votre prochaine tentative de démarrage pendant un incident, sinon vous poursuivrez des symptômes obsolètes.

Task 16: When systemd is stuck, check for pending jobs and blocked transactions

cr0x@server:~$ systemctl list-jobs
JOB  UNIT             TYPE  STATE
421  nginx.service     stop  running
422  app-api.service   stop  waiting

Ce que cela signifie : app-api attend parce que l’arrêt de nginx est toujours en cours. Les transactions systemd sérialisent certaines opérations ; une unité bloquée peut en bloquer d’autres.

Décision : Réparez/effacez l’unité bloquée ou isolez en opérant sur des unités non bloquées par cette transaction. Évitez de lancer une douzaine de nouveaux jobs dans l’engorgement.

Échelle d’escalade : du poli au ferme (sans panique)

Quand quelque chose est bloqué, les humains cherchent les gros boutons rouges. Résistez. Utilisez une échelle d’escalade, car vous voulez l’action la moins destructrice qui restaure le service tout en préservant des preuves.

Level 0: Decide if a restart is even the right tool

Redémarrer est approprié quand :

• Le processus est vivant mais dysfonctionne (deadlock, fuite mémoire, pool de threads bloqué), et vous avez de la redondance ou un plan de vidage.
• Un changement de configuration l’exige (et reload n’est pas disponible).
• Une dépendance est réparée et vous avez besoin d’un nouvel échange propre (p.ex. reconnecter à la base de données, remonter un stockage).

Redémarrer est une mauvaise idée quand :

• Le processus est en état D (attente I/O). Tuer ne fonctionnera pas ; les tentatives répétées gaspillent du temps et ajoutent de la confusion.
• L’hôte subit une pression mémoire ou I/O extrême. Le redémarrage ajoute de la charge.
• Vous pouvez basculer vers un nœud sain plus vite que « réparer » celui-ci.

Level 1: Graceful stop/start with traffic draining

Si vous êtes derrière un load balancer, drenez d’abord. Ne « redémarrez pas sur place » en espérant que les clients soient patients.

cr0x@server:~$ sudo systemctl stop app-api.service

Décision : Si l’arrêt se termine rapidement et proprement, démarrez. S’il se bloque, passez à l’inspection plutôt que de répéter la commande.

Level 2: Use reload or rotate workers if supported

Pour certains démons (nginx, haproxy, certains agents de logs), reload suffit. Pour d’autres, vous pouvez parfois « faire tourner » les workers (p.ex. envoyer un signal pour créer de nouveaux workers et retirer les anciens). Cela conserve les sockets ouverts et réduit la douleur des clients.

Level 3: Confirm what’s blocking shutdown (locks, I/O, dependencies)

C’est là que vous utilisez journalctl, lsof, ps wchan, et les outils de ressources. L’objectif : identifier si vous attendez le stockage, le réseau ou la logique applicative.

Level 4: Targeted termination of the right processes

Si le processus est dans un état interruptible et ignore simplement SIGTERM, vous pouvez escalader avec intention. Faites‑le dans le cgroup du service, pas en chassant des PIDs au hasard.

cr0x@server:~$ sudo systemctl kill -s SIGTERM nginx.service

cr0x@server:~$ sudo systemctl kill -s SIGKILL nginx.service

Ce que cela signifie : Vous demandez à systemd d’envoyer un signal à tous les processus du cgroup de l’unité. C’est plus propre que de chercher des PIDs, et cela respecte les frontières du service.

Décision : N’utilisez SIGKILL que quand vous avez décidé que la perte d’état est acceptable et que le processus n’est pas en état D. Si c’est en état D, SIGKILL n’atterrira pas.

Level 5: If systemd itself is wedged, use cgroup cleanup carefully

Parfois une unité est « partie » mais le cgroup est sale, ou un processus s’est échappé. Vous pouvez inspecter et agir, mais gardez les mains stables.

cr0x@server:~$ systemctl show nginx.service -p ControlGroup
ControlGroup=/system.slice/nginx.service

cr0x@server:~$ cat /sys/fs/cgroup/system.slice/nginx.service/cgroup.procs
17102
17105
17106

Décision : Si ces PIDs appartiennent réellement au service, vous pouvez arrêter l’unité et tuer via systemd. Si les PIDs sont en état D, arrêtez‑vous ici et réparez l’I/O ; la suppression via cgroup ne servira pas.

Level 6: Last resort—reboot with intent, not frustration

Si le noyau est wedgé sur le stockage (périphérique bloqué, NFS mort, chemin multipath cassé) et que vous ne pouvez pas récupérer depuis l’espace utilisateur, reboot peut être le bon choix opérationnel. Mais faites‑le comme un ingénieur :

• Basculez le trafic d’abord.
• Capturez des preuves : dmesg, journal, échantillons iostat, état des montages.
• Communiquez l’impact attendu et les étapes de récupération.

Petite blague n°2 : Un reboot, c’est comme l’éteindre et le rallumer — sauf que le « rallumer » inclut l’explication au comité de changements.

Trois micro-récits d’entreprise depuis le terrain

Incident causé par une fausse hypothèse : « Redémarrer le service n’affectera pas les données »

Une entreprise de taille moyenne exécutait une API de paiements appuyée par une file et une base relationnelle. Les nœuds API étaient « sans état », ou du moins c’est ce que tout le monde disait. Un déploiement a introduit un bug subtil : des threads travailleurs s’empilaient en attente d’une connexion BD qui ne revenait jamais. La latence a grimpé ; le taux d’erreurs aussi.

L’astreignant a vu des threads bloqués et a fait le geste standard : redémarrer le service API sur un nœud. Il est revenu. Pendant environ trois minutes. Puis il s’est à nouveau bloqué. Ils ont redémarré d’autres nœuds. Vite. Le load balancer a réparti le trafic sur les nœuds restants, qui se sont rapidement saturés.

L’hypothèse qui les a piégés : « l’API est sans état ». En réalité, chaque nœud exécutait aussi un agent local qui mettait en spool les requêtes en vol sur disque pour réessai lors de pannes transitoires. Pendant la tempête de redémarrages, le spool de réessai de l’agent a ressoumis d’anciennes requêtes, et les clés d’idempotence de la BD n’étaient pas appliquées uniformément entre les chemins de code.

Ils n’ont pas perdu d’argent — presque. Ils ont perdu un week‑end en réconciliations et revues d’incident. La solution n’était pas « ne pas redémarrer ». La solution a été de modéliser honnêtement l’état du système : où il vit, comment il est réessayé, et quels composants doivent être vidés avant redémarrage. Le runbook inclut désormais « désactiver l’agent de réessai local » et « vérifier l’application d’idempotence » avant tout redémarrage massif.

La leçon pratique : vous ne pouvez pas redémarrer en toute sécurité ce que vous n’avez pas inventorié. « Sans état » n’est pas un ressenti ; c’est une décision d’architecture que l’on peut prouver.

Optimisation qui s’est retournée contre eux : « Des timeouts plus courts rendront les redémarrages plus rapides »

Une autre organisation avait une flotte d’hôtes Linux exécutant un forwarder de logs et un agent de métriques. L’équipe a réglé les unités systemd pour réduire le temps d’arrêt pendant les maintenances roulantes : TimeoutStopSec=10 partout. Ça semblait vif. Ça paraissait efficace. C’était aussi faux.

Un jour, un hic sur le stockage distant a causé des délais intermittents d’écriture des tampons de logs. Le forwarder avait besoin d’environ 20–30 secondes pour vider en toute sécurité. Mais avec un timeout d’arrêt de 10 secondes, systemd a escaladé régulièrement vers SIGKILL. Le résultat n’a pas été une indisponibilité immédiate ; c’était pire : des logs d’audit silencieusement perdus et des lots à moitié livrés qui ont cassé le parsing en aval.

L’incident fut difficile à repérer car le « redémarrage a réussi ». Tableaux verts. Statut d’unité heureux. Pendant ce temps les équipes compliance ont remarqué des trous, et l’équipe en aval a vu des patterns d’événements « un peu dupliqués ».

Le rollback a été de restaurer des timeouts sensés et d’ajouter des métriques explicites de flush. Ils ont aussi appris à différencier les services : un proxy web peut être tué plus rapidement qu’un pipeline de données avec tampon. L’optimisation uniforme est la façon de propager des erreurs uniformes à l’échelle.

La leçon pratique : les timeouts font partie de votre histoire d’intégrité des données. Adaptez‑les par service, prouvés par des tests de panne, pas par esthétique.

Pratique ennuyeuse mais correcte qui a sauvé la journée : « Vider, vérifier, puis redémarrer un nœud »

Une société SaaS avait un cluster de nœuds applicatifs derrière un load balancer, plus une couche de stockage séparée. Un nœud a commencé à échouer les checks de santé de façon intermittente. Le processus applicatif n’était pas mort ; il était « vivant mais bloqué », répondant lentement et manquant les deadlines du watchdog.

L’astreignant a suivi le runbook ennuyeux. D’abord, ils ont drainé le nœud du balancer et confirmé que le trafic était proche de zéro. Puis ils ont capturé des preuves locales : cinq minutes d’iostat, le systemctl status courant, et les 200 dernières lignes du journal pour l’unité.

Ils ont ensuite redémarré le service sur ce seul nœud. Il a quand même bugué à l’arrêt. Au lieu d’escalader aveuglément, ils ont vérifié les états des processus et trouvé des attentes en état D liées à un chemin iSCSI obsolète. Ils ont détaché le nœud de la session de stockage (planifié), l’ont marqué hors rotation, et laissé le cluster continuer.

Plus tard, en journée, ils ont corrigé les paramètres multipath et ajouté des alertes pour les fluctuations de chemin. Pas de reboot héroïque. Pas de redémarrages en masse. L’impact client fut minimal parce qu’ils ont traité « un nœud défaillant » comme un problème d’isolation, pas un drame pour toute la flotte.

La leçon pratique : drainer et faire des canaris sur un seul nœud semble lent, mais empêche l’expérience classique « j’ai transformé un problème en douze ».

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: systemctl stop hangs forever (or until timeout)

Cause racine : Le processus est en état D en attente d’un I/O stockage/réseau (NFS, iSCSI, disque mort), ou un script ExecStop est bloqué sur DNS/montage.

Correctif : Confirmez avec ps ... wchan et findmnt. Restaurez la dépendance (stockage/réseau/DNS) ou basculez ; ne spammez pas les signaux.

2) Symptom: restart “works” but service becomes slow immediately

Cause racine : Pression de ressources sous-jacente (saturation I/O, swap mémoire) plus caches froids après le redémarrage.

Correctif : Vérifiez iostat, free, et les plus gros consommateurs I/O. Réduisez la charge ou corrigez le goulot d’étranglement d’abord ; redémarrez en dernier.

3) Symptom: systemd says “active (running)” but the service is dead/unresponsive

Cause racine : Type d’unité incorrect ou signalement de readiness défaillant (p.ex. Type=forking avec un fichier PID obsolète), ou absence de gating par health check.

Correctif : Validez le suivi du PID ; privilégiez Type=notify quand possible. Ajoutez watchdogs/checks de santé ou un contrôle socket et alertez dessus.

4) Symptom: systemctl start fails with “Address already in use”

Cause racine : Ancien processus toujours en écoute (cgroup échappé, orphelin), ou confusion avec unité socket-activée.

Correctif : Trouvez les listeners avec ss -ltnp, confirmez l’appartenance au cgroup, tuez le bon processus via systemd ou arrêtez l’unité socket si applicable.

5) Symptom: service keeps restarting in a loop

Cause racine : Restart=always plus une défaillance persistante (mauvaise config, dépendance manquante, permissions). La boucle peut créer charge et tempêtes de logs.

Correctif : Arrêtez l’unité, inspectez les logs, corrigez l’erreur réelle, puis démarrez. Envisagez un backoff ou StartLimitIntervalSec / StartLimitBurst.

6) Symptom: stop succeeds but start blocks at “activating”

Cause racine : Le check de readiness ne se termine jamais (attente d’un notify), ou il attend une dépendance qui est « up » mais inutilisable (DNS répond mais lent ; montage présent mais obsolète).

Correctif : Vérifiez systemctl status + propriétés de l’unité (Type=, notify), validez la santé des dépendances avec des commandes directes (lookup DNS, test lecture/écriture sur montage).

7) Symptom: killing the PID does nothing

Cause racine : Le PID est faux (fichier PID obsolète), ou le processus est bloqué en sommeil non interruptible.

Correctif : Vérifiez le PID avec systemctl status et systemd-cgls. Si c’est en état D, traitez‑le comme une défaillance I/O sous-jacente.

8) Symptom: “Unit is masked” or “Refusing to operate on alias name” during incident

Cause racine : Quelqu’un a masqué un service pour l’empêcher de démarrer, ou vous ciblez un alias/symlink plutôt que l’unité réelle.

Correctif : Confirmez avec systemctl status et systemctl cat. Démasquez intentionnellement, documentez pourquoi il était masqué, et démarrez l’unité canonique.

Checklists / plan étape par étape

Checklist A: Safe restart of a typical stateless service (web/API)

1. Confirmer l’étendue de l’impact : Ce nœud est‑il redondant ? Sinon, marquez une fenêtre de maintenance ou planifiez un basculement.
2. Drainer le trafic : retirez le nœud du load balancer ; confirmez la chute des connexions actives.
3. Capturer des preuves : systemctl status, les 100 dernières lignes de journalctl -u, et un snapshot ps des PIDs du service.
4. Essayer l’action douce : reload si possible ; sinon stop via systemd.
5. Si l’arrêt se bloque : vérifiez état D, montages, pression I/O. Réparez la cause avant de forcer.
6. Démarrer et vérifier : unité active, port à l’écoute, endpoint de santé OK, taux d’erreur stable.
7. Retourner le trafic progressivement : réintégrez le nœud ; surveillez latence et saturation.

Checklist B: Safe restart of a stateful service (database/queue)

1. Confirmer l’état de réplication / HA : connaître primaire vs réplique, quorum et règles de basculement.
2. Quiescer les écritures si nécessaire : pausez les consommateurs, arrêtez les jobs batch, ou activez le mode maintenance.
3. Vérifier l’espace disque et la santé I/O d’abord : faible espace ou latence élevée transforme le « redémarrage » en « marathon de récupération ».
4. Utiliser les commandes d’administration natives : p.ex. arrêt rapide de base de données vs kill brutal, pour éviter une reprise longue après crash.
5. Arrêter via systemd et surveiller : regardez les logs pour les messages de checkpoint/flush.
6. Si ça se bloque : ne SIGKILL pas par réflexe. Identifiez si c’est un checkpoint, un fsync en cours, ou un blocage sur le stockage sous-jacent.
7. Après le démarrage : vérifiez les signaux de cohérence (replication catch-up, WAL replay complet), puis réactivez les écrivains/consommateurs.

Checklist C: When you suspect storage/network is the real culprit

1. Vérifier les processus en état D : si oui, vous êtes probablement sous l’espace noyau.
2. Vérifier montages et systèmes distants : NFS, iSCSI, SMB — confirmez santé, latence et logs d’erreur.
3. Vérifier les messages du noyau : timeouts, flaps de lien, resets SCSI, erreurs NVMe.
4. Isoler l’hôte : drainer le trafic et arrêter d’aggraver la situation.
5. Récupérer la dépendance ou basculer : restaurer les chemins, redémarrer les services de montage, ou déplacer la charge.
6. Rebooter seulement avec un plan : après capture de preuves et avec basculement confirmé.

FAQ

1) Pourquoi ne pas simplement rebooter ? C’est plus rapide.

Parfois c’est plus rapide pour vous, pas pour le système. Rebooter réinitialise tout, peut déclencher de longues récupérations (fsck, resync RAID, rejouage BD), et détruit des preuves. Redémarrez quand vous avez identifié un wedge côté noyau ou que vous avez déjà basculé et que vous voulez une ardoise propre.

2) Que signifie « état D », et pourquoi est‑ce important ?

L’état D est le sommeil non interruptible : le processus attend dans le noyau, typiquement un I/O. Les signaux ne seront pas traités tant que l’appel noyau ne s’achève pas. Si un processus est bloqué en état D, le tuer ne fonctionnera pas ; il faut réparer le chemin I/O sous‑jacent ou rebooter l’hôte.

3) Dois‑je utiliser killall ou pkill lors d’un incident ?

Généralement non. Ce sont des instruments grossiers qui aiment les dommages collatéraux. Préférez systemctl kill pour une unité spécifique afin de toucher le bon cgroup. Si vous devez utiliser pkill, restreignez‑le fortement et vérifiez avec ps et systemd-cgls.

4) Pourquoi systemd dit qu’il a tué le processus, mais il est toujours là ?

Si le processus est en état D, il peut rester présent parce qu’il ne peut pas terminer l’opération noyau et sortir. Autre possibilité : vous regardez un PID différent (fichier PID obsolète) ou un processus enfant en dehors du cgroup de l’unité.

5) Est‑il bon d’abaisser TimeoutStopSec pour éviter les blocages ?

Pas comme politique générale. Pour les pipelines à tampon et services étatful, des timeouts courts transforment un arrêt gracieux en perte de données. Définissez des timeouts par service, basés sur des mesures d’arrêt sous charge et en dégradation.

6) Quand SIGKILL est‑il acceptable ?

Quand vous avez décidé que préserver l’état est moins important que restaurer la disponibilité, et que vous comprenez le coût de récupération. C’est aussi acceptable pour des services vraiment sans état où le processus est simplement impoli. Ce n’est pas une solution pour les blocages en état D.

7) Quelle est la différence entre restart et try-restart ?

restart démarre le service même s’il n’est pas en cours. try-restart ne redémarre que s’il était déjà en cours. En production, try-restart est plus sûr quand vous ne voulez pas lancer accidentellement quelque chose qui était intentionnellement arrêté.

8) Comment éviter les défaillances en cascade lors du redémarrage de dépendances ?

Connaissez le graphe de dépendances. Videz ou arrêtez les dépendants avant de redémarrer une dépendance centrale (base de données, file, DNS, stockage). Remettez les dépendances en premier, puis les dépendants par petits lots en surveillant taux d’erreur et saturation.

9) systemd affiche « activating » indéfiniment. Quel est le coupable habituel ?

Le signalement de readiness. Le service peut attendre un événement notify, un fichier PID, ou un hook post-start qui appelle le réseau. Inspectez le type d’unité et ExecStartPost ; vérifiez les logs et les timeouts.

10) Comment conserver des preuves si je dois intervenir rapidement ?

Prenez le minimum de preuves viables avant d’appliquer la force : statut de l’unité, ~200 dernières lignes du journal, snapshot d’état des processus, et un échantillon I/O rapide. C’est suffisant pour diagnostiquer la plupart des causes de « stop bloqué » plus tard.

Prochaines étapes que vous pouvez réellement faire demain

Les redémarrages sûrs ne sont pas une question de prudence ; c’est une question de précision. Quand un service est bloqué, votre premier travail est la classification : est‑ce un blocage applicatif, un blocage de dépendance, ou un blocage noyau/stockage ? Seul l’un de ces cas se résout en « redémarrer plus fort ».

Faites ceci ensuite :

1. Rédigez une échelle d’escalade pour vos 5 services principaux : reload vs restart, étapes de vidage, et quand SIGKILL est autorisé.
2. Mesurez le temps d’arrêt de base en conditions normales et en légère dégradation, puis réglez TimeoutStopSec en conséquence.
3. Ajoutez une alerte état D : comptez les processus en état D et déclenchez une page quand ça grimpe. C’est un signal précoce que votre stockage/réseau vous ment.
4. Inventoriez l’état : identifiez quels services « sans état » persistent, tamponnent ou réessayent localement.
5. Entraînez‑vous sur un nœud dans un environnement de type staging : forcez un montage bloqué, observez le comportement d’arrêt, et mettez à jour le runbook avec ce que vous apprenez.

Le but n’est pas de ne jamais redémarrer. Le but est de redémarrer uniquement quand vous le décidez — et de savoir exactement ce que vous achetez avec ce rayon de dégâts.