Sauver un processus lancé au premier plan avant une coupure

Vous avez lancé une compilation, un import ou une installation qui va durer deux heures. Vous l’avez lancée au premier plan, sans y penser. Et vous réalisez que si votre connexion tombe — ou simplement si vous fermez le terminal — tout s’arrête en plein milieu.

La bonne nouvelle, c’est que la situation se rattrape sans interrompre le traitement. Trois touches et deux commandes suffisent. Encore faut-il savoir dans quelle fenêtre les taper, et comment vérifier ensuite que le sauvetage a réussi.

Pourquoi la déconnexion tue le processus

Quand la connexion SSH se rompt, le démon sshd ferme le pseudo-terminal associé — pts/2, par exemple. Le shell rattaché à ce terminal reçoit alors le signal SIGHUP, abréviation de hang up, hérité de l’époque où l’on raccrochait un modem.

Ce shell ne meurt pas seul : il propage le signal à tous ses jobs. Toute l’arborescence descend avec lui, y compris le processus qui compilait depuis une heure et demie.

C’est pour cela qu’un traitement long ne doit jamais rester attaché à une session interactive. Et c’est aussi pour cela que la parade consiste à couper ce lien de parenté, sans toucher au processus lui-même.

Savoir si un processus est au premier plan

C’est le point que la plupart des documentations passent sous silence, et c’est pourtant le seul diagnostic fiable. Il tient dans un caractère.

ps -fu monuser

Regardez la colonne STAT. Un processus du groupe de premier plan porte un + à la fin de son état :

STAT	Signification
S+	en attente, au premier plan — vulnérable au SIGHUP
S	en attente, en arrière-plan — détaché du terminal
R+	en cours d’exécution, au premier plan
R	en cours d’exécution, en arrière-plan
T	arrêté — suspendu, ne progresse plus
D	en attente d’entrée-sortie, non interruptible

Le + est donc votre voyant d’alerte. Tant qu’il est là, la déconnexion emporte le processus ; une fois disparu, le traitement survit.

L’arborescence rend la lecture plus simple encore :

ps -fu monuser --forest

Vous voyez alors la chaîne complète — le shell, le script qu’il a lancé, les sous-shells, et le binaire qui travaille réellement. Si le shell parent porte le +, tous ses descendants aussi.

Le sauvetage en trois gestes

Une contrainte d’abord : il faut agir dans la fenêtre où tourne le job. Depuis un autre terminal, vous ne pouvez pas intervenir sur les jobs d’un shell qui n’est pas le vôtre — la table des jobs appartient à chaque shell.

Si vous avez ouvert une seconde session pour surveiller, revenez dans la première.

Ctrl+Z        # suspend le job sans le tuer
bg            # le relance immédiatement en arrière-plan
disown        # le retire de la table des jobs du shell
jobs          # ne doit plus rien afficher

Ctrl+Z envoie un SIGTSTP : le processus est mis en pause, pas interrompu. Son état passe à T.

bg envoie un SIGCONT et le reprend, cette fois en arrière-plan. La pause n’aura duré que le temps de taper la commande.

disown est l’étape décisive : elle retire le job de la table du shell. Celui-ci ne lui enverra donc plus de SIGHUP à sa mort.

Enchaînez les trois sans traîner, pour que la suspension reste de l’ordre de quelques secondes. Sur une compilation, cette pause est sans conséquence : rien n’est perdu, le travail reprend exactement là où il s’était arrêté.

Vérifier que le sauvetage a fonctionné

Deux contrôles, et ils ne disent pas la même chose.

ps -fu monuser --forest | grep -E "mon_script|mon_binaire"

Le + doit avoir disparu des processus du job. Vous verrez S là où il y avait S+. En revanche, le shell de la fenêtre, lui, reste en S+ : c’est normal, c’est lui qui est désormais au premier plan.

Aucun processus ne doit être en état T. Un T résiduel signifie que le bg n’a pas pris, et que le traitement est suspendu — il ne progresse plus, ce qui est pire que le problème initial.

Le second contrôle est le seul qui prouve vraiment quelque chose : regardez le journal applicatif.

tail -5 /chemin/vers/le/journal.log
sleep 60
tail -5 /chemin/vers/le/journal.log

Si le compteur a avancé entre les deux, le traitement tourne. C’est la seule certitude ; l’état dans ps ne dit pas qu’il progresse, seulement qu’il n’est pas bloqué.

Après reconnexion, les processus seront toujours là, mais leur parent sera devenu le PID 1 — le shell d’origine ayant disparu. La colonne TTY affichera souvent encore l’ancien terminal, ou un point d’interrogation. Les deux sont normaux.

Deux limites que disown ne lève pas

disown protège du SIGHUP. Il ne détache pas le processus du terminal, et cela a deux conséquences.

Les écritures vers le terminal échouent. Une fois la fenêtre fermée, tout ce que le processus écrit directement sur sa sortie standard ou d’erreur produit une erreur d’entrée-sortie. En pratique, ce n’est pas gênant : un tee continue d’écrire dans ses fichiers, et les journaux restent complets. Le risque n’existe que pour un script qui testerait le code retour d’un affichage — cas rare, mais il existe.

Toute saisie interactive bloque le traitement. Si le script demande une confirmation ou un mot de passe en cours de route, il tentera de lire le terminal depuis l’arrière-plan et recevra un SIGTTIN. Il passera alors en état T, et attendra indéfiniment.

ps -o pid,stat,cmd -p 12345

C’est le contrôle à faire si le journal cesse d’avancer. Avant de détacher un traitement, demandez-vous donc s’il peut réclamer quoi que ce soit à mi-parcours.

Les autres sessions de la fenêtre

Un détail qu’on oublie : le SIGHUP frappe toutes les sessions ouvertes, pas seulement celle qui vous inquiète.

Une session sqlplus, psql ou mysql restée ouverte dans un autre onglet sera tuée elle aussi. Si une transaction y est en cours, elle sera annulée — ou pire, laissera des verrous le temps que le serveur détecte la rupture.

Avant de vous déconnecter, validez ou quittez proprement ce qui traîne.

Bien lancer, la prochaine fois

Le sauvetage est une rustine. Trois méthodes évitent d’en arriver là, par ordre croissant de confort.

nohup et l’esperluette — le minimum vital :

nohup ./traitement-long.sh > /chemin/sortie.log 2>&1 &

Le processus ignore le SIGHUP et toutes ses sorties partent dans un fichier. Notez la redirection des deux flux : sans 2>&1, les erreurs se perdraient.

setsid va plus loin en créant une nouvelle session, détachée du terminal dès le départ :

setsid ./traitement-long.sh > /chemin/sortie.log 2>&1 < /dev/null &

La redirection de l’entrée depuis /dev/null évite le blocage en cas de lecture inattendue.

tmux ou screen — la bonne méthode pour tout traitement long administré à distance :

tmux new -s installation
# lancez votre traitement normalement
# Ctrl+B puis D pour vous détacher
tmux attach -t installation   # pour revenir, depuis n'importe où

La différence est de nature : avec nohup, vous perdez la main sur le processus et ne pouvez plus que lire ses journaux. Avec tmux, vous retrouvez la session exactement telle que vous l’avez laissée, affichage compris, et vous pouvez interagir de nouveau.

Sur une opération de plusieurs heures menée depuis un poste distant, c’est la différence entre une coupure sans conséquence et une matinée perdue.

Et si le processus est déjà orphelin ?

Dernier cas : la connexion est tombée avant que vous n’ayez pu faire quoi que ce soit, mais le processus a survécu — parce qu’il avait été lancé avec nohup, ou parce que le shell n’a pas propagé le signal.

Vous ne pouvez plus l’attacher à votre nouvelle session avec les outils standards. L’utilitaire reptyr, s’il est installé, sait le faire :

reptyr 12345

Il est rarement présent sur un serveur de production, et son usage suppose des droits suffisants. Sans lui, il ne reste qu’à suivre les journaux — ce qui suffit dans la plupart des cas.

En résumé

• la déconnexion envoie un SIGHUP au shell, qui le propage à toute son arborescence ;
• le + dans la colonne STAT signale un processus au premier plan, donc vulnérable ;
• le sauvetage tient en trois gestes : Ctrl+Z, bg, disown ;
• il doit se faire depuis la fenêtre où tourne le job, la table des jobs étant propre à chaque shell ;
• la suspension de Ctrl+Z est sans danger : le travail reprend là où il s’était arrêté ;
• vérifiez que le + a disparu, qu’aucun processus n’est en T, et surtout que le journal avance ;
• disown ne protège pas d’une saisie interactive en cours de route, qui bloquerait le traitement ;
• pensez aux autres sessions de la fenêtre : une transaction ouverte sera annulée ;
• la prochaine fois : nohup au minimum, tmux de préférence.

Un réflexe à prendre avant toute opération longue : se demander, dix secondes avant de valider, ce qui se passera si la connexion tombe. La réponse décide du mode de lancement, et elle coûte bien moins cher que le sauvetage.