Quelle est la différence entre l'exécution d'un programme en tant que démon et le déplacement en arrière-plan avec '&'?

Quelles sont les différences pratiques d'un sharepoint vue sysadmin lors du deployment de services sur un système basé sur unix?

    La méthode traditionnelle de démonisation est la suivante:

    fork() setsid() close(0) /* and /dev/null as fd 0, 1 and 2 */ close(1) close(2) fork() 

    Cela garantit que le process n'est plus dans le même groupe de process que le terminal et ne sera donc pas tué avec lui. La redirection d'E / S consiste à ne pas afficher la sortie sur le terminal.

    Pour un démon, ce que vous voulez est un process qui n'a aucun lien avec quoi que ce soit. À tout le less, vous voulez qu'il soit dans sa propre session, ne pas être attaché à un terminal, ne pas avoir un descripteur de file hérité du parent ouvert à n'importe quoi, pas un parent qui s'occupe de vous (autre qu'init) directory dans / afin de ne pas empêcher un déassembly …

    Pour se détacher d'un terminal, vous créez une nouvelle session. Cependant, pour créer une session, vous ne devez pas être un leader de groupe (ou de session), il est donc préférable d'utiliser un nouveau process. En supposant que le parent quitte, cela signifie également que le process n'aura plus de parent et sera adopté par init. Ensuite, chdir("/") , fermez tous les descripteurs de files possibles.

    Parce que ce process est un leader de session, il existe un risque que si jamais il ouvre un terminal, il devient le process de contrôle de ce terminal. La fourchette une deuxième fois assure que cela n'arrive pas.

    À l'autre extrémité, dans les shells interactifs, crée un nouveau groupe de process (pour ne pas être dans le groupe de process de premier plan du terminal) et dans les shells non interactifs, crée un process et ignore SIGINT. Il ne se détache pas du terminal, ne ferme pas les descripteurs de files (bien que certains shells rouvriront stdin à /dev/null ) …

    Avec la command & Votre process sera tué par un signal SIGHUP lorsque le parent meurt.

    Les administrateurs système ont cependant access à certaines solutions de contournement.

    Sur un système bash, vous pouvez utiliser:

     (trap '' HUP; command) & 

    Cela ouvre un sous-shell, intercepte le signal HUP avec un gestionnaire vide et l'esperluette / le fourche.

    La sortie pourrait toujours être redirigée vers le mauvais tty . Ou se perdre.
    Vous pouvez résoudre ce problème avec &>command.out , 1>output.out ou 2>errors.out

    Vous pouvez également avoir access, sur la plupart des systèmes, à la command nohup .
    nohup simplifie grandement ce process. C'est assez standard, mais j'ai trouvé de nombreuses dissortingbutions ARM embarquées dans busybox qui me manquent. Vous écrivez juste:

     nohup command & 

    ..et tu as fini. La sortie est redirigée, IIRC, vers nohup.out , mais ce nom de file peut être changé avec une option.

    La différence entre l'exécution d'un programme / process en tant que démon et sa conversion en arrière-plan à l'aide de l'esperluette est essentiellement liée à la propriété.

    Le plus souvent, le process parent d'un démon est le process init (le tout premier process démarré sur un système Unix), le démon étant un enfant de ce process signifie qu'il n'est pas sous votre contrôle direct en tant qu'user non privilégié . Tandis que d'un autre côté, en forçant un programme / process à l'arrière-plan, vous pouvez à tout moment le callbacker au premier plan et / ou le tuer.