C'est exactement ce que fait inetd. Et comme stunnel est à TLS
ce que inetd est à IP, pourquoi systemd ne prend pas en charge
l'initialisation des sockets TLS, dans leur logique ça devrait
être le cas ?
Si c'est pas le cas, alors ta vision de la logique des developpeurs est fausse.
Il me semblait qu'une gestion des dépendances permettaient de
lancer les services dans un ordre correct et non pas dans
n'importe quel ordre.
Si tu arrives à déterminer quand un service est effectivement démarré. C'est tout le noeud du problème. sysinit et d'autres s'en préoccuppent pas vraiment. Ça marche la plupart du temps, mais tu es obligé de faire ça en série, en partant du principe que ça démarre assez vite. parfois, tu rajoutes des sleep par ci par la, mais bon. On a vu le cas chez mandriva avec les cartes réseaux qui mettent 10 secondes à avoir leur ip, et les services notés "aprés le réseau" ne pas réussir à écouter comme il faut. Et puis parfois, tu as pas le souci, et tu sais pas ce qui est différent.
Upstart s'y prends différement. Il va suivre les process avec ptrace et voir le nombre de fork fait et à partir de la, dire "ok, il est lancé". C'est buggué, je vais pas revenir la dessus, j'ai collé les liens à chaque discussion sur systemd.
Donc la vrai solution, c'est que le service dise "je suis prêt".
D'ou la discussion sur le BTS Debian sur le sujet, avec l'idée d'utiliser sigstop (comme upstart ), refuser car posant divers souci. Systemd propose un protocole qui consiste à envoyer un message sur une socket donné par systemd lors du lancement, mais faut patcher le code des programmes, et ça se fait pas tout seul ( bien que de mon expérience, c'est pas le code le plus problématique, c'est les autotools ). Donc en attendant, il y a des heuristiques. On considére que le service est pret quand il a forké, quand il fait un fichier de pid, ou on utilise l'activation par socket, pour les cas ou "programme pret == programme qui écoute". Comme les sockets sont ouvertes avant de lancer toutes les unités, alors les dépendances ne sont plus importantes si la dépendance exprime juste "j'ai besoin de me connecter à tel service gére par la socket activation". Ça supporte dbus, les fifo, les messages netlink, etc, donc ç'est large. Ensuite, oui, si ton service depend d'un truc plus compliqué, alors la bonne façon, c'est de rajouter le protocole de notification, ou de faire comme avant, se dire que ça va marcher sans synchronisation.
systemd supporte-t-il l'activation pour les services utilisant
les "raw socket" (vrai question) ?
Non, pas que je sache. Je pense pas que ça soit super complexe à rajouter, et je suppose qu'un truc comme snort pourrait s'en servir, mais j'ai quand même du mal à voir des cas d'utilisation. Ceci dit, je garde l'idée le jour ou je m'ennuie et j'ai envie de faire du C.
Quand à la gestion des crash, c'est indépendant de
l'activation des socket de systemd et, pour faire juste, il
faudrait communiquer avec le service afin de contrôler son
fonctionnement. Le service peut sembler fonctionnel alors
qu'en fait il est planter, donc on est obliger de prévoir une
solution supplémentaire capable de parler le protocole du
service afin de s'assurer qu'il fonctionne correctement.
la réalité est plus compliqué que ça. Tu as plusieurs façons de planter, et c'est pas parce qu'un outil ne couvre pas tout les cas imaginables que couvrir 50% est inutile, loin de la. Déjà, tu peux faire de l'activation comme inetd avec 1 process par client. La, je pense que j'ai pas besoin de dire pourquoi ça marche quand le process se plante. Mais même avec 1 process pour tout les clients, il est relancé si jamais ça se gauffre, vu que c'est un retour l'état de début.
Quand à avoir un process qui ne marche pas mais qui tourne encore, il y a aussi un système de watchdog ou le process signal "je tourne encore" à intervalle régulier. Bien que ça ne règle pas le cas "je tourne mais je dit de la merd", ça donne un truc de plus entre le simple "le pid est la donc c'est bon" et le plus lourd "je lance une analyse compléte de la réaction du serveur" que ferait un nagios.
Il faut bien voir que plus un test est léger, plus on peut le lancer souvent. Exemple, voir qu'un process est planté pour systemd, c'est 3 fois rien. Mais plus il est leger, moins il couvre de choses. Dans le cas extrême d'un site, voir que 15 urls renvoient pas "error 500" en suivant un scénario web précis , c'est un chouia plus lourd, tu va pas le lancer tout les 10 secondes. Dans le cas d'un watchdog dans systemd, c'est un bete timer, et je pense que faire ça chaque 30 secondes ( ie, une écriture dans un socket ), c'est pas la mort.
Encore une fois, l'idée est pas de remplacer, mais de profiter de la poistion du gestionnaire d'init pour proposer des features en plus, à un autre endroit sur une échelle "precision/lourdeur" de test.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 7.
Si c'est pas le cas, alors ta vision de la logique des developpeurs est fausse.
Si tu arrives à déterminer quand un service est effectivement démarré. C'est tout le noeud du problème. sysinit et d'autres s'en préoccuppent pas vraiment. Ça marche la plupart du temps, mais tu es obligé de faire ça en série, en partant du principe que ça démarre assez vite. parfois, tu rajoutes des sleep par ci par la, mais bon. On a vu le cas chez mandriva avec les cartes réseaux qui mettent 10 secondes à avoir leur ip, et les services notés "aprés le réseau" ne pas réussir à écouter comme il faut. Et puis parfois, tu as pas le souci, et tu sais pas ce qui est différent.
Upstart s'y prends différement. Il va suivre les process avec ptrace et voir le nombre de fork fait et à partir de la, dire "ok, il est lancé". C'est buggué, je vais pas revenir la dessus, j'ai collé les liens à chaque discussion sur systemd.
Donc la vrai solution, c'est que le service dise "je suis prêt".
D'ou la discussion sur le BTS Debian sur le sujet, avec l'idée d'utiliser sigstop (comme upstart ), refuser car posant divers souci. Systemd propose un protocole qui consiste à envoyer un message sur une socket donné par systemd lors du lancement, mais faut patcher le code des programmes, et ça se fait pas tout seul ( bien que de mon expérience, c'est pas le code le plus problématique, c'est les autotools ). Donc en attendant, il y a des heuristiques. On considére que le service est pret quand il a forké, quand il fait un fichier de pid, ou on utilise l'activation par socket, pour les cas ou "programme pret == programme qui écoute". Comme les sockets sont ouvertes avant de lancer toutes les unités, alors les dépendances ne sont plus importantes si la dépendance exprime juste "j'ai besoin de me connecter à tel service gére par la socket activation". Ça supporte dbus, les fifo, les messages netlink, etc, donc ç'est large. Ensuite, oui, si ton service depend d'un truc plus compliqué, alors la bonne façon, c'est de rajouter le protocole de notification, ou de faire comme avant, se dire que ça va marcher sans synchronisation.
Non, pas que je sache. Je pense pas que ça soit super complexe à rajouter, et je suppose qu'un truc comme snort pourrait s'en servir, mais j'ai quand même du mal à voir des cas d'utilisation. Ceci dit, je garde l'idée le jour ou je m'ennuie et j'ai envie de faire du C.
la réalité est plus compliqué que ça. Tu as plusieurs façons de planter, et c'est pas parce qu'un outil ne couvre pas tout les cas imaginables que couvrir 50% est inutile, loin de la. Déjà, tu peux faire de l'activation comme inetd avec 1 process par client. La, je pense que j'ai pas besoin de dire pourquoi ça marche quand le process se plante. Mais même avec 1 process pour tout les clients, il est relancé si jamais ça se gauffre, vu que c'est un retour l'état de début.
Quand à avoir un process qui ne marche pas mais qui tourne encore, il y a aussi un système de watchdog ou le process signal "je tourne encore" à intervalle régulier. Bien que ça ne règle pas le cas "je tourne mais je dit de la merd", ça donne un truc de plus entre le simple "le pid est la donc c'est bon" et le plus lourd "je lance une analyse compléte de la réaction du serveur" que ferait un nagios.
Il faut bien voir que plus un test est léger, plus on peut le lancer souvent. Exemple, voir qu'un process est planté pour systemd, c'est 3 fois rien. Mais plus il est leger, moins il couvre de choses. Dans le cas extrême d'un site, voir que 15 urls renvoient pas "error 500" en suivant un scénario web précis , c'est un chouia plus lourd, tu va pas le lancer tout les 10 secondes. Dans le cas d'un watchdog dans systemd, c'est un bete timer, et je pense que faire ça chaque 30 secondes ( ie, une écriture dans un socket ), c'est pas la mort.
Encore une fois, l'idée est pas de remplacer, mais de profiter de la poistion du gestionnaire d'init pour proposer des features en plus, à un autre endroit sur une échelle "precision/lourdeur" de test.