Je pense de plus en plus à implémenter un init pour les BSDs avec les
mêmes possibilités qu'offre systemd. En effet, celui-ci offre des
avantages que l'on ne peut plus négliger pour un OS moderne.
Parmi ces avantages, on peut noter, par exemple, la possibilité
d'implémenter un monitoring de daemon évolué par rapport
à ce que permet l'init de BSD, la possibilité de gérer l'hard dans
l'init lui-même, d'avoir une journalisation digne de ce nom au format
binaire, s'il vous plait, de gérer des containers, etc. J'arrête là,
les avantages apporté par cet init qui, de fait, sont bien trop
nombreux pour qu'un humain ordinaire puisse tous les énumérer.
Certes, il reste peut-être quelques petites erreurs de jeunesse, qui
seront, à ne pas douter, rapidement corriger, les mainteneurs de systemd
étant particulièrement réceptifs aux corrections de bugs, mais tout
celà ne devrait pas empêcher une bonne intégration dans un système BSD,
d'autant plus si l'on implémente from scratch.
Pourquoi from scratch ? Le problème est que systemd est sous licence
GNU LGPL 1.2, et quand bien même il existe des logiciels sous
licence GNU dans le coeur des principaux BSDs, il serait préférable
d'utliser une vrai licence libre.
Enfin il reste le choix du premier BSD pour commencer cette
implémentation. Le choix de FreeBSD est évident. C'est le seul à
posséder un système de type MAC digne de ce nom grâce à Trusted BSD, ce
qui, de facto, démontre sans aucun doute que c'est le système le
plus sécurisé de la famille BSD.
Cependant, je ne suis pas assez familiarisé avec cet init
extraordinaire, d'où ma demande sur fcold aux divers spécialistes
des Linux qui ont très certainement d'autres arguments en faveur de
systemd, des conseils sur comment bien implémenter un journal binaire,
ce genre de choses, quoi.
A noter, si je ne crosspote pas avec fcob, c'est bien pour leur laisser
l'agréable surprise lorsque le nouvel init sera commité pour la
prochaine release de FreeBSD (la 11.1 donc).
Tu veux dire que systemd est capable de vérifier le taux de remplissage du swap, les espaces disques, le nombre de status en erreur dans une base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Tu n'as rien compris, mais ça n'étonne personne. Reste dans ta fange.
Disons surtout que tu t'es mal exprimé. systemd n'est pas un système de monitoring, c'est un init transformé en usine à gaz pour répondre à des problèmes qui n'existent que dans l'imagination des mecs qui ne sont jamais en face de cas pratiques.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
Tu veux dire que systemd est capable de vérifier le taux de remplissage
du swap, les espaces disques, le nombre de status en erreur dans une
base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Tu n'as rien compris, mais ça n'étonne personne. Reste dans ta fange.
Disons surtout que tu t'es mal exprimé. systemd n'est pas un système de
monitoring, c'est un init transformé en usine à gaz pour répondre à des
problèmes qui n'existent que dans l'imagination des mecs qui ne sont
jamais en face de cas pratiques.
Tu veux dire que systemd est capable de vérifier le taux de remplissage du swap, les espaces disques, le nombre de status en erreur dans une base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Tu n'as rien compris, mais ça n'étonne personne. Reste dans ta fange.
Disons surtout que tu t'es mal exprimé. systemd n'est pas un système de monitoring, c'est un init transformé en usine à gaz pour répondre à des problèmes qui n'existent que dans l'imagination des mecs qui ne sont jamais en face de cas pratiques.
S.T.
On 2016-10-16, Nicolas George <nicolas$ wrote:
Et s'il n'a pas encore complètement la main mais peut à volonter faire crasher un certain processus, pouvoir s'en servir pour en faire tuer un autre peut lui permettre de progresser dans ses intentions.
Et c'est à ce moment que la marmotte referme le papier d'alu sur le chocolat et qu'on se prend le météorite sur la gueule.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
Et s'il n'a pas encore complètement la main mais peut à volonter faire
crasher un certain processus, pouvoir s'en servir pour en faire tuer un
autre peut lui permettre de progresser dans ses intentions.
Et c'est à ce moment que la marmotte referme le papier d'alu sur le
chocolat et qu'on se prend le météorite sur la gueule.
Et s'il n'a pas encore complètement la main mais peut à volonter faire crasher un certain processus, pouvoir s'en servir pour en faire tuer un autre peut lui permettre de progresser dans ses intentions.
Et c'est à ce moment que la marmotte referme le papier d'alu sur le chocolat et qu'on se prend le météorite sur la gueule.
Doug713705
Le 16-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5803b806$0$3298$) :
"S.T." , dans le message <nu0cm7$q41$, a écrit :
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que systemd. Mais si c'est développé par un admin dans son coin, ça le fait en général moins bien.
https://www.icinga.org/ pour n'en citer qu'un. -- En ce temps-là, le rien s'appelait quotidien Et nous allions pointer dans les jobs interdits. Dans les musiques blêmes, dans les sombres parfums Dans les dédales obscurs où plane la folie. -- H.F. Thiéfaine, Exil Sur planète fantôme
Le 16-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5803b806$0$3298$426a74cc@news.free.fr>) :
"S.T." , dans le message <nu0cm7$q41$2@gioia.aioe.org>, a écrit :
Et là arrive toute la logique de systemd, l'outil de la mort qui tout,
le café et le reste parce que tous les administrateurs systems sont
incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que
systemd. Mais si c'est développé par un admin dans son coin, ça le fait en
général moins bien.
https://www.icinga.org/ pour n'en citer qu'un.
--
En ce temps-là, le rien s'appelait quotidien
Et nous allions pointer dans les jobs interdits.
Dans les musiques blêmes, dans les sombres parfums
Dans les dédales obscurs où plane la folie.
-- H.F. Thiéfaine, Exil Sur planète fantôme
Le 16-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5803b806$0$3298$) :
"S.T." , dans le message <nu0cm7$q41$, a écrit :
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que systemd. Mais si c'est développé par un admin dans son coin, ça le fait en général moins bien.
https://www.icinga.org/ pour n'en citer qu'un. -- En ce temps-là, le rien s'appelait quotidien Et nous allions pointer dans les jobs interdits. Dans les musiques blêmes, dans les sombres parfums Dans les dédales obscurs où plane la folie. -- H.F. Thiéfaine, Exil Sur planète fantôme
Doug713705
Le 16-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5803ac4f$0$7983$) :
"S.T." , dans le message <nu09hj$k2d$, a écrit :
Vu le nombre de PID disponible, t'as bien une chance sur 30,000 que ça arrive avant que tu puisses détecter que ton serveur est down avec n'importe quel système de monitoring.
Si ça arrive accidentellement, peut-être. Mais je trouve que 1/30000 comme risque d'incident, ça fait beaucoup. On ne doit pas avoir les mêmes exigences en termes de fiabilité.
Non mais je parlais du PID mais c'est loin d'être le seul test à faire pour vérifier l'état d'un service. C'est même probablement le moins fiable ! -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 16-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5803ac4f$0$7983$426a34cc@news.free.fr>) :
"S.T." , dans le message <nu09hj$k2d$1@gioia.aioe.org>, a écrit :
Vu le nombre de PID disponible, t'as bien une chance sur 30,000 que ça
arrive avant que tu puisses détecter que ton serveur est down avec
n'importe quel système de monitoring.
Si ça arrive accidentellement, peut-être. Mais je trouve que 1/30000 comme
risque d'incident, ça fait beaucoup. On ne doit pas avoir les mêmes
exigences en termes de fiabilité.
Non mais je parlais du PID mais c'est loin d'être le seul test à faire
pour vérifier l'état d'un service. C'est même probablement le moins
fiable !
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 16-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5803ac4f$0$7983$) :
"S.T." , dans le message <nu09hj$k2d$, a écrit :
Vu le nombre de PID disponible, t'as bien une chance sur 30,000 que ça arrive avant que tu puisses détecter que ton serveur est down avec n'importe quel système de monitoring.
Si ça arrive accidentellement, peut-être. Mais je trouve que 1/30000 comme risque d'incident, ça fait beaucoup. On ne doit pas avoir les mêmes exigences en termes de fiabilité.
Non mais je parlais du PID mais c'est loin d'être le seul test à faire pour vérifier l'état d'un service. C'est même probablement le moins fiable ! -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Jo Engo
Le Sun, 16 Oct 2016 18:39:35 +0000, Doug713705 a écrit :
Non mais je parlais du PID mais c'est loin d'être le seul test à faire pour vérifier l'état d'un service. C'est même probablement le moins fiable !
Connaître le PID c'est surtout utile pour arrêter ou respawner le daemon. -- JOUISSIF P : Et dire que tous les ans, des centaines d'enfants exploités au tiers monde meurent dans des mines de sable à chat... Aah !... c'est trop bon !
Le Sun, 16 Oct 2016 18:39:35 +0000, Doug713705 a écrit :
Non mais je parlais du PID mais c'est loin d'être le seul test à faire
pour vérifier l'état d'un service. C'est même probablement le moins
fiable !
Connaître le PID c'est surtout utile pour arrêter ou respawner le daemon.
--
JOUISSIF
P : Et dire que tous les ans, des centaines d'enfants exploités au tiers
monde meurent dans des mines de sable à chat... Aah !... c'est trop bon !
Le Sun, 16 Oct 2016 18:39:35 +0000, Doug713705 a écrit :
Non mais je parlais du PID mais c'est loin d'être le seul test à faire pour vérifier l'état d'un service. C'est même probablement le moins fiable !
Connaître le PID c'est surtout utile pour arrêter ou respawner le daemon. -- JOUISSIF P : Et dire que tous les ans, des centaines d'enfants exploités au tiers monde meurent dans des mines de sable à chat... Aah !... c'est trop bon !
Jo Engo
Le Sun, 16 Oct 2016 17:24:34 +0000, Nicolas George a écrit :
Avec systemd, c'est systemd lui-même qui lance les différents services. Et pour les services qui s'acharnent à abandonner leur père, il les adopte puisqu'il a le PID 1.
Et si systemd a une faille, tout le système est compromis. C'est bien ce truc... -- Aimer, c'est trouver sa richesse hors de soi. -+- Émile Chartier, dit Alain (1868-1951), Éléments de philosophie -+-
Le Sun, 16 Oct 2016 17:24:34 +0000, Nicolas George a écrit :
Avec systemd, c'est systemd lui-même qui lance les différents services.
Et pour les services qui s'acharnent à abandonner leur père, il les
adopte puisqu'il a le PID 1.
Et si systemd a une faille, tout le système est compromis. C'est bien ce
truc...
--
Aimer, c'est trouver sa richesse hors de soi.
-+- Émile Chartier, dit Alain (1868-1951), Éléments de
philosophie -+-
Le Sun, 16 Oct 2016 17:24:34 +0000, Nicolas George a écrit :
Avec systemd, c'est systemd lui-même qui lance les différents services. Et pour les services qui s'acharnent à abandonner leur père, il les adopte puisqu'il a le PID 1.
Et si systemd a une faille, tout le système est compromis. C'est bien ce truc... -- Aimer, c'est trouver sa richesse hors de soi. -+- Émile Chartier, dit Alain (1868-1951), Éléments de philosophie -+-
Doug713705
Le 16-10-2016, Jo Engo nous expliquait dans fr.comp.os.linux.debats () :
Le Sun, 16 Oct 2016 17:24:34 +0000, Nicolas George a écrit :
Avec systemd, c'est systemd lui-même qui lance les différents services. Et pour les services qui s'acharnent à abandonner leur père, il les adopte puisqu'il a le PID 1.
Et si systemd a une faille, tout le système est compromis. C'est bien ce truc...
Ce n'est pas possible, il n'y a que des dieux qui codent systemd. Ils sont tellement balaises qu'ils ont un accès 999 sur le repo parce que 777 c'était trop petit pour leur melon ;-) -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 16-10-2016, Jo Engo nous expliquait dans
fr.comp.os.linux.debats
(<pan.2016.10.16.18.55.30@icite.fr>) :
Le Sun, 16 Oct 2016 17:24:34 +0000, Nicolas George a écrit :
Avec systemd, c'est systemd lui-même qui lance les différents services.
Et pour les services qui s'acharnent à abandonner leur père, il les
adopte puisqu'il a le PID 1.
Et si systemd a une faille, tout le système est compromis. C'est bien ce
truc...
Ce n'est pas possible, il n'y a que des dieux qui codent systemd.
Ils sont tellement balaises qu'ils ont un accès 999 sur le repo parce
que 777 c'était trop petit pour leur melon ;-)
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 16-10-2016, Jo Engo nous expliquait dans fr.comp.os.linux.debats () :
Le Sun, 16 Oct 2016 17:24:34 +0000, Nicolas George a écrit :
Avec systemd, c'est systemd lui-même qui lance les différents services. Et pour les services qui s'acharnent à abandonner leur père, il les adopte puisqu'il a le PID 1.
Et si systemd a une faille, tout le système est compromis. C'est bien ce truc...
Ce n'est pas possible, il n'y a que des dieux qui codent systemd. Ils sont tellement balaises qu'ils ont un accès 999 sur le repo parce que 777 c'était trop petit pour leur melon ;-) -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Nicolas George
Doug713705 , dans le message <nu0hh7$4r4$, a écrit :
Non mais je parlais du PID mais c'est loin d'être le seul test à faire pour vérifier l'état d'un service. C'est même probablement le moins fiable !
Mais tu rates l'essentiel : l'état d'un service devrait être connu sans qu'il y ait besoin de le vérifier. Bien sûr, si on veut une fiabilité aussi complète que possible, il faut aussi un watchdog pour vérifier que le service répond effectivement ce qu'il est censé répondre, mais c'est assez coûteux. Et de toutes façons, la première brique d'un système fiable, c'est de ne pas laisser les services suspendus dans le vide sans personne pour savoir ce qu'ils deviennent.
Doug713705 , dans le message <nu0hh7$4r4$3@golgoth99.redatomik.org>, a
écrit :
Non mais je parlais du PID mais c'est loin d'être le seul test à faire
pour vérifier l'état d'un service. C'est même probablement le moins
fiable !
Mais tu rates l'essentiel : l'état d'un service devrait être connu sans
qu'il y ait besoin de le vérifier.
Bien sûr, si on veut une fiabilité aussi complète que possible, il faut
aussi un watchdog pour vérifier que le service répond effectivement ce qu'il
est censé répondre, mais c'est assez coûteux. Et de toutes façons, la
première brique d'un système fiable, c'est de ne pas laisser les services
suspendus dans le vide sans personne pour savoir ce qu'ils deviennent.
Doug713705 , dans le message <nu0hh7$4r4$, a écrit :
Non mais je parlais du PID mais c'est loin d'être le seul test à faire pour vérifier l'état d'un service. C'est même probablement le moins fiable !
Mais tu rates l'essentiel : l'état d'un service devrait être connu sans qu'il y ait besoin de le vérifier. Bien sûr, si on veut une fiabilité aussi complète que possible, il faut aussi un watchdog pour vérifier que le service répond effectivement ce qu'il est censé répondre, mais c'est assez coûteux. Et de toutes façons, la première brique d'un système fiable, c'est de ne pas laisser les services suspendus dans le vide sans personne pour savoir ce qu'ils deviennent.
David Sarella
le 2016-10-16, S.T. a plope ceci:
Si un process meurt, aucun autre process ne va prendre son PID avant des heures
mmmm, j'ai comme un doute, la... -- x______o_______o_______o_______o_______o_______o_______o_______o_______x [ ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
le 2016-10-16, S.T. a plope ceci:
Si un process meurt, aucun autre process ne va prendre son PID avant des
heures
Si un process meurt, aucun autre process ne va prendre son PID avant des heures
mmmm, j'ai comme un doute, la... -- x______o_______o_______o_______o_______o_______o_______o_______o_______x [ ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
S.T.
On 2016-10-16, Nicolas George <nicolas$ wrote:
Bien sûr, si on veut une fiabilité aussi complète que possible, il faut aussi un watchdog pour vérifier que le service répond effectivement ce qu'il est censé répondre, mais c'est assez coûteux. Et de toutes façons, la première brique d'un système fiable, c'est de ne pas laisser les services suspendus dans le vide sans personne pour savoir ce qu'ils deviennent.
C'est une condition nécessaire mais très très loin d'être suffisante et c'est, qui plus est, une condition extrèmement simple à remplir avec n'importe quel système de monitoring. Ce que systemd n'est pas. D'ailleurs, qu'attend-t-on de systemd ? qu'il redémarre les process qui sont tombés et interferent avec un système de monitoring sérieux ? Dans mon expérience, un process qui est tombé va retomber, parfois 3 secondes plus tard, parfois 3 minutes ou 3 jours. Que doit faire systemd en fonction de quel programme ? comment sait-il ce qu'il est bon de faire ?
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
Bien sûr, si on veut une fiabilité aussi complète que possible, il faut
aussi un watchdog pour vérifier que le service répond effectivement ce qu'il
est censé répondre, mais c'est assez coûteux. Et de toutes façons, la
première brique d'un système fiable, c'est de ne pas laisser les services
suspendus dans le vide sans personne pour savoir ce qu'ils deviennent.
C'est une condition nécessaire mais très très loin d'être suffisante et
c'est, qui plus est, une condition extrèmement simple à remplir avec
n'importe quel système de monitoring. Ce que systemd n'est pas.
D'ailleurs, qu'attend-t-on de systemd ? qu'il redémarre les process qui
sont tombés et interferent avec un système de monitoring sérieux ?
Dans mon expérience, un process qui est tombé va retomber, parfois 3
secondes plus tard, parfois 3 minutes ou 3 jours. Que doit faire systemd
en fonction de quel programme ? comment sait-il ce qu'il est bon de
faire ?
Bien sûr, si on veut une fiabilité aussi complète que possible, il faut aussi un watchdog pour vérifier que le service répond effectivement ce qu'il est censé répondre, mais c'est assez coûteux. Et de toutes façons, la première brique d'un système fiable, c'est de ne pas laisser les services suspendus dans le vide sans personne pour savoir ce qu'ils deviennent.
C'est une condition nécessaire mais très très loin d'être suffisante et c'est, qui plus est, une condition extrèmement simple à remplir avec n'importe quel système de monitoring. Ce que systemd n'est pas. D'ailleurs, qu'attend-t-on de systemd ? qu'il redémarre les process qui sont tombés et interferent avec un système de monitoring sérieux ? Dans mon expérience, un process qui est tombé va retomber, parfois 3 secondes plus tard, parfois 3 minutes ou 3 jours. Que doit faire systemd en fonction de quel programme ? comment sait-il ce qu'il est bon de faire ?
