L'ID de process et l'identifiant de session d'un démon peuvent-ils différer?

Pour autant que j'ai compris à partir de différents articles et ici , un démon a les caractéristiques suivantes:

  1. L'ID de process parent doit être 1.
  2. Aucun terminal ne doit être associé au process.
  3. L'ID de process, l'ID de session et l'ID de groupe de process du process doivent être égaux.

Il semble fonctionner pour certains des démons de mon système. Cependant, l' avahi-daemon de mon système a le PID 678 et les deux autres id, 677. Pourquoi est-il ainsi?

Y a-t-il d'autres fonctionnalités pour identifier les démons?

Vos caractéristiques sont trop ressortingctives. La notion key est la suivante: un démon est un process d'arrière-plan, il ne peut donc pas être le process de contrôle d'un terminal, ni avoir un terminal de contrôle . Cette simple "règle" permet aux démons de survivre à travers les terminaux ouverts / fermés et les users se connectent / se déconnectent.

Chaque terminal a une session de contrôle, c'est-à-dire un set de process générés par ce terminal. Le chef de session, généralement un shell, est le process de contrôle du terminal. Le terminal est censé être le terminal de contrôle du shell.

Comme vous pourrez lire dans cette réponse à une de mes questions , lorsqu'un terminal est fermé, il envoie un signal SIGHUP à son process de contrôle, le shell. Cela entraîne généralement la mort de tous les process liés à ce shell, car le shell retransmet le SIGHUP qu'il a reçu à tous ses travaux.

Les process démons doivent échapper à cette string car ils doivent survivre aux connections et aux déconnections des users. Pour cette raison, ils doivent se détacher de leur shell parent. Une façon courante de le faire est de doubler la fourchette.

  1. Le démon génère un process enfant.
  2. Le démon quitte son process "principal" / parent.
  3. Tout le travail est fait chez l'enfant.

Puisque les coquilles ne gardent pas les traces de leurs petits-enfants, ils n'envoient pas de SIGHUP au rest du démon. Maintenant, dans cette configuration, les petits-enfants (daemon) devraient fondamentalement avoir:

  • Son propre PID, comme tout autre process.
  • La PGID de son parent maintenant terminé.
  • Le PPID de son subreaper le plus proche, généralement PID 1.
  • Le SID de son parent maintenant terminé, qui est généralement le SID du shell.

Notez que tuer le parent n'était pas particulièrement nécessaire: le process serait mort avec son terminal. Cependant, pour éviter les process inutiles, il est un peu plus propre de mettre fin au parent immédiatement avant que l'enfant ne commence à travailler.

Dans cette situation, le process peut être appelé un démon. Fermer le terminal ne le tue pas. Cependant, il est très courant de donner une toute nouvelle session aux process daemon. Au niveau de l'API, ceci est fait en utilisant l' setsid système setsid . Une fois qu'il a été utilisé, le process devrait avoir:

  • Un PID inchangé.
  • Un PPID inchangé (le plus proche subreaper).
  • Un nouveau SID, généralement le même que son PID.
  • Un nouveau GID, puisque les process d'un même groupe doivent également être dans la même session.

Cela signifie simplement que le parent du démon (pid 677) a commencé la nouvelle session, forked, et l'enfant (pid 678) a hérité de cette session et a continué à fonctionner.

Cela pourrait se produire si un script wrapper était utilisé pour démoniser quelque chose (et pour une raison quelconque n'exécutait pas sa cible – peut-être pour gérer les redémarrages), ou simplement parce que le process a choisi de fourrer à nouveau avant d'entrer son état stable.

Je dirais qu'un process est effectivement un démon si PPID est 1 et qu'il n'a pas de terminal de contrôle. La contrainte id de session / process d'identification de groupe est souvent aussi vraie, mais n'est pas réellement nécessaire pour le comportement démoniaque.