Mon script est assez courant en fait (Utilisé par pas mal de gens qui ont soit un modem ADSL en usb soit une config
réseau sécurisé) et c'est un des gros points de ralage contre systemd.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
Figure toi que c'est ce que j'ai essayé de faire. Et systemd aime pas du tout la blague -
pour lui network ca veut dire pleins de choses et son comportement est étrange quand ça ne se passe pas comme prévu.
et
Mais j'ai besoin de network, c'est dans mon script network que je veux que TCP/IP arrive plus tard.
Et systemd est incompatible avec ce comportement.
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
( à noter que les softs qui dépendent d'une interface particulière ou qui doivent gérer des choses quand une ip arrive le font via un hook dans /etc/ )
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload. Puis ensuite, je remets la config, et je fait un reload. Je vois même pas ce que systemed vient faire la, à part le fait que tu as du modifier les scripts d'init pour faire plus que ce qu'ils proposent de base. Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part", oui, systemd n'a pas pour vocation de supporter tout ce que les gens ont pu faire de non standard.
Ça fait des années qu'on dit aux gens "faut passer par service car il nettoie l’environnement avant de lancer un script", si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse. Sinon, service ( la commande ) supporte des helpers scripts dans /usr/libexec/initscripts/legacy-actions ( au moins sur une fedora ), peut être que ça va répondre à tes besoins.
Et si tu doit faire les choses à la main vite fait, pour changer la config, un des trucs merveilleux d'unix, c'est "cp". Sinon, un autre truc merveilleux qu'on fait, c'est "puppet". Tu coupes puppet, tu changes ta config, tu fixes le truc, tu lances puppet, ta config se remets d'équerre ( si ta config puppet est bien faite, bien sur ). C'est un chouia plus moderne, mais ça marche pas mal pour gérer des gros clusters.
Bien sur, peut être que tu gères tes 40 services à la mano sans ça et que ça marche, mais ça veut pas dire que c'est efficace. La preuve, tu es obligé d'écrire des scripts d'init customs juste pour ça, ce qui est tant à démontrer que les scripts sysV ne répondent pas à tes besoins, vu que tu dois les patcher ( et genre,en patcher 40, ç'est pas rien ).
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd". Comme ça, tu as les dépendances ( genre le process qui fait le sync va déclencher automatiquement le demon ), systemd surveille un process à la fois. Je suis sur que ça va pas te plaire non plus, mais bon, j'aurais au moins tenté.
Et pour terminer, pour la partie sur sshd et tomcat. Si je comprends bien, c'est que tu veux dans certains cas que restart relance tout ( stop, start ), et dans d'autres cas, que ça relance rien ?
Pour sshd, c'est fait de base par la distro, via pam. Chaque process sshd est migré vers un autre cgroups à la connexion. Comme je suppose que tu va me dire "j'utilise pas pam" ( car j'ai bien compris que forcément, les trucs qui marchent sont interdit en faveur des solutions maisons chez toi ), l'autre méthode est de mettre KillMode=none ( ou KillMode=process ), et de tuer ce que tu veux quand tu fait le stop.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner), que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd ( par exemple, avoir un script dans ExecStart/ExecStop permet de le faire sans casse et je suis sur que tu as deja le scripts qui existe pour faire ça ).
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 2.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
et
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
( à noter que les softs qui dépendent d'une interface particulière ou qui doivent gérer des choses quand une ip arrive le font via un hook dans /etc/ )
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload. Puis ensuite, je remets la config, et je fait un reload. Je vois même pas ce que systemed vient faire la, à part le fait que tu as du modifier les scripts d'init pour faire plus que ce qu'ils proposent de base. Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part", oui, systemd n'a pas pour vocation de supporter tout ce que les gens ont pu faire de non standard.
Ça fait des années qu'on dit aux gens "faut passer par service car il nettoie l’environnement avant de lancer un script", si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse. Sinon, service ( la commande ) supporte des helpers scripts dans /usr/libexec/initscripts/legacy-actions ( au moins sur une fedora ), peut être que ça va répondre à tes besoins.
Et si tu doit faire les choses à la main vite fait, pour changer la config, un des trucs merveilleux d'unix, c'est "cp". Sinon, un autre truc merveilleux qu'on fait, c'est "puppet". Tu coupes puppet, tu changes ta config, tu fixes le truc, tu lances puppet, ta config se remets d'équerre ( si ta config puppet est bien faite, bien sur ). C'est un chouia plus moderne, mais ça marche pas mal pour gérer des gros clusters.
Bien sur, peut être que tu gères tes 40 services à la mano sans ça et que ça marche, mais ça veut pas dire que c'est efficace. La preuve, tu es obligé d'écrire des scripts d'init customs juste pour ça, ce qui est tant à démontrer que les scripts sysV ne répondent pas à tes besoins, vu que tu dois les patcher ( et genre,en patcher 40, ç'est pas rien ).
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd". Comme ça, tu as les dépendances ( genre le process qui fait le sync va déclencher automatiquement le demon ), systemd surveille un process à la fois. Je suis sur que ça va pas te plaire non plus, mais bon, j'aurais au moins tenté.
Et pour terminer, pour la partie sur sshd et tomcat. Si je comprends bien, c'est que tu veux dans certains cas que restart relance tout ( stop, start ), et dans d'autres cas, que ça relance rien ?
Pour sshd, c'est fait de base par la distro, via pam. Chaque process sshd est migré vers un autre cgroups à la connexion. Comme je suppose que tu va me dire "j'utilise pas pam" ( car j'ai bien compris que forcément, les trucs qui marchent sont interdit en faveur des solutions maisons chez toi ), l'autre méthode est de mettre KillMode=none ( ou KillMode=process ), et de tuer ce que tu veux quand tu fait le stop.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner), que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd ( par exemple, avoir un script dans ExecStart/ExecStop permet de le faire sans casse et je suis sur que tu as deja le scripts qui existe pour faire ça ).