D'un autre côté, je ne vois pas comment exécuter un programme sur un FS sans supporter de FS au préalable,
Tu peux exécuter un programme sur un FS en lecture seule, alors que je suis pas sur que tu puisses créer un pipe/socket nommé sans un endroit ou écrire (donc avant le montage de /tmp ou /run).
Ceci dit, c'est sans doute improbable que ça soit ça.
Pareil pour un socket si ma mémoire est bonne. Les pipes ne sont pas forcément nommés, mais un pipe non nommé serait plus intrusif.
Dans mon souvenir (mais rien ne semble aller dans mon sens sur stackoverflow ou la doc), plusieurs clients qui écrivent sur un pipe peuvent interférer les uns avec les autres (vu qu'il n'y a qu'un seul FD pour lire pour tous. Donc ça voudrait dire ouvrir 1 pipe par process pour être sur de ne pas avoir de race condition, et ça me semble sous optimal pour la scalabilité.
Alors qu'avec une socket en mode datagram, tu n'as pas le souci vu que le kernel s'occupe de séparer les messages par client et tu as le pid en plus (et donc, tu peux chercher le pid dans le cgroup pour savoir quel service est ready).
Après réflexion, c'est sûrement la raison, plus que mon histoire de montage en RO sans /tmp/ ou /run/.
Mais ceci dit, tu peux aussi passer par une socket abstraite (sous Linux) qui n'est pas sur le disque, et donc la passer via une variable d’environnement, donc même si c'est pas la raison, ç'est peut être un bonus.
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par Misc (site web personnel) . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 4.
Tu peux exécuter un programme sur un FS en lecture seule, alors que je suis pas sur que tu puisses créer un pipe/socket nommé sans un endroit ou écrire (donc avant le montage de /tmp ou /run).
Ceci dit, c'est sans doute improbable que ça soit ça.
Dans mon souvenir (mais rien ne semble aller dans mon sens sur stackoverflow ou la doc), plusieurs clients qui écrivent sur un pipe peuvent interférer les uns avec les autres (vu qu'il n'y a qu'un seul FD pour lire pour tous. Donc ça voudrait dire ouvrir 1 pipe par process pour être sur de ne pas avoir de race condition, et ça me semble sous optimal pour la scalabilité.
Alors qu'avec une socket en mode datagram, tu n'as pas le souci vu que le kernel s'occupe de séparer les messages par client et tu as le pid en plus (et donc, tu peux chercher le pid dans le cgroup pour savoir quel service est ready).
Après réflexion, c'est sûrement la raison, plus que mon histoire de montage en RO sans /tmp/ ou /run/.
Mais ceci dit, tu peux aussi passer par une socket abstraite (sous Linux) qui n'est pas sur le disque, et donc la passer via une variable d’environnement, donc même si c'est pas la raison, ç'est peut être un bonus.