Quelle est la différence entre une bague et une esperluette ?

Question

Les deux sites nohup myprocess.out & o myprocess.out & pour que monprocessus.out s'exécute en arrière-plan. Après avoir fermé le terminal, le processus est toujours en cours d'exécution. Quelle est la différence entre les deux ?

Answer 1

La commande nohup est un utilitaire de masquage de signal et capte le signal de raccrochage. Alors que l'esperluette ne capte pas les signaux de raccrochage. L'interpréteur de commandes terminera la sous-commande avec le signal de raccrochage lorsqu'il exécutera une commande en utilisant & et en quittant l'interpréteur de commandes. Ceci peut être évité en utilisant nohup, car il capte le signal. La commande nohup accepte le signal de suspension qui peut être envoyé à un processus par le noyau et le bloque. La commande nohup est utile lorsqu'un utilisateur souhaite lancer une application en cours d'exécution ou fermer la fenêtre dans laquelle le processus a été lancé. L'une ou l'autre de ces actions incite normalement le noyau à raccrocher l'application, mais un wrapper nohup permettra au processus de continuer. L'utilisation de l'esperluette exécutera la commande dans un processus enfant et cet enfant de la session bash actuelle. Lorsque vous quittez la session, tous les processus enfants de ce processus seront tués. L'esperluette est liée au contrôle des tâches pour le shell actif. Ceci est utile pour exécuter un processus dans une session en arrière-plan.

Answer 2

Il existe de nombreux cas où de petites différences entre les environnements peuvent vous mordre. C'est un cas que j'ai rencontré récemment. Quelle est la différence entre ces deux commandes ?

1 ~ $ nohup myprocess.out &
2 ~ $ myprocess.out &

La réponse est la même que d'habitude : cela dépend.

nohup capte le signal de raccrochage alors que l'esperluette ne le fait pas.

Quel est le signal de raccrochage ?

SIGHUP - raccrochage détecté sur le terminal de contrôle ou mort du processus de contrôle (valeur : 1).

Normalement, lorsqu'on exécute une commande à l'aide de & et qu'on quitte l'interpréteur de commandes par la suite, l'interpréteur de commandes met fin à la sous-commande avec le signal d'interruption (comme kill -SIGHUP $PID). Ceci peut être évité en utilisant nohup, car il attrape le signal et l'ignore de sorte qu'il n'atteigne jamais l'application réelle.

Bien, mais comme dans ce cas, il y a toujours des "mais". Il n'y a pas de différence entre ces méthodes de lancement lorsque le shell est configuré de manière à ne pas envoyer de SIGHUP du tout.

Si vous utilisez bash, vous pouvez utiliser la commande spécifiée ci-dessous pour savoir si votre shell envoie SIGHUP à ses processus enfants ou non :

~ $ shopt | grep hupon

Et de plus - il y a des cas où nohup ne fonctionne pas. Par exemple, lorsque le processus que vous lancez reconnecte le signal NOHUP (cela se fait à l'intérieur, au niveau du code de l'application).

Dans le cas décrit, le manque de différences m'a mordu quand à l'intérieur d'un service personnalisé lançant script il y avait un appel à un second script qui met en place et lance l'application appropriée sans commande nohup.

Sur un environnement Linux, tout a fonctionné sans problème, sur un second, l'application s'est arrêtée dès que le deuxième script est sorti (détecter ce cas, bien sûr, m'a pris beaucoup plus de temps que vous ne le pensez :stuck_out_tongue :).

Après avoir ajouté nohup comme méthode de lancement au second script, l'application continue de fonctionner même si les scripts se terminent et ce comportement est devenu cohérent sur les deux environnements.