Posté par Kaane .
En réponse au journal udev forké.
Évalué à 6.
donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire.
C'est très positif comme façon de faire. Il faut bien voir que les scripts d'init custom sont une plaie à maintenir, et que c'est la partie sur laquelle il est le plus complexe d'obtenir du support. Donc forcément il vaut mieux s'y prendre à l'avance. Le truc est que l'on peut lancer des scripts shells standard avec systemd mais que ça coince quand même à pas mal de niveaux.
Par exemple systemd essaye de suivre le double fork de la daemonisation comme il peut, parceque le plus souvent le processus qui est lancé immédiatement n'est pas le processus définitif. Au bout d'un temps X (qui dépend de tout un tas de paramètres y compris l'age du capitaine et les exceptions codées en dur) il va choisir un ou plusieurs processus à surveiller comme étant "le(s) bon(s)" processus.
Dans le cas d'un cluster qui peut mettre un certain temps à se synchroniser avant de démarrer (des fois plusieurs minutes, rarement quelques heures) le bon processus est lancé très tard et le processus daemonisé en premier qui ne fait que la synchro s'arrête. systemd n'aime pas du tout ce comportement, et on a pas de moyen simple de lui envoyer un message pour dire "tout va bien c'est XXXX le vrai processus".
Il existe des méthodes de contournement (on peut passer certaines infos d'un processus à un autre en systemd) mais ca fait des scripts complexes avec des exceptions, des tests et des cas aux limites un peu douteux.
Tu serais pas un peu aigri et totalement subjectif ?
Si bien sur pourquoi ? Mais pour autant la question à se poser est de savoir si j'ai tort ou pas…
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 6.
donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire.
C'est très positif comme façon de faire. Il faut bien voir que les scripts d'init custom sont une plaie à maintenir, et que c'est la partie sur laquelle il est le plus complexe d'obtenir du support. Donc forcément il vaut mieux s'y prendre à l'avance. Le truc est que l'on peut lancer des scripts shells standard avec systemd mais que ça coince quand même à pas mal de niveaux.
Par exemple systemd essaye de suivre le double fork de la daemonisation comme il peut, parceque le plus souvent le processus qui est lancé immédiatement n'est pas le processus définitif. Au bout d'un temps X (qui dépend de tout un tas de paramètres y compris l'age du capitaine et les exceptions codées en dur) il va choisir un ou plusieurs processus à surveiller comme étant "le(s) bon(s)" processus.
Dans le cas d'un cluster qui peut mettre un certain temps à se synchroniser avant de démarrer (des fois plusieurs minutes, rarement quelques heures) le bon processus est lancé très tard et le processus daemonisé en premier qui ne fait que la synchro s'arrête. systemd n'aime pas du tout ce comportement, et on a pas de moyen simple de lui envoyer un message pour dire "tout va bien c'est XXXX le vrai processus".
Il existe des méthodes de contournement (on peut passer certaines infos d'un processus à un autre en systemd) mais ca fait des scripts complexes avec des exceptions, des tests et des cas aux limites un peu douteux.
Tu serais pas un peu aigri et totalement subjectif ?
Si bien sur pourquoi ? Mais pour autant la question à se poser est de savoir si j'ai tort ou pas…