Dans quels cas SIGHUP n'est-il pas envoyé à un travail lorsque vous vous déconnectez?

J'ai lu une réponse d'un utilisateur qui prétendait que courir

foo 2>&1 >& output.log &

entraînerait la foopoursuite de l'exécution même lorsqu'ils se déconnectent. Selon cet utilisateur, cela a même fonctionné sur des connexions SSH.

Je ne croyais pas vraiment que, car j'avais l'impression qu'en cas de déconnexion de SSH ou de résiliation du TTY, le shell et donc ses processus recevraient un SIGHUP, ce qui les obligerait à se terminer. À mon avis, c'était la seule raison d'utiliser nohupdans de tels cas, ou tmux, screenet al.

J'ai ensuite regardé dans le manuel de glibc :

Ce signal est également utilisé pour signaler la fin du processus de contrôle sur un terminal aux travaux associés à cette session; cette terminaison déconnecte efficacement tous les processus de la session du terminal de contrôle.

Cela semble confirmer mes pensées. Mais en regardant plus loin, il dit :

Si le processus est un leader de session qui a un terminal de contrôle, un signal SIGHUP est envoyé à chaque processus dans la tâche de premier plan, et le terminal de contrôle est dissocié de cette session.

Cela signifie-t-il donc que les emplois mis en arrière-plan ne recevront pas SIGHUP?

_{À ma plus grande confusion, j'ai exécuté une session Zsh interactive, exécuté yes >& /dev/null &et tapé exit, lorsque Zsh m'a averti que j'avais des travaux en cours et, après avoir tapé exitune deuxième fois, m'a dit qu'il avait SIGHUPed un travail. Faire exactement la même chose dans Bash laisse le travail en cours…}

Bash semble envoyer le SIGHUPseul s'il a reçu lui-même un SIGHUP, ce qui se produit par exemple lorsqu'un terminal virtuel est fermé ou lorsque la connexion SSH est interrompue. De la documentation :

Le shell se ferme par défaut à réception d'un SIGHUP. Avant de quitter, un shell interactif renvoie le SIGHUP à toutes les tâches, en cours d'exécution ou arrêtées. Les travaux arrêtés sont envoyés SIGCONT pour s'assurer qu'ils reçoivent le SIGHUP. Pour empêcher le shell d'envoyer le signal SIGHUP à un travail particulier, il doit être supprimé de la table des travaux avec le programme intégré désavoué (voir les commandes de contrôle des travaux) ou marqué pour ne pas recevoir SIGHUP en utilisant disown -h.

Donc, si vous tapez exitou appuyez sur Ctrl+, Dtout le processus d'arrière-plan restera, car cela n'envoie pas de signal de raccrochage au Bash.

Vous pouvez forcer Bash à vous avertir du fait qu'il existe toujours des processus en arrière-plan avec

shopt -s checkjobs

Il existe une option pour envoyer la SIGHUPsortie à la sortie si vous êtes dans un shell interactif ( voir ici ). Mais cela ne fonctionne pas sur ma machine avec Bash 4.2.25. Peut-être que cela fonctionne pour vous

shopt -s huponexit