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).
Si un process meurt, aucun autre process ne va prendre son PID avant des heures
mmmm, j'ai comme un doute, la...
Avec 32768 PID disponibles par défaut, si tu as un doute, tu changes la valeur max pour 2^22, tu tues ton sendmail et tu regardes combien de temps avant qu'un autre process persistant reprenne le même PID. Si tu n'es pas mort de vieillesse avant que cela n'arrive, tu nous préviens.
On 2016-10-17, David Sarella <oldchap@remote.cispeo.fr> wrote:
Si un process meurt, aucun autre process ne va prendre son PID avant des
heures
mmmm, j'ai comme un doute, la...
Avec 32768 PID disponibles par défaut, si tu as un doute, tu changes la
valeur max pour 2^22, tu tues ton sendmail et tu regardes combien de
temps avant qu'un autre process persistant reprenne le même PID. Si tu
n'es pas mort de vieillesse avant que cela n'arrive, tu nous préviens.
Si un process meurt, aucun autre process ne va prendre son PID avant des heures
mmmm, j'ai comme un doute, la...
Avec 32768 PID disponibles par défaut, si tu as un doute, tu changes la valeur max pour 2^22, tu tues ton sendmail et tu regardes combien de temps avant qu'un autre process persistant reprenne le même PID. Si tu n'es pas mort de vieillesse avant que cela n'arrive, tu nous préviens.
Nicolas George
David Sarella , dans le message , a écrit :
mmmm, j'ai comme un doute, la...
Tu as raison, il se plante.
David Sarella , dans le message <npmddd-ho.ln1@ds23.cispeo.fr>, a
écrit :
Quand le daemon meurt, l'enregistrement du PID n'est pas automatiquement supprimé, et bientôt le PID est réutilisé pour un autre processus. Bang.
Dans ce cas, pourquoi ne pas enregistrer le PID et la date de création du service (et en calculer le condensat numérique au passage) ? Cordialement Dominique
Bonjour,
Nicolas George wrote:
Quand le daemon meurt, l'enregistrement du PID n'est pas automatiquement
supprimé, et bientôt le PID est réutilisé pour un autre processus. Bang.
Dans ce cas, pourquoi ne pas enregistrer le PID et la date de création du
service (et en calculer le condensat numérique au passage) ?
Quand le daemon meurt, l'enregistrement du PID n'est pas automatiquement supprimé, et bientôt le PID est réutilisé pour un autre processus. Bang.
Dans ce cas, pourquoi ne pas enregistrer le PID et la date de création du service (et en calculer le condensat numérique au passage) ? Cordialement Dominique
S.T.
On 2016-10-17, Nicolas George <nicolas$ wrote:
mmmm, j'ai comme un doute, la...
Tu as raison, il se plante.
C'est bien pour cela que tu es incapable d'expliquer en quoi je me plante.
On 2016-10-17, Nicolas George <nicolas$george@salle-s.org> wrote:
mmmm, j'ai comme un doute, la...
Tu as raison, il se plante.
C'est bien pour cela que tu es incapable d'expliquer en quoi je me
plante.
C'est bien pour cela que tu es incapable d'expliquer en quoi je me plante.
JKB
Le Fri, 14 Oct 2016 21:04:11 +0000 (UTC), Doug713705 écrivait :
Le 14-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5800f38d$0$7106$) :
JKB , dans le message , a écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut aller la mauvaise foi des fanatiques.
Faire planter != Empécher de demarrer Et franchement, un script d'init qui empèche un service de démarrer Ok, mais qui empèche le serveur de démarrer, je n'ai jamais vu. Par contre les bugs de systemd sont trop nombreux pour les lister tous ici et ça c'est un _fait_.
Non, non, non, NG te l'a dit, ça n'existe pas. Homme de peu de foi !
Après ça marchouille, il ne faut pas dire que ça ne fonctionne pas du tout. Ici j'ai des centaines de VMs sous CentOS7 sur lesquelles systemd ne pose pas de problème mais il faut dire que chaque VM ne propose gnéralement qu'un seul service bien précis, genre reverse-proxy, serveur http, et autres trucs moches "professionnels" (comprendre vendus une fortune par des grosses boites américaines) en Java (en plus des qques services systeme genre snmp).
Moi, j'ai un effet de bord rigolo récent avec systemd et des bornes client biécran. Lorsque X est lancé par systemd, aléatoirement, l'un des deux écrans n'est pas reconnu. En lançant X à la main, les deux sont _toujours_ reconnus. J'ai donc écrit un script lancé par systemd qui vérifie que xrandr renvoie bien les deux sorties écrans pour redémarrer X. systemd empêche donc le vieillissement du cerveau par lutte contre l'inaction scélorante des neurones. Il faut au moins lui reconnaître ça.
Ceci dit, j'ai déjà vu des units systemd ne plus savoir où ils en sont et te raconter que le service est demarré quand ce n'est pas le cas ou être incapables de demarrer un service.
J'ai aussi vu des trucs amusants avec des services incapables de démarrer lors du boot, mais démarrant parfaitement à la main. Et pour couper l'herbe à NG, ces services étaient parfaitement bien configurés (et le problème a miraculeusement disparu lors d'une mise à jour de la merde systemd).
Du coup, ça remet pas mal en question le concept qui dit que systemd permet d'avoir une meilleure vue de l'état des services. Soit, si l'unit est écrit avec les pieds, ce n'est pas de la faute de systemd mais cette remarque est également valable pour init. Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service. Et systemd ne pourra pas pallier le codage avec les pieds. L'idée de départ étant érronnée, il y a peu de chance que le projet atteigne son but !
Très certes, cher. Moi, personnellement, ce qui m'amuse le plus (ou me navre), c'est que Linux se Windowise à grands pas. Il y a dix ans, jamais une telle merde n'aurait été introduite dans le système. Linux devait être stable et pérenne. Avec systemd, on est dans le grand n'importe quoi. Et je ne vois toujours pas ce que ça apporte au système (la gestion des cgroups n'est pas un argument car on pourrait tout à fait faire la même chose avec un init classique, d'autant plus que je ne vois toujours pas à quoi sert un cgroup lorsqu'on a un système d'initialisation bien fichu). JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Fri, 14 Oct 2016 21:04:11 +0000 (UTC),
Doug713705 <doug.letough@free.fr> écrivait :
Le 14-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5800f38d$0$7106$426a74cc@news.free.fr>) :
JKB , dans le message <slrno01ftn.vjd.jkb@rayleigh.systella.fr>, a
écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce
que le nombre de fois où un systemd m'a planté un serveur ne se
compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça
n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut
aller la mauvaise foi des fanatiques.
Faire planter != Empécher de demarrer
Et franchement, un script d'init qui empèche un service de démarrer Ok,
mais qui empèche le serveur de démarrer, je n'ai jamais vu.
Par contre les bugs de systemd sont trop nombreux pour les lister tous
ici et ça c'est un _fait_.
Non, non, non, NG te l'a dit, ça n'existe pas. Homme de peu de foi !
Après ça marchouille, il ne faut pas dire que ça ne fonctionne pas du
tout. Ici j'ai des centaines de VMs sous CentOS7 sur lesquelles systemd
ne pose pas de problème mais il faut dire que chaque VM ne propose
gnéralement qu'un seul service bien précis, genre reverse-proxy, serveur
http, et autres trucs moches "professionnels" (comprendre vendus une
fortune par des grosses boites américaines) en Java (en plus des qques
services systeme genre snmp).
Moi, j'ai un effet de bord rigolo récent avec systemd et des bornes client
biécran. Lorsque X est lancé par systemd, aléatoirement, l'un des
deux écrans n'est pas reconnu. En lançant X à la main, les deux sont
_toujours_ reconnus. J'ai donc écrit un script lancé par systemd qui
vérifie que xrandr renvoie bien les deux sorties écrans pour
redémarrer X. systemd empêche donc le vieillissement du cerveau par
lutte contre l'inaction scélorante des neurones. Il faut au moins
lui reconnaître ça.
Ceci dit, j'ai déjà vu des units systemd ne plus savoir où ils en sont
et te raconter que le service est demarré quand ce n'est pas le cas ou être
incapables de demarrer un service.
J'ai aussi vu des trucs amusants avec des services incapables de
démarrer lors du boot, mais démarrant parfaitement à la main. Et
pour couper l'herbe à NG, ces services étaient parfaitement bien
configurés (et le problème a miraculeusement disparu lors d'une mise
à jour de la merde systemd).
Du coup, ça remet pas mal en question le concept qui dit que systemd
permet d'avoir une meilleure vue de l'état des services.
Soit, si l'unit est écrit avec les pieds, ce n'est pas de la faute de
systemd mais cette remarque est également valable pour init.
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit
pas capable de bien décrire le status d'un service.
Et systemd ne pourra pas pallier le codage avec les pieds. L'idée de
départ étant érronnée, il y a peu de chance que le projet atteigne son
but !
Très certes, cher.
Moi, personnellement, ce qui m'amuse le plus (ou me navre), c'est
que Linux se Windowise à grands pas. Il y a dix ans, jamais une telle merde
n'aurait été introduite dans le système. Linux devait être stable et
pérenne. Avec systemd, on est dans le grand n'importe quoi.
Et je ne vois toujours pas ce que ça apporte au système (la gestion
des cgroups n'est pas un argument car on pourrait tout à fait faire
la même chose avec un init classique, d'autant plus que je ne vois
toujours pas à quoi sert un cgroup lorsqu'on a un système
d'initialisation bien fichu).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Fri, 14 Oct 2016 21:04:11 +0000 (UTC), Doug713705 écrivait :
Le 14-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5800f38d$0$7106$) :
JKB , dans le message , a écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut aller la mauvaise foi des fanatiques.
Faire planter != Empécher de demarrer Et franchement, un script d'init qui empèche un service de démarrer Ok, mais qui empèche le serveur de démarrer, je n'ai jamais vu. Par contre les bugs de systemd sont trop nombreux pour les lister tous ici et ça c'est un _fait_.
Non, non, non, NG te l'a dit, ça n'existe pas. Homme de peu de foi !
Après ça marchouille, il ne faut pas dire que ça ne fonctionne pas du tout. Ici j'ai des centaines de VMs sous CentOS7 sur lesquelles systemd ne pose pas de problème mais il faut dire que chaque VM ne propose gnéralement qu'un seul service bien précis, genre reverse-proxy, serveur http, et autres trucs moches "professionnels" (comprendre vendus une fortune par des grosses boites américaines) en Java (en plus des qques services systeme genre snmp).
Moi, j'ai un effet de bord rigolo récent avec systemd et des bornes client biécran. Lorsque X est lancé par systemd, aléatoirement, l'un des deux écrans n'est pas reconnu. En lançant X à la main, les deux sont _toujours_ reconnus. J'ai donc écrit un script lancé par systemd qui vérifie que xrandr renvoie bien les deux sorties écrans pour redémarrer X. systemd empêche donc le vieillissement du cerveau par lutte contre l'inaction scélorante des neurones. Il faut au moins lui reconnaître ça.
Ceci dit, j'ai déjà vu des units systemd ne plus savoir où ils en sont et te raconter que le service est demarré quand ce n'est pas le cas ou être incapables de demarrer un service.
J'ai aussi vu des trucs amusants avec des services incapables de démarrer lors du boot, mais démarrant parfaitement à la main. Et pour couper l'herbe à NG, ces services étaient parfaitement bien configurés (et le problème a miraculeusement disparu lors d'une mise à jour de la merde systemd).
Du coup, ça remet pas mal en question le concept qui dit que systemd permet d'avoir une meilleure vue de l'état des services. Soit, si l'unit est écrit avec les pieds, ce n'est pas de la faute de systemd mais cette remarque est également valable pour init. Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service. Et systemd ne pourra pas pallier le codage avec les pieds. L'idée de départ étant érronnée, il y a peu de chance que le projet atteigne son but !
Très certes, cher. Moi, personnellement, ce qui m'amuse le plus (ou me navre), c'est que Linux se Windowise à grands pas. Il y a dix ans, jamais une telle merde n'aurait été introduite dans le système. Linux devait être stable et pérenne. Avec systemd, on est dans le grand n'importe quoi. Et je ne vois toujours pas ce que ça apporte au système (la gestion des cgroups n'est pas un argument car on pourrait tout à fait faire la même chose avec un init classique, d'autant plus que je ne vois toujours pas à quoi sert un cgroup lorsqu'on a un système d'initialisation bien fichu). JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
JKB
Le 16 Oct 2016 12:48:41 GMT, Jo Engo écrivait :
Le Sun, 16 Oct 2016 12:11:02 +0200, David Sarella a écrit :
Parce que d'après toi il n'est pas possible de retrouver les PID des processus liés à un service, ni de vérifier si ces processus sont toujours actifs ou non ?
c'est parfois tres difficile, il faut le reconnaitre.
C'est au moment où on lance le démon qu'on enregistre son pid, ainsi il est connu et ce n'est pas difficile. J'aierais voir des cas où ce procédé faile.
Si l'utilisateur efface le fichier ? Mais on ne peut rien contre la bêtise humaine. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le 16 Oct 2016 12:48:41 GMT,
Jo Engo <yl@icite.fr> écrivait :
Le Sun, 16 Oct 2016 12:11:02 +0200, David Sarella a écrit :
Parce que d'après toi il n'est pas possible de retrouver les PID des
processus liés à un service, ni de vérifier si ces processus sont
toujours actifs ou non ?
c'est parfois tres difficile, il faut le reconnaitre.
C'est au moment où on lance le démon qu'on enregistre son pid, ainsi il
est connu et ce n'est pas difficile. J'aierais voir des cas où ce procédé
faile.
Si l'utilisateur efface le fichier ? Mais on ne peut rien contre la
bêtise humaine.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sun, 16 Oct 2016 12:11:02 +0200, David Sarella a écrit :
Parce que d'après toi il n'est pas possible de retrouver les PID des processus liés à un service, ni de vérifier si ces processus sont toujours actifs ou non ?
c'est parfois tres difficile, il faut le reconnaitre.
C'est au moment où on lance le démon qu'on enregistre son pid, ainsi il est connu et ce n'est pas difficile. J'aierais voir des cas où ce procédé faile.
Si l'utilisateur efface le fichier ? Mais on ne peut rien contre la bêtise humaine. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
JKB
Le Sun, 16 Oct 2016 18:26:32 +0000 (UTC), S.T. écrivait :
On 2016-10-16, Nicolas George <nicolas$ 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.
Ehoh ! Tu parles de mecs qui ne sont jamais en face de cas pratiques à un autre mec jamais en face de cas pratiques. Que veux-tu qu'il y pige ? JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Sun, 16 Oct 2016 18:26:32 +0000 (UTC),
S.T. <pffff@toutunehistoire.com> écrivait :
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.
Ehoh ! Tu parles de mecs qui ne sont jamais en face de cas pratiques
à un autre mec jamais en face de cas pratiques. Que veux-tu qu'il y
pige ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sun, 16 Oct 2016 18:26:32 +0000 (UTC), S.T. écrivait :
On 2016-10-16, Nicolas George <nicolas$ 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.
Ehoh ! Tu parles de mecs qui ne sont jamais en face de cas pratiques à un autre mec jamais en face de cas pratiques. Que veux-tu qu'il y pige ? JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
JKB
Le Mon, 17 Oct 2016 05:48:00 +0000 (UTC), S.T. écrivait :
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 ?
Il sait. C'est tout. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Mon, 17 Oct 2016 05:48:00 +0000 (UTC),
S.T. <pffff@toutunehistoire.com> écrivait :
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 ?
Il sait. C'est tout.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Mon, 17 Oct 2016 05:48:00 +0000 (UTC), S.T. écrivait :
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 ?
Il sait. C'est tout. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Doug713705
Le 17-10-2016, JKB nous expliquait dans fr.comp.os.linux.debats () :
Moi, personnellement, ce qui m'amuse le plus (ou me navre), c'est que Linux se Windowise à grands pas. Il y a dix ans, jamais une telle merde n'aurait été introduite dans le système. Linux devait être stable et pérenne. Avec systemd, on est dans le grand n'importe quoi.
Je ne peux qu'abonder. Et c'est valable pour tout un tas de projets libres, beaucoup autour de RedHat, Fedora et toute la clique à chapeau rouge. Il y aussi la bande de Gnome. Ces gars là tiennent absolument à rendre Linux le moins opérationnel possible. Et quand ils s'associent (j'en connais qui sont dans les deux camps à la fois), je ne te dis pas le massacre idéologique. Ça te piétinne le KISS avec outrecuidance, ça t'accueille à bras ouvert MS sur Linux et Linux dans Windows, ça installe Steam, des trucs horribles... Parfois je me dis que le libre se fait troller en profondeur dans toute sa largeur par des zélotes windowsiens. -- 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 17-10-2016, JKB nous expliquait dans
fr.comp.os.linux.debats
(<slrno08u1j.q7p.jkb@rayleigh.systella.fr>) :
Moi, personnellement, ce qui m'amuse le plus (ou me navre), c'est
que Linux se Windowise à grands pas. Il y a dix ans, jamais une telle merde
n'aurait été introduite dans le système. Linux devait être stable et
pérenne. Avec systemd, on est dans le grand n'importe quoi.
Je ne peux qu'abonder. Et c'est valable pour tout un tas de projets
libres, beaucoup autour de RedHat, Fedora et toute la clique à chapeau
rouge. Il y aussi la bande de Gnome. Ces gars là tiennent absolument à
rendre Linux le moins opérationnel possible. Et quand ils s'associent
(j'en connais qui sont dans les deux camps à la fois), je ne te dis pas
le massacre idéologique. Ça te piétinne le KISS avec outrecuidance, ça
t'accueille à bras ouvert MS sur Linux et Linux dans Windows, ça
installe Steam, des trucs horribles...
Parfois je me dis que le libre se fait troller en profondeur dans toute
sa largeur par des zélotes windowsiens.
--
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 17-10-2016, JKB nous expliquait dans fr.comp.os.linux.debats () :
Moi, personnellement, ce qui m'amuse le plus (ou me navre), c'est que Linux se Windowise à grands pas. Il y a dix ans, jamais une telle merde n'aurait été introduite dans le système. Linux devait être stable et pérenne. Avec systemd, on est dans le grand n'importe quoi.
Je ne peux qu'abonder. Et c'est valable pour tout un tas de projets libres, beaucoup autour de RedHat, Fedora et toute la clique à chapeau rouge. Il y aussi la bande de Gnome. Ces gars là tiennent absolument à rendre Linux le moins opérationnel possible. Et quand ils s'associent (j'en connais qui sont dans les deux camps à la fois), je ne te dis pas le massacre idéologique. Ça te piétinne le KISS avec outrecuidance, ça t'accueille à bras ouvert MS sur Linux et Linux dans Windows, ça installe Steam, des trucs horribles... Parfois je me dis que le libre se fait troller en profondeur dans toute sa largeur par des zélotes windowsiens. -- 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
S.T.
On 2016-10-17, Doug713705 wrote:
Je ne peux qu'abonder. Et c'est valable pour tout un tas de projets libres, beaucoup autour de RedHat, Fedora et toute la clique à chapeau rouge. Il y aussi la bande de Gnome. Ces gars là tiennent absolument à rendre Linux le moins opérationnel possible. Et quand ils s'associent (j'en connais qui sont dans les deux camps à la fois), je ne te dis pas le massacre idéologique. Ça te piétinne le KISS avec outrecuidance, ça t'accueille à bras ouvert MS sur Linux et Linux dans Windows, ça installe Steam, des trucs horribles...
En fait, ça te transforme l'Unixien le plus dur en chevre bêlante de Windows. Il n'y a qu'à voir un NG appeler "service" ce que tout le monde nommait "daemon" ou "démon", à la limite "serveur" auparavant. "Service", c'est bien le mot qu'on utilise sur un serveur Windows.
On 2016-10-17, Doug713705 <doug.letough@free.fr> wrote:
Je ne peux qu'abonder. Et c'est valable pour tout un tas de projets
libres, beaucoup autour de RedHat, Fedora et toute la clique à chapeau
rouge. Il y aussi la bande de Gnome. Ces gars là tiennent absolument à
rendre Linux le moins opérationnel possible. Et quand ils s'associent
(j'en connais qui sont dans les deux camps à la fois), je ne te dis pas
le massacre idéologique. Ça te piétinne le KISS avec outrecuidance, ça
t'accueille à bras ouvert MS sur Linux et Linux dans Windows, ça
installe Steam, des trucs horribles...
En fait, ça te transforme l'Unixien le plus dur en chevre bêlante de
Windows. Il n'y a qu'à voir un NG appeler "service" ce que tout le monde
nommait "daemon" ou "démon", à la limite "serveur" auparavant.
"Service", c'est bien le mot qu'on utilise sur un serveur Windows.
Je ne peux qu'abonder. Et c'est valable pour tout un tas de projets libres, beaucoup autour de RedHat, Fedora et toute la clique à chapeau rouge. Il y aussi la bande de Gnome. Ces gars là tiennent absolument à rendre Linux le moins opérationnel possible. Et quand ils s'associent (j'en connais qui sont dans les deux camps à la fois), je ne te dis pas le massacre idéologique. Ça te piétinne le KISS avec outrecuidance, ça t'accueille à bras ouvert MS sur Linux et Linux dans Windows, ça installe Steam, des trucs horribles...
En fait, ça te transforme l'Unixien le plus dur en chevre bêlante de Windows. Il n'y a qu'à voir un NG appeler "service" ce que tout le monde nommait "daemon" ou "démon", à la limite "serveur" auparavant. "Service", c'est bien le mot qu'on utilise sur un serveur Windows.
