Utiliser nohup pour maintenir un processus actif

nohup commande &, c'est tout ce qu'il faut taper pour qu'une commande survive à votre déconnexion SSH. Sans nohup, Linux envoie SIGHUP à tous les processus de la session quand le terminal se ferme, et ils se terminent. nohup bloque ce signal.

Ce que vous allez apprendre

• Comprendre pourquoi un processus meurt à la déconnexion (SIGHUP)
• Lancer une commande avec nohup et &
• Rediriger stdout et stderr vers un fichier de log dédié
• Combiner nohup avec disown pour une protection maximale
• Retrouver le processus après reconnexion avec pgrep ou ps

Dans quel contexte ?

• Vous lancez une sauvegarde, une compilation, un transfert de données via SSH.
• Vous ne pouvez pas ou ne voulez pas laisser le terminal ouvert.
• Vous n'avez pas tmux disponible sur la machine distante.

Pourquoi les processus meurent à la déconnexion

Quand vous vous déconnectez d'une session SSH, le shell reçoit le signal SIGHUP (signal 1, hang up). Il le propage à l'ensemble des processus de la session. Par défaut, la plupart des commandes réagissent à SIGHUP en se terminant.

# Simuler ce qui se passe : envoyer SIGHUP manuellement
kill -HUP $PID

nohup contourne ce mécanisme en configurant l'ignorance de SIGHUP avant d'exécuter la commande.

Syntaxe de base

nohup commande arguments &

• nohup : configure l'ignorance de SIGHUP puis exécute la commande
• & : place le processus en arrière-plan (indispensable, sans &, nohup bloque le terminal)

# Exemple concret
nohup rsync -avz /data/ user@serveur:/backup/ &
echo "Sauvegarde lancée, PID=$!"

Le fichier nohup.out

Si vous ne redirigez pas la sortie, nohup crée automatiquement un fichier nohup.out dans le répertoire courant pour capturer stdout :

cd /home/bob
nohup mon-script.sh &
# --> nohup : l'entrée standard est ignorée, la sortie est ajoutée à 'nohup.out'
ls -la nohup.out
tail -f nohup.out   # surveiller la progression

nohup.out peut grossir

Sur un script verbeux tournant des heures, nohup.out peut atteindre plusieurs gigaoctets. Redirigez toujours explicitement vers un fichier de log avec rotation prévue.

Redirection explicite (recommandé)

La bonne pratique est de spécifier vous-même le fichier de log :

nohup mon-script.sh > /var/log/mon-script.log 2>&1 &
PID=$!
echo "PID=$PID, logs dans /var/log/mon-script.log"

• > fichier.log : redirige stdout
• 2>&1 : redirige stderr vers le même fichier
• Quand vous redirigez explicitement, nohup.out n'est pas créé

Pour suivre l'avancement en temps réel depuis une autre connexion :

tail -f /var/log/mon-script.log

Combiner nohup et disown

nohup protège contre SIGHUP. disown retire la tâche de la table de jobs du shell. Combinés, ils offrent la protection maximale :

nohup ma-commande > sortie.log 2>&1 &
PID=$!
disown $PID
echo "Tâche $PID lancée, protégée contre HUP et détachée du shell"

Quand utiliser la combinaison ?

• Quand vous travaillez dans un shell interactif et que vous ne voulez aucun risque de fin prématurée.
• Quand des scripts côté serveur redémarrent les sessions automatiquement.

disown -h vs disown

disown -h $PID immunise contre SIGHUP sans retirer la tâche de jobs. Vous pouvez encore utiliser fg dessus. disown $PID la retire complètement de jobs.

Retrouver un processus nohup après reconnexion

Après déconnexion et reconnexion, votre nouveau shell n'a aucune mémoire des tâches précédentes. Retrouvez le processus avec :

# Par nom de commande
pgrep -a mon-script
pgrep -u bob rsync

# Par PID (si vous l'avez noté)
ps -p 1234 -o pid,stat,comm,etime

# Lire les logs
tail -f /var/log/mon-script.log

Récapitulatif : nohup vs disown vs tmux

Outil	Quand l'utiliser	Avantage	Limite
nohup commande &	Tâche simple, connexion unique	Une commande suffit	Pas d'interactivité possible après
disown -h $PID	Commande déjà lancée sans nohup	Rattrapage après le fait	Moins robuste que nohup
nohup ... & disown	Protection maximale	Immunisé SIGHUP et détaché	Pas de reprise interactive
tmux	Session interactive, suivi en direct	Reconnexion complète possible	Nécessite tmux installé

Glissez pour voir

Pour les tâches critiques

Pour une tâche vraiment critique (migration de base de données, conversion vidéo longue), préférez tmux. Il vous permet de vous reconnecter et de voir la sortie en direct, sans perdre l'interactivité.

Dépannage

Symptôme	Cause probable	Solution
nohup.out absent alors que la tâche tourne	Sortie redirigée explicitement	Normal, cherchez votre fichier de log
nohup.out dans le mauvais dossier	nohup crée le fichier dans $PWD au moment du lancement	Toujours spécifier un chemin absolu en redirection
La commande se termine quand même à la déconnexion	Vous avez oublié &, nohup a bloqué le terminal	Relancer avec nohup commande &
Impossible de retrouver le processus après reconnexion	PID non noté, commande trop générique	Toujours noter le PID ou utiliser une commande avec un nom unique
Deux nohup.out qui se mélangent	Deux tâches nohup dans le même répertoire sans redirection	Utiliser des fichiers de log distincts pour chaque tâche

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• nohup intercepte SIGHUP : la commande ne se termine plus à la déconnexion SSH.
• Ajoutez toujours &, sans lui, nohup bloque votre terminal.
• Redirigez explicitement vers un fichier de log : nohup commande > mon.log 2>&1 &
• Combinez avec disown $! pour une protection complète.
• Notez le PID ou utilisez un nom de log explicite pour retrouver la tâche après reconnexion.

Pour aller plus loin

• Travailler avec tmux : La solution complète : sessions persistantes avec reconnexion et interactivité.

×

📖 Voir la documentation →