cerhu > comp.os.* > comp.os.linux.debats

Nicolas George (25/10/2016, 11h17)
JKB , dans le message <slrno0s4cg.iu9.jkb>, a
écrit :
> Avec systemd, c'est largement rigologène. Parce que tu ne surcharges
> pas une variable. Tu es contraint de surcharger l'ensemble du
> fichier de description du daemon.


Voilà encore une preuve supplémentaire : les détracteurs les plus virulents
de systemd déversent leur haine sans savoir réellement de quoi ils parlent :

[..]

(La doc officielle serait :
[..]
mais comme elle est rédigée comme une page de man, pas possible de faire un
lien interne.)
Nicolas George (25/10/2016, 11h18)
Doug713705 , dans le message <numt0o$rog$1>, a
écrit :
> Ça s'appelle créer le besoin.


Tu peux préciser ta pensée ? Tu n'es pas en train de suggérer que les
différentes distributions ont transformé leurs scripts d'init en spaghettis
exprès pour paver la voie pour systemd, par hasard ?
remy (25/10/2016, 15h28)
Le 20/10/2016 14:54, Nicolas George a écrit :
[..]
>256a34cc>,
> a écrit :
> En effet, la mauvaise foi est absolument évidente.
>> Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il

> ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
> est optionnel.

tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe

remy
JKB (25/10/2016, 15h48)
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy> écrivait :
> Le 20/10/2016 14:54, Nicolas George a écrit :
> tien le retour des vieux con(présent)
> tu peux m'explique comme tu monitoring de manier automatique
> un daemon avec rc.init un truc du style redémarrage automatique si le
> daemon tombe


Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.

Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.

JKB
remy (25/10/2016, 16h37)
Le 25/10/2016 15:48, JKB a écrit :
> Le Tue, 25 Oct 2016 15:28:58 +0200,
> remy <remy> écrivait :
> Un daemon qui explose en vol n'a pas à redémarrer tout seul.C'est
> un dysfonctionnement qu'il faut traiter.
> Sinon, je connais des petits rigolos qui contrôlent la bonne
> exécution des daemons avec des crons, mais je trouve ça complètement
> idiot. La solution est de trouver pourquoi il explose et de corriger
> le problème en amont. Mais pour cela, il faut rester dans la
> philosophie KISS.


il existe Strace mais les log sont imbitable comme dab d?ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière

remy
JKB (25/10/2016, 16h48)
Le Tue, 25 Oct 2016 16:37:14 +0200,
remy <remy> écrivait :
> Le 25/10/2016 15:48, JKB a écrit :
> il existe Strace mais les log sont imbitable comme dab d?ailleurs
> désoler mais la plupart du temps ont préfère attendre la version
> suivante du bouzin pas stable mais indispensable
> et donc ma question reste entière


Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.

JKB
remy (25/10/2016, 16h58)
Le 25/10/2016 16:48, JKB a écrit :
> Le Tue, 25 Oct 2016 16:37:14 +0200,
> remy <remy> écrivait :
> Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
> pourquoi ce n'est pas souhaitable.
> JKB

tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
JKB (25/10/2016, 17h04)
Le Tue, 25 Oct 2016 16:58:16 +0200,
remy <remy> écrivait :
> Le 25/10/2016 16:48, JKB a écrit :
> tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
> remy


Relis-moi bien attentivement. Je ne te répondrai pas avant que aies
lu et compris.

Au fait, le chiffrement, ça en est où ?

JKB
remy (25/10/2016, 17h41)
Le 25/10/2016 17:04, JKB a écrit :
> Le Tue, 25 Oct 2016 16:58:16 +0200,
> remy <remy> écrivait :
> Relis-moi bien attentivement. Je ne te répondrai pas avant que aies
> lu et compris.
> Au fait, le chiffrement, ça en est où ?


il faut que je mette en musique ma relation voir

[..]

et je recherche une éventuelle antériorité si elle existe
j'ai pas trouver grand chose voir carrément rien

sinon j'avais un truc mais j'ai pas réussie a le simplifier assez pour
que cela soit compris cetait a partir des equations diophantine et de
l?unicité de la parti décimal des racine ieme dans toutles cas ses pas
très grave
JKB (25/10/2016, 17h54)
Le Tue, 25 Oct 2016 17:41:24 +0200,
remy <remy> écrivait :
> Le 25/10/2016 17:04, JKB a écrit :
> il faut que je mette en musique ma relation voir
> [..]
> et je recherche une éventuelle antériorité si elle existe
> j'ai pas trouver grand chose voir carrément rien


Tu m'étonnes. J'en rigole par avance. Reviens un peu sur fsm,
histoire de changer des élucubrations des poètes de service.

> sinon j'avais un truc mais j'ai pas réussie a le simplifier assez pour
> que cela soit compris cetait a partir des equations diophantine et de
> l?unicité de la parti décimal des racine ieme dans tout les cas ses pas
> très grave


...

JKB
S.T. (25/10/2016, 18h33)
On 2016-10-25, JKB <jkb> wrote:

> Sinon, je connais des petits rigolos qui contrôlent la bonne
> exécution des daemons avec des crons, mais je trouve ça complètement
> idiot. La solution est de trouver pourquoi il explose et de corriger
> le problème en amont. Mais pour cela, il faut rester dans la
> philosophie KISS.


Oui, enfin il y a des systèmes de monitoring aussi.
JKB (25/10/2016, 19h56)
Le Tue, 25 Oct 2016 16:33:10 +0000 (UTC),
S.T. <pffff> écrivait :
> On 2016-10-25, JKB <jkb> wrote:
>> Sinon, je connais des petits rigolos qui contrôlent la bonne
>> exécution des daemons avec des crons, mais je trouve ça complètement
>> idiot. La solution est de trouver pourquoi il explose et de corriger
>> le problème en amont. Mais pour cela, il faut rester dans la
>> philosophie KISS.

> Oui, enfin il y a des systèmes de monitoring aussi.


Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...

JKB
S.T. (25/10/2016, 20h11)
On 2016-10-25, JKB <jkb> wrote:
> Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
> hein...


Justement, on pourrait expliquer à Rémy que lorsque systemd monitore des
process de démons et les relance lorsqu'ils plantent, cela va provoquer
indéniablement une diminution de la qualité des programmes sous Linux
(puisque ça se relance tout seul, pourquoi les faire stables), mais que
lorsqu'un système de monitoring (type Nagios) relance un process après
avoir levé une alerte, envoyé un email et un sms à un administrateur
système, il s'agit alors d'assurer une continuité du service tout en
prévenant les personnes concernées de prendre action afin que le
problème ne se représente pas.

Monitorer avec cron est une stupidité, mais un poil moins qu'avec
systemd, parce qu'un daemon peut planter à l'occasion sans que
l'administrateur ai la possibilité d'y changer quoi que ce soit (cas non
reproductible, code proprio ...), cron apporte alors une réactivité que
Nagios n'a pas et peut rendre service si on reste dans un contexte
d'exception et non de règle.

Rémy, t'as compris ?
Doug713705 (25/10/2016, 21h15)
Le 25-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<580f2375$0$5276$426a74cc>) :

> Doug713705 , dans le message <numt0o$rog$1>, a
> écrit :
>> Ça s'appelle créer le besoin.

> Tu peux préciser ta pensée ? Tu n'es pas en train de suggérer que les
> différentes distributions ont transformé leurs scripts d'init en spaghettis
> exprès pour paver la voie pour systemd, par hasard ?


C'est très exactement ce que je suis en train d'exprimer, c'est évidement
un troll mais l'exemple proposé par Kevin Denis est une démonstration
parfaite de l'abrutissement total de certains dev et aujourd'hui on
vient dire "init est trop complexe et peu fiable, il faut autre chose".

Allo, les gars, c'est *VOUS* qui avez mis la grouille partout dans un
truc qui se voulait simple.

Il y a un moment où il faut savoir se regarder dans la glace est se dire
qu'on s'est trompé. Ça n'a pas l'air évident pour tout le monde...

286 lignes de codes (hors scripts externes) pour démarrer Apache, c'est
juste du grand n'importe quoi qui ne peut *pas* être justifié. C'est
juste de la merde, il n'y a pas d'autre mot possible.

Coup de bol, c'est de la merde qui tombe en marche, on est sauvé !
Nicolas George (25/10/2016, 21h40)
Doug713705 , dans le message <nuob0s$juc$1>, a
écrit :
> C'est très exactement ce que je suis en train d'exprimer, c'est évidement
> un troll mais l'exemple proposé par Kevin Denis est une démonstration
> parfaite de l'abrutissement total de certains dev et aujourd'hui on
> vient dire "init est trop complexe et peu fiable, il faut autre chose".
> Allo, les gars, c'est *VOUS* qui avez mis la grouille partout dans un
> truc qui se voulait simple.
> Il y a un moment où il faut savoir se regarder dans la glace est se dire
> qu'on s'est trompé. Ça n'a pas l'air évident pour tout le monde...
> 286 lignes de codes (hors scripts externes) pour démarrer Apache, c'est
> juste du grand n'importe quoi qui ne peut *pas* être justifié. C'est
> juste de la merde, il n'y a pas d'autre mot possible.


Figure-toi que chacune de ces lignes est nécessaire pour quelque chose. La
politique de Slackware est de laisser l'utilisateur se débrouiller ; ça te
convient, tant mieux. La politique de Debian, et de beaucoup d'autres, est
de fournir quelque chose qui marche autant que possible dans tous les cas,
et pour ça, c'est bête, mais il faut les gérer, tous les cas, et ça exige du
code, beaucoup de code.

Toutes les lignes ne servent pas à tout le monde, mais chaque ligne sert au
moins à une personne.

Et c'est valable pour le reste : la complexité n'est pas gratuite, elle
vient des tâches de plus en plus complexes qu'on demande à un ordinateur. Il
y a vingt ans, on avait un lecteur de disquettes, il apparaissait comme
/dev/fd0, et /etc/fstab autorisait à le monter en VFAT. De nos jours, on a
des machins USB qui peuvent être branchés et débranchés à n'importe quel
moment, qui peuvent être branchés plusieurs à la fois ou faire apparaître
plusieurs cibles, qui peuvent être formatés en exFAT ou en HFS+ et qu'il
faut pouvoir monter, si possible sans ouvrir de trou de sécurité béant.

Discussions similaires
systemd et fichiers dans /etc/init.d/

systemd-shim et systemd-sysv

Systemd et scripts /etc/init.d/.

systemd sera l'init par défaut de Jessie


Fuseau horaire GMT +2. Il est actuellement 01h48. | Privacy Policy