Posté par Kaane .
En réponse au journal udev forké.
Évalué à 1.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
Et moi donc j'apprécierai que tu lises la doc que tu me balances avant de me dire que je suis dans le faux.
Je récapitule pour ce qui ne suivent pas : on a un process qui éventuellement fork et repasse la main à l'init avant de commencer une synchronisation et finalement de lancer le vrai processus.
On va partir du principe que le process ne fork pas pour simplifier le boulot, mais c'est encore pire si il fork
Dès le départ je suis obligé d'aller remplir le PIDFile avec le PID de mon premier élément sinon ca s'arrête et systemd concluera à un echec de lancement.
Ensuite je poursuis ma synchro. Quand ma synchro est finie problème :
Soit j'avais mis RemainAfterExit à TRUE et là je peux fermer mon process de synchro l'esprit tranquille, mais si mon process principal ne se lance pas, ben systemd ne sera jamais mis au courant du fait que ca ne marche pas. Pareil si le process se lance mais meurt par la suite.
Soit j'avais mis RemainAfterExit à FALSE et là c'est le drame parceque je ne peux pas fermer mon processus de synchro avant d'être sur que la mise a jour des PID a bien eu lieu dans systemd. Sauf que je sais pas quand elle a lieu la mise à jour. Donc je boucle en mode texte du systemctl jusqu'à ce que le PID modifié soit pris en compte. (Je ne sais pas si ca a changé, mais en vrai le nouveau PID dans le fichier ne sera jamais pris en compte)
On triche avec ExecStartPre, je lance la moitié de mon script d'init en pre pour la synchro et l'autre moitié en normal.
Problème : si la synchro se foire, l'autre commande n'est jamais executée. Sauf si je mets un - devant ma commande, auquel cas l'autre commande est toujours executée. Sauf que je veux du "des fois oui, des fois non". Donc il faut que j'étoffe mes deux scripts pour que le second script puisse récupérer et analyser les résultats du premier script (BEURK). Donc non seulement j'ai deux scripts à maintenir au lieu d'un, mais en plus j'ai du boilerplate qui vient se rajouter en plus sur l'existant.
Sauf que si le second script plante pendant le démarrage, il n'est pas dit qu'il aura fait le ménage avant que le plantage. Donc un petit troisième script en ExecStartPost pour passer le balais….(que tant qu'à faire je met aussi en ExecStartPre des fois que).
YOUPI trois scripts pour le prix d'un avec du boilerplate en plus…
Ensuite, si le souci, c'est l'orchestration de services sur le réseau
Non le soucis c'est de passer le service dans un état dans lequel il pourra être orchestré par la suite. C'est dire cohérent, synchronisé, stable et avec les bon paramètres de connexion connus.
_Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents _
Non c'est quasiment certain que systemd évoluera pour s'adapter au besoin. Je doute sincèrement que RH aille au bras de fer (c'est à dire dise à Oracle : soit c'est comme on veut, soit il va vous falloir trouver une nouvelle distrib de référence). Aucun interet pour eux. Si ils le font - c'est à dire si ils refusent de rajouter des gruikeries dans systemd malgré un besoin Oracle je leur tire mon chapeau, et j'applaudirai des deux mains. Mais très honnêtement (et il s'agit de mon opinion personnelle là) je n'y crois pas.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 1.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
Et moi donc j'apprécierai que tu lises la doc que tu me balances avant de me dire que je suis dans le faux.
Je récapitule pour ce qui ne suivent pas : on a un process qui éventuellement fork et repasse la main à l'init avant de commencer une synchronisation et finalement de lancer le vrai processus.
On va partir du principe que le process ne fork pas pour simplifier le boulot, mais c'est encore pire si il fork
Les options intéressantes :
RemainAfterExit=
PIDFile=
ExecStart=
ExecStartPre=, ExecStartPost=
Dès le départ je suis obligé d'aller remplir le PIDFile avec le PID de mon premier élément sinon ca s'arrête et systemd concluera à un echec de lancement.
Ensuite je poursuis ma synchro. Quand ma synchro est finie problème :
Soit j'avais mis RemainAfterExit à TRUE et là je peux fermer mon process de synchro l'esprit tranquille, mais si mon process principal ne se lance pas, ben systemd ne sera jamais mis au courant du fait que ca ne marche pas. Pareil si le process se lance mais meurt par la suite.
Soit j'avais mis RemainAfterExit à FALSE et là c'est le drame parceque je ne peux pas fermer mon processus de synchro avant d'être sur que la mise a jour des PID a bien eu lieu dans systemd. Sauf que je sais pas quand elle a lieu la mise à jour. Donc je boucle en mode texte du systemctl jusqu'à ce que le PID modifié soit pris en compte. (Je ne sais pas si ca a changé, mais en vrai le nouveau PID dans le fichier ne sera jamais pris en compte)
On triche avec ExecStartPre, je lance la moitié de mon script d'init en pre pour la synchro et l'autre moitié en normal.
Problème : si la synchro se foire, l'autre commande n'est jamais executée. Sauf si je mets un - devant ma commande, auquel cas l'autre commande est toujours executée. Sauf que je veux du "des fois oui, des fois non". Donc il faut que j'étoffe mes deux scripts pour que le second script puisse récupérer et analyser les résultats du premier script (BEURK). Donc non seulement j'ai deux scripts à maintenir au lieu d'un, mais en plus j'ai du boilerplate qui vient se rajouter en plus sur l'existant.
Sauf que si le second script plante pendant le démarrage, il n'est pas dit qu'il aura fait le ménage avant que le plantage. Donc un petit troisième script en ExecStartPost pour passer le balais….(que tant qu'à faire je met aussi en ExecStartPre des fois que).
YOUPI trois scripts pour le prix d'un avec du boilerplate en plus…
Ensuite, si le souci, c'est l'orchestration de services sur le réseau
Non le soucis c'est de passer le service dans un état dans lequel il pourra être orchestré par la suite. C'est dire cohérent, synchronisé, stable et avec les bon paramètres de connexion connus.
_Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents _
Non c'est quasiment certain que systemd évoluera pour s'adapter au besoin. Je doute sincèrement que RH aille au bras de fer (c'est à dire dise à Oracle : soit c'est comme on veut, soit il va vous falloir trouver une nouvelle distrib de référence). Aucun interet pour eux. Si ils le font - c'est à dire si ils refusent de rajouter des gruikeries dans systemd malgré un besoin Oracle je leur tire mon chapeau, et j'applaudirai des deux mains. Mais très honnêtement (et il s'agit de mon opinion personnelle là) je n'y crois pas.