Quelle est la différence entre nohup et un daemon ?

Question

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 bifurcation, etc., mais quel impact cela a-t-il sur mon script ?

Answer 1

Le site nohup est la façon la plus simple 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, elle dispose d'un terminal de contrôle et recevra un signal SIGHUP (raccrochage) lorsque le processus de contrôle (généralement votre shell de connexion) quittera. Le site nohup La commande fait en sorte que l'entrée provienne de /dev/null et pour que la production et les erreurs aillent à nohup.out et pour que le programme ignore les interruptions, les signaux de sortie et les interruptions. En fait, il a toujours le même terminal de contrôle - il ignore simplement les commandes du terminal. Notez que si vous voulez que le processus s'exécute en arrière-plan, vous devez demander au shell de l'exécuter en arrière-plan - du moins sous Solaris (c'est-à-dire que vous tapez ' nohup sleep 20 & ' ; sans l'esperluette, le processus s'exécute de manière synchrone en avant-plan).

En général, un processus exécuté via nohup est quelque chose qui prend du temps, mais qui ne traîne pas en attendant une interaction venant d'ailleurs.

En général (ce qui signifie que si vous faites des efforts, 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 qui attend de répondre à une entrée quelconque. Les démons réseau attendent que des demandes de connexion ou des messages UDP arrivent sur le réseau, effectuent le travail approprié et renvoient une réponse. Pensez à un serveur Web, par exemple, ou à un SGBD.

Lorsqu'un processus se démonétise complètement, il passe par certaines des étapes que le programme nohup passe ; il réorganise ses E/S de manière à n'être 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, puisqu'il n'y a pas de terminal pour lui envoyer les signaux générés par un terminal). En général, il bifurque une fois, et le parent se termine avec succès. Le processus enfant bifurque généralement une seconde fois, après avoir fixé son groupe de processus, son ID de session, etc. Le processus petit-enfant est maintenant autonome et n'apparaîtra pas dans la base de données de l ps pour le terminal où il a été lancé.

Vous pouvez consulter Programmation avancée dans l'environnement Unix, 3e éd. par W Richard Stevens et Stephen A Rago, ou à l'adresse suivante Programmation Unix avancée, 2ème édition par Marc J Rochkind pour des discussions sur la démonisation.

J'ai un programme daemonize qui va démoniser un programme qui ne sait pas comment se démoniser (correctement). Il a été écrit pour contourner les défauts d'un programme qui était censé se démoniser mais qui n'a pas fait le travail correctement. Contactez-moi si vous le voulez - voir mon profil.

Answer 2

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 à mot en raison des droits d'auteur (voir la section À propos), mais voici le résumé :

1. fork (première fois) -- donc on n'est pas un chef de groupe, et on laisse le parent sortir.
2. appelez 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.
3. fork (deuxième fois) -- nous ne sommes donc pas un chef de session (et ne pouvons donc pas reprendre le contrôle du terminal), et laissons le parent sortir.
4. cd au répertoire Root -- ainsi nous n'empêchons pas d'autres répertoires d'être umountés.
5. set umask à la valeur désirée (optionnel) -- parce que nous aurions pu hériter d'un masque que nous ne voulions pas.
6. fermer stdin, stdout, stderr (ou juste les rouvrir pour pointer ailleurs)

nohup

Quoi nohup fait :

• Si stdout et stderr sont connectés à un terminal, les redirige vers nohup.out
• ignore le SIGHUP

---

Similitudes et différences

Remarquez que les seules actions communes sont la redirection de 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 le processus en arrière-plan, ce qui signifie que vous pouvez toujours utiliser ctrl-c pour envoyer un SIGINT. Le processus répond toujours à l'entrée 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 fonctions normalement utilisées avec lui (par exemple, l'arrière-plan). L'OP a posé une question spécifique sur nohup .

En pratique

En termes pratiques, lorsque vous souhaitez démarrer un processus unique à longue durée d'exécution qui doit se poursuivre lorsque l'interpréteur de commandes se termine, vous voudrez utiliser nohup mais vous voudrez aussi le combiner avec le traitement en arrière-plan et la redirection de stdin. Un travail unique ne vaut pas la peine d'être transformé en 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 effectuées selon 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 les tâches répétées dont l'heure de début n'est pas prévisible. Il n'y a normalement pas d'heure de fin définie pour le processus daemon (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 sur un périphérique d'entrée-sortie via unix select()). D'autres démons recherchent une condition et exécutent une action en 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é à ses stdin, stdout, stderr. Un seul groupe de processus peut avoir accès à stdin. Par défaut, les groupes de processus en arrière-plan peuvent également écrire sur stdout et stderr.

De plus, il semble que les signaux de clavier envoyés à un terminal ne sont envoyés qu'au groupe de processus qui l'a comme terminal de contrôle.

Answer 3

Dans les variantes d'UNIX, un processus est associé à un processus terminal (shell de connexion). Ainsi, lorsque le processus terminal s'arrête, le processus est également arrêté, en raison de cette association. Le nohup empêche un processus de s'arrêter lorsque le terminal s'arrête.

Un daemon ou démon est un processus qui est lancé par le système au démarrage, il fonctionne jusqu'à l'arrêt, aucun utilisateur ne l'a demandé explicitement. Par définition, il ne fait donc pas partie de l'interaction de l'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 sysadmin, vous pouvez installer un processus deamon. Pour le processus, cela n'a pas d'importance.

Answer 4

Un daemon ne peut pas être initié, alors que nohup est initié par l'utilisateur.