Tl; dr:
Pourquoi le sleep
processus peut-il survivre lorsque je me déconnecte et que le terminal est fermé? Dans mon esprit, tout sauf les démons et les nohup
programmes sera tué lors de la déconnexion. Si sleep
peut survivre de cette façon, cela signifie-t-il que je peux utiliser cette méthode à la place de la nohup
commande?
À moins que l' bash
instance engendrée par ssh
n'ait l' huponexit
option définie, aucun processus ne sera interrompu de quelque manière que ce soit à la sortie / déconnexion, et lorsque l' huponexit
option est définie, l'utilisation kill -9
sur le shell n'est pas une bonne alternative à l'utilisation nohup
sur les processus enfants du shell; nohup
sur le shell, les processus enfants les protégeront toujours contre les SIGHUP qui ne proviennent pas du shell, et même lorsque cela n'est pas important, il nohup
faut toujours le préférer car cela permet de terminer le shell avec élégance.
Il bash
y a une option appelée huponexit
qui, si elle est définie, fera de bash
SIGHUP ses enfants à la sortie / déconnexion;
Dans les bash
instances interactives sans connexion , comme dans une bash
instance générée par gnome-terminal
, cette option est ignorée; qu'il huponexit
soit réglé ou non, bash
les enfants de 'S ne seront jamais SIGHUPpés bash
à la sortie;
Dans les instances de connexion interactive bash
, comme dans une bash
instance engendrée par ssh
, cette option n'est pas ignorée (mais elle n'est pas définie par défaut); s'il huponexit
est défini, bash
les enfants de SIGHUP seront suivis par bash
à la sortie / déconnexion; s'il huponexit
n'est bash
pas défini , les enfants de ne seront pas SIGHUPped bash
à la sortie / déconnexion;
Donc, en général, la fermeture / déconnexion d'une bash
instance de connexion interactive , sauf si l' huponexit
option est définie, ne fera pas du shell SIGHUP ses enfants, et la fermeture / déconnexion d'une bash
instance interactive sans connexion ne fera pas du shell SIGHUP ses enfants indépendamment;
Cela n'est cependant pas pertinent dans ce cas: l'utilisation kill -9
sleep
survivra malgré tout, car la suppression de son processus parent ( bash
) ne laissera aucune chance à ce dernier de faire quoi que ce soit à l'ancien (par exemple, si l' bash
instance actuelle était une bash
instance de connexion) . et l' huponexit
option a été définie, à SIGHUP it).
De plus, contrairement à d'autres signaux (comme un signal SIGHUP envoyé à bash
), un signal SIGKILL n'est jamais propagé aux processus enfants d'un processus, il sleep
n'est donc même pas tué;
nohup
démarre un processus insensible aux signaux SIGHUP, ce qui est différent; cela empêchera le processus de raccrocher à la réception d'un signal SIGHUP, qui dans ce cas pourrait être reçu par l' bash
instance de connexion interactive au cas où l' huponexit
option aurait été définie et le shell quitté; donc, techniquement, utiliser nohup
pour démarrer un processus dans une bash
instance de connexion interactive avec l' huponexit
option unset empêchera le processus de raccrocher à la réception d'un signal SIGHUP, mais quitter / se déconnecter du shell ne le SIGHUP le fera pas indépendamment;
En général, cependant, lorsque cela nohup
est nécessaire pour empêcher les signaux SIGHUP provenant du shell parent, il n'y a aucune raison de préférer la kill -9
méthode on the parent à la méthode nohup
on the child; au contraire, ce devrait être le contraire.
Tuer le parent à l'aide de la kill -9
méthode ne laisse aucune chance au parent de sortir avec élégance, tandis que le démarrage de l'enfant à l'aide de la nohup
méthode permet au parent d'être interrompu par d'autres signaux, tels que SIGHUP (pour donner un exemple qui a du sens dans le contexte d'un enfant a commencé à utiliser nohup
), ce qui lui permet de sortir avec élégance.
&
va bifurquer le processus en arrière-plan (comme le démon) et continue de fonctionner même si vous êtes déconnecté.