Quelle est la différence entre Nohup et un démon?
Quelles sont les implications de l'exécution d'un script en tant que démon par rapport à l'utilisation de nohup?
Je sais quelle est la différence en termes de processus de forking etc., mais quel impact cela a-t-il sur mon script?
La commande Nohup est la manière du pauvre homme d'exécuter un processus en tant que démon. Comme l'a noté Bruno Ranschaert, lorsque vous exécutez une commande dans un shell interactif, il a un terminal de contrôle et recevra un signal SIGHUP (raccrochage) lorsque le processus de contrôle (généralement votre shell de connexion) se termine. La commande Nohup fait en sorte que l'entrée provienne de /dev/null, et pour la sortie et les erreurs aller à Nohup.out, et pour que le programme ignore les interruptions, quitte les signaux et raccroche. En fait, il a toujours le même terminal de contrôle - il ignore simplement les contrôles des terminaux. Notez que si vous voulez que le processus s'exécute en arrière-plan, vous devez dire au shell de l'exécuter en arrière-plan - au moins sur Solaris (c'est-à-dire que vous tapez 'Nohup sleep 20 & '; sans esperluette, le processus s'exécute de manière synchrone au premier plan).
En règle générale, un processus exécuté via Nohup est quelque chose qui prend du temps, mais qui ne reste pas en attente d'interaction venant d'ailleurs.
En règle générale (ce qui signifie que si vous essayez dur, vous pouvez trouver des exceptions à ces règles), un processus démon est quelque chose qui se cache en arrière-plan, déconnecté de tout terminal, mais attendant de répondre à une entrée quelconque. Les démons réseau attendent que les demandes de connexion ou les messages UDP arrivent sur le réseau, effectuez le travail approprié et renvoyez une réponse. Pensez à un serveur Web, par exemple, ou à un SGBD.
Lorsqu'un processus se démonifie complètement, il passe par certaines étapes du code Nohup; il réorganise ses E/S afin qu'il ne soit connecté à aucun terminal, se détache du groupe de processus, ignore les signaux appropriés (ce qui pourrait signifier qu'il n'ignore aucun signal, car il n'y a pas de terminal pour lui envoyer les signaux générés via un terminal). En règle générale, il bifurque une fois et le parent se ferme correctement. Le processus enfant se déroule généralement une deuxième fois, après avoir corrigé son groupe de processus et son ID de session, etc. l'enfant sort alors aussi. Le processus de petit-enfant est maintenant autonome et n'apparaîtra pas dans la sortie ps pour le terminal où il a été lancé.
Vous pouvez consulter Programmation avancée dans l'environnement Unix, 3e édition par W Richard Stevens et Stephen A Rago, ou Programmation avancée Unix, 2e édition par Marc J Rochkind pour des discussions de démonétisation.
J'ai un programme daemonize qui démonisera un programme qui ne sait pas se démoniser (correctement). Il a été écrit pour contourner les défauts d'un programme qui était censé se démonifier lui-même mais n'a pas fait le travail correctement. Contactez-moi si vous le souhaitez - voir mon profil.
Devenir un démon
Ce lien contient une bonne liste d'étapes qu'un processus doit suivre pour devenir un démon:
https://web.archive.org/web/20120328110436/http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16
Je ne peux pas copier la liste mot pour mot à cause du droit d'auteur (voir la section À propos), mais voici le résumé:
fork(première fois) - donc nous ne sommes pas un chef de groupe et laissons le parent sortir.- appeler
setsid()- pour devenir le leader d'une nouvelle session. Cet appel ne fonctionne que si nous ne sommes pas un chef de groupe. Cette nouvelle session n'a pas de terminal de contrôle. fork(deuxième fois) - donc nous ne sommes pas un chef de session (et ne pouvons donc pas retrouver un terminal de contrôle), et laissons le parent sortir.cdvers le répertoire racine - donc nous n'empêchons pas les autres répertoires d'être démontés.- définissez
umasksur la valeur souhaitée (facultatif) - car nous aurions pu hériter d'un masque dont nous ne voulions pas. - fermer stdin, stdout, stderr (ou simplement les rouvrir pour pointer ailleurs)
Nohup
Ce que Nohup fait:
- Si stdout et stderr sont connectés à un terminal, les redirige vers
Nohup.out - ignore SIGHUP
Similitudes et différences
Remarquez comment les seules actions courantes redirigent stdout et stderr. Pour être un démon, il n'est même pas nécessaire d'ignorer SIGHUP.
Nohup ne vous oblige pas à utiliser '& 'pour mettre en arrière-plan le processus - ce qui signifie que vous pouvez toujours utiliser ctrl-c pour envoyer SIGINT. Le processus répond toujours à la saisie au clavier. Il ne change pas non plus stdin automatiquement, il est donc recommandé de le faire vous-même via "< /dev/null ".
Veuillez ne pas confondre Nohup avec d'autres fonctionnalités normalement utilisées avec lui (par exemple, l'arrière-plan). L'OP a posé des questions spécifiques sur Nohup.
En pratique
En termes pratiques, lorsque vous souhaitez démarrer un processus unique à long terme qui devrait se poursuivre à la fermeture du shell, vous voudrez utiliser Nohup, mais vous voudrez également le combiner avec un arrière-plan et redirection de stdin. Un travail ponctuel ne vaut pas la peine de créer un démon, mais certaines des propriétés d'un démon peuvent toujours être utiles avec un travail Nohup, comme "cd / ".
Les tâches périodiques sur un calendrier régulier sont mieux exécutées via cron (ou un autre planificateur).
Les démons sont les mieux adaptés pour superviser des tâches répétées qui n'ont pas d'heure de début prévisible. Il n'y a normalement pas d'heure de fin définie pour le processus démon (il est explicitement arrêté par un utilisateur/un autre processus ou par l'arrêt du système). Les démons sont souvent des services qui répondent à des applications (clients) ou à d'autres conditions (par exemple, des données entrantes via un périphérique IO via unix select ()). D'autres démons interrogent une condition et exécutent une action dans réponse.
Addendum sur le contrôle du terminal
Voir cette page . Un résumé rapide est qu'un terminal de contrôle accorde un accès illimité à son stdin, stdout, stderr. Un seul groupe de processus peut avoir accès à stdin. Par défaut, les groupes de processus d'arrière-plan peuvent également écrire sur stdout et stderr.
De plus, il semble que les signaux du clavier envoyés à un terminal ne soient envoyés qu'au groupe de processus qui en fait un terminal de contrôle.
Dans les variantes UNIX, un processus est associé à un processus terminal (shell de connexion). Ainsi, lorsque le processus terminal se termine, le processus est également interrompu en raison de cette association. Le Nohup empêche un processus de se terminer lorsque le terminal s'arrête.
Un démon ou un démon est un processus qui est démarré par le système au démarrage, il s'exécute jusqu'à l'arrêt, aucun utilisateur ne l'a demandé explicitement. Ainsi, par définition, il ne fait pas partie d'une interaction utilisateur mais appartient au système.
Si vous avez accès au système en tant qu'utilisateur, vous pouvez utiliser Nohup. Si vous êtes administrateur système, vous pouvez installer un processus de démon. Pour le processus, cela n'a pas d'importance.