Nohup

Lorsqu'un utilisateur se déconnecte, le daemon qui détecte cette déconnexion (telnetd, sshd, ...) envoie le signal SIGHUP (signal 1) aux processus enfants, ce qui provoque par défaut la fin du processus. nohup ignore le signal SIGHUP (d'où son nom) puis exécute le programme indiqué en ligne de commande, de sorte que celui-ci sera immunisé contre le signal SIGHUP.

Toutefois, le processus lancé est libre de définir lui-même l'action qu'il désire associer au traitement du signal SIGHUP. En effet, cette immunité est héritée du processus initial nohup vers ses fils (via fork/exec (en)). Si un programme tiers, pour des raisons de design ou de spécification du programme, choisit de ne pas ignorer ce signal, voire de placer son propre gestionnaire à cette fin, alors ce programme tiers ne sera pas protégé contre les fermetures de terminaux, ou en général contre la réception du signal SIGHUP.

Enfin, l'utilisation de nohup oublie souvent des aspects liés aux descripteurs. En effet, la commande nohup s'occupe de rediriger les sortie et erreur standards, mais par contre elle ne fait rien à propos de l'entrée standard. Dans la majorité des premiers usages, lors de la déconnexion du terminal, l'on reçoit un message comme « There are running jobs. », lequel est provoqué par le fait que le processus tiers est toujours lié au terminal par son entrée standard. Cet inconvénient peut être levé en redirigeant explicitement l'entrée standard du processus tiers.

La première ligne de commande ci-dessous démarre le programme mon_programme en tâche de fond de telle façon qu'une déconnexion ne l'arrêtera pas.

$ nohup mon_programme &
$ exit

Cet autre exemple montre comment rediriger la sortie vers un fichier texte autre que nohup.out (défaut).

$ nohup mon_programme > out.file &

Voici un exemple avec redirection de l'input standard pour éviter qu'il ne se bloque à la fermeture du terminal.

$ nohup mon_programme 0</dev/null &

• GNU Screen
• disown

• Portail de l’informatique