IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde
Et c'est là que le bas blesse. L'init script va faire ce que je lui demande, systemd va essayer de deviner. Si mon script d'init est merdique, ben je le corrige, si les choix de systemd sont mauvais je dispose de très peut d'outils pour le faire changer d'avis.
A l'époque des bon vieux PID dans /var quand je lançait un nouveau process je récupérais son PID et j'allais le rajouter à la mano dans une liste. C'est moche d'accord mais ça marche. L'équivalent systemd consisterait à insérer mon nouveau process dans le cgroup qui va bien. Ben je ne sais pas faire.
tu crées pas une carte réseau, tu crées au mieux une interface réseau
Si tu veux, une interface réseau virtuelle.
Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Non, non je veux bien dire lancer la couche TCP/IP. Je ne veux pas de TCP/IP (sur mes interfaces) avant que les tunnels VPN soient montés et que les interfaces virtuelles soient créées. Et non je n'ai pas besoin de TCP/IP pour monter mes VPN, c'est du gre pur (par exemple).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique"
C'est dans la partie chat échaudé craint l'eau froide. J'ai une config son trop complexe pour pulse-audio, j'ai une config réseau trop complexe pour network manager, j'ai un UPnP trop spécifique pour avahi - mais c'est pas grave parce que je désactive le truc qui me casse les pieds et je fais à la main.
Par contre désactiver l'init je vois pas comment faire. Surtout que je ne peux même pas ruser (en créant une unit unique avec un daemon idle en exec et un init traditionnel en pre) parceque systemd va de toute façon faire une partie du boulot que je le veuille ou non.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Oui mais je ne veux pas qu'il charge la config par défaut, je veux qu'il charge une autre config (de maintenance par exemple), et pour l'instant la seule solution que j'ai trouvée consiste à déclarer des tonnes de variables d'environnement et à s'en souvenir.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Prenons le cas suivant, je veux modifier un paramètre apache (ou d'un module apache) qui requiert un redémarrage d'apache. Par défaut apache est configuré pour redémarrer automatiquement dans systemd avec préservation des sockets. Qu'est-ce qu'il va se passer d'après toi si je fais apachectl restart ? Moi j'en ai pas la moindre idée. Apache va être relancé, mais par qui ? La bonne façon de faire quand on a besoin de passer par apachectl (donc pour un truc un peu plus costaud que juste restart) c'est de dire à systemd de ne plus le relancer automatiquement. Mais comment faire ?
tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ?
Je crois avoir donné pas mal d'exemples (et là je viens d'en détailler deux) donc je pense que l'attaque gratuite n'est pas franchement de rigueur. systemd est beaucoup plus rigide que l'init classique - ca n'est pas forcément un tort, mais il manque à mon sens pas mal d'outils/d'options à systemd pour être vraiment utilisable.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 4.
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde
Et c'est là que le bas blesse. L'init script va faire ce que je lui demande, systemd va essayer de deviner. Si mon script d'init est merdique, ben je le corrige, si les choix de systemd sont mauvais je dispose de très peut d'outils pour le faire changer d'avis.
A l'époque des bon vieux PID dans /var quand je lançait un nouveau process je récupérais son PID et j'allais le rajouter à la mano dans une liste. C'est moche d'accord mais ça marche. L'équivalent systemd consisterait à insérer mon nouveau process dans le cgroup qui va bien. Ben je ne sais pas faire.
tu crées pas une carte réseau, tu crées au mieux une interface réseau
Si tu veux, une interface réseau virtuelle.
Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Non, non je veux bien dire lancer la couche TCP/IP. Je ne veux pas de TCP/IP (sur mes interfaces) avant que les tunnels VPN soient montés et que les interfaces virtuelles soient créées. Et non je n'ai pas besoin de TCP/IP pour monter mes VPN, c'est du gre pur (par exemple).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique"
C'est dans la partie chat échaudé craint l'eau froide. J'ai une config son trop complexe pour pulse-audio, j'ai une config réseau trop complexe pour network manager, j'ai un UPnP trop spécifique pour avahi - mais c'est pas grave parce que je désactive le truc qui me casse les pieds et je fais à la main.
Par contre désactiver l'init je vois pas comment faire. Surtout que je ne peux même pas ruser (en créant une unit unique avec un daemon idle en exec et un init traditionnel en pre) parceque systemd va de toute façon faire une partie du boulot que je le veuille ou non.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Oui mais je ne veux pas qu'il charge la config par défaut, je veux qu'il charge une autre config (de maintenance par exemple), et pour l'instant la seule solution que j'ai trouvée consiste à déclarer des tonnes de variables d'environnement et à s'en souvenir.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Prenons le cas suivant, je veux modifier un paramètre apache (ou d'un module apache) qui requiert un redémarrage d'apache. Par défaut apache est configuré pour redémarrer automatiquement dans systemd avec préservation des sockets. Qu'est-ce qu'il va se passer d'après toi si je fais apachectl restart ? Moi j'en ai pas la moindre idée. Apache va être relancé, mais par qui ? La bonne façon de faire quand on a besoin de passer par apachectl (donc pour un truc un peu plus costaud que juste restart) c'est de dire à systemd de ne plus le relancer automatiquement. Mais comment faire ?
tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ?
Je crois avoir donné pas mal d'exemples (et là je viens d'en détailler deux) donc je pense que l'attaque gratuite n'est pas franchement de rigueur. systemd est beaucoup plus rigide que l'init classique - ca n'est pas forcément un tort, mais il manque à mon sens pas mal d'outils/d'options à systemd pour être vraiment utilisable.