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).
Fcold c'est que des bobos qui veulent nous empêcher de kiffer la vibes avec notre GUI.
Tu fais ce que tu veux avec ton GUI, ça ne pose aucun problème aux bobo de fcold. Perso, mon GUI, c'est FVWM et xterm, le tout avec la même conf depuis près de 20 ans et je la kiffe aussi. Donc tu vois qu'il y a aucun problème.
On 2016-10-15, The Mover <the.mover@bsdmail.invalid> wrote:
Fcold c'est que des bobos qui veulent nous empêcher de kiffer la vibes avec
notre GUI.
Tu fais ce que tu veux avec ton GUI, ça ne pose aucun problème aux bobo
de fcold.
Perso, mon GUI, c'est FVWM et xterm, le tout avec la même conf depuis
près de 20 ans et je la kiffe aussi. Donc tu vois qu'il y a aucun
problème.
Fcold c'est que des bobos qui veulent nous empêcher de kiffer la vibes avec notre GUI.
Tu fais ce que tu veux avec ton GUI, ça ne pose aucun problème aux bobo de fcold. Perso, mon GUI, c'est FVWM et xterm, le tout avec la même conf depuis près de 20 ans et je la kiffe aussi. Donc tu vois qu'il y a aucun problème.
Yliur
Le 15 Oct 2016 12:46:46 GMT Nicolas George <nicolas$ a écrit :
Exactement. On peut construire un immeuble branlant en briques, mais un immeuble solide en paille non.
Maintenant si ;) <http://www.toutvert.fr/constructions-en-paille-pour-les-immeubles-aussi/> Sans prendre parti pour ou contre systemd, pour le peu que j'en fais ça marche...
Le 15 Oct 2016 12:46:46 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
Exactement. On peut construire un immeuble branlant en briques, mais
un immeuble solide en paille non.
Maintenant si ;)
<http://www.toutvert.fr/constructions-en-paille-pour-les-immeubles-aussi/>
Sans prendre parti pour ou contre systemd, pour le peu que j'en fais ça
marche...
Le 15 Oct 2016 12:46:46 GMT Nicolas George <nicolas$ a écrit :
Exactement. On peut construire un immeuble branlant en briques, mais un immeuble solide en paille non.
Maintenant si ;) <http://www.toutvert.fr/constructions-en-paille-pour-les-immeubles-aussi/> Sans prendre parti pour ou contre systemd, pour le peu que j'en fais ça marche...
The Mover
S.T. a écrit :
la même conf depuis près de 20 ans et je la kiffe aussi.
Xp Sp 2 ? -- https://www.youtube.com/watch?vÈaFcHFu8QM
S.T. a écrit :
la même conf depuis près de 20 ans et je la kiffe aussi.
la même conf depuis près de 20 ans et je la kiffe aussi.
Xp Sp 2 ? -- https://www.youtube.com/watch?vÈaFcHFu8QM
David Sarella
le 2016-10-15, Doug713705 a plope ceci:
écrit :
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.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
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. -- x______o_______o_______o_______o_______o_______o_______o_______o_______x [ ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
le 2016-10-15, Doug713705 a plope ceci:
écrit :
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.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
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.
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.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
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. -- x______o_______o_______o_______o_______o_______o_______o_______o_______x [ ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jo Engo
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. -- L'ennui est la seule chose horrible en ce monde. C'est le seul péché pour lequel il n'existe pas de pardon. -+- Oscar Wilde -+-
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.
--
L'ennui est la seule chose horrible en ce monde.
C'est le seul péché pour lequel il n'existe pas de pardon.
-+- Oscar Wilde -+-
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. -- L'ennui est la seule chose horrible en ce monde. C'est le seul péché pour lequel il n'existe pas de pardon. -+- Oscar Wilde -+-
Nicolas George
Jo Engo , dans le message , a écrit :
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.
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.
Jo Engo , dans le message <pan.2016.10.16.12.48.41@icite.fr>, a écrit :
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.
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.
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.
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.
Jo Engo
Le Sun, 16 Oct 2016 15:42:32 +0000, Nicolas George a écrit :
Quand le daemon meurt, l'enregistrement du PID n'est pas automatiquement supprimé,
Comportement pathologique ou comportement normal ?
et bientôt le PID est réutilisé pour un autre processus. Bang.
Ah pas con. le pid réaffecté. Et comment on pallie à ça et pourquoi pas avec un script ? -- cuvez wons marx : c'est un comble : Karl qui incite à thésauriser ! -- Zalmanski, Alain
Le Sun, 16 Oct 2016 15:42:32 +0000, Nicolas George a écrit :
Quand le daemon meurt, l'enregistrement du PID n'est pas automatiquement
supprimé,
Comportement pathologique ou comportement normal ?
et bientôt le PID est réutilisé pour un autre processus. Bang.
Ah pas con. le pid réaffecté. Et comment on pallie à ça et pourquoi pas
avec un script ?
--
cuvez wons marx : c'est un comble : Karl qui incite à thésauriser !
-- Zalmanski, Alain
Le Sun, 16 Oct 2016 15:42:32 +0000, Nicolas George a écrit :
Quand le daemon meurt, l'enregistrement du PID n'est pas automatiquement supprimé,
Comportement pathologique ou comportement normal ?
et bientôt le PID est réutilisé pour un autre processus. Bang.
Ah pas con. le pid réaffecté. Et comment on pallie à ça et pourquoi pas avec un script ? -- cuvez wons marx : c'est un comble : Karl qui incite à thésauriser ! -- Zalmanski, Alain
S.T.
On 2016-10-16, Nicolas George <nicolas$ 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.
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.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> 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.
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.
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.
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.
Nicolas George
"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é. Si ça arrive suite à des manoeuvres malicieuses, ton raisonnement ne vaut rien.
"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é.
Si ça arrive suite à des manoeuvres malicieuses, ton raisonnement ne vaut
rien.
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é. Si ça arrive suite à des manoeuvres malicieuses, ton raisonnement ne vaut rien.
Nicolas George
Jo Engo , dans le message , a écrit :
Comportement pathologique ou comportement normal ?
Qui effacerait le fichier de PID ?
Et comment on pallie à ça
En faisant en sorte que le processus père garde la trace, car lui, et lui seul, est notifié de la mort du processus et chargé de la finaliser.
Jo Engo , dans le message <pan.2016.10.16.15.58.56@icite.fr>, a écrit :
Comportement pathologique ou comportement normal ?
Qui effacerait le fichier de PID ?
Et comment on pallie à ça
En faisant en sorte que le processus père garde la trace, car lui, et lui
seul, est notifié de la mort du processus et chargé de la finaliser.
