Pour bouger des pid dans le cgroup, c'est écrit dans la doc qui se trouve facilement via "cgroup pid move" sur un moteur de recherche. Exemple de résultat
Sauf que
a - c'est pas si évident que ça de trouver le cgroups qui va bien
b - systemd n'aura pas forcément conscience de ce changement, en fait il est même très fortement déconseillé de forcer une mise à jour ( http://0pointer.de/blog/projects/cgroups-vs-cgroups.html ) extrait :
> systemd will also maintain its own, private, controller-less, named control group hierarchy which is mounted to /sys/fs/cgroup/systemd/. This hierarchy is private property of systemd, and other software should not try to interfere with it. This hierarchy is how systemd makes use of the naming and grouping feature of control groups (A) without actually requiring any kernel controller enabled for that.
Dans la page entière il explique la différence entre les cgroups pour le nommage et les cgroups pour le controle, les seconds étant très impactant en terme de perfs il n'utilise que les premiers. Sauf que derrière vu que c'est privé, que systemd ne veut pas que je l'altère et que je n'ai pas de moyen de savoir quand les altérations des cgroups publics sont prises en compte (ni même si elle le sont) comment je fais pour informer systemd d'un nouveau processus ?
c - dans certains cas (apache, postgresql, postfix etc.) quand le processus maitre se casse la gueule il faut fermer tous les sous process et redémarrer à vide, mais dans d'autres cas (tomcat, sshd par exemple) je ne veux surtout pas tuer les sous process, en cas de redémarrage je veux les garder en vie et les rattacher au cgroup du nouveau processus maitre. Une fois de plus j'ai pas trouvé comment faire.
Pour tes trucs trop compliqués ou spécifiques, je pense qu'il a été dit facile 20 fois "tu peux garder ton script sysv".
Et j'ai dit 20 fois : non je ne peux pas, il ne marche pas dans le cadre de systemd.
Que ce soit parce qu'il lance pleins de processus et que systemd se retrouve à distribuer des watchers partout
Que ce soit parce qu'il met très longtemps à démarrer (gros check/sync au démarrage) et que systemd va mettre son watcher sur le process de synchro au lieu du process maitre (et donc me certifier mordicus que mon service est planté à partir du moment ou celui-ci aura enfin démarré)
Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
Euh… Le truc fait 20 lignes et lance une appli même pas démonisé, un script RC standard avec un peu de réseau, un peu de controle par API en fait 200. Donc non c'est pas la complexité (削除) que j'aime (削除ここまで) dont j'ai l'habitude.
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère.
Et qui va forcer un reload sur le premier service ? Ou bien j'arrête le premier service et je lance le second ? Et si je dois coder un fichier de conf à la va vite pour palier à un gros soucis il faut d'abord que je créé une nouvelle unit et que je la lance à la main ? Et si j'ai 20 services à mettre en maintenance ca me fait 40 scripts à maintenir ?
Non sérieusement j'aimais bien l'option ou en changeant une variable d'environnement et en lançant un script tout se passait comme je voulais.
Ca doit pas être super du de permettre un systemsct $service overload_reload $nouveau_fichier_de_conf.
Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Je veux pas stopper le service, je veux changer sa conf. J'ai besoin que le service reste actif parce que d'autres éléments non modifiés sont toujours utiles (voire vitaux) à mon système. Par exemple je veux rediriger le DNS du site corporate, pas priver tout le plateau de résolution DNS, je veux ajouter une règle de transformation dans postfix pas arrêter le mail local etc.
Et avec sysvinit j'utilisais les outils de controle de base et ca se passait bien. Avec systemd c'est pas que ca se passe mal, c'est que je n'arrive pas à comprendre tout ce qui se passe et je ne vois pas comment faire pour récupérer/transmettre l'info.
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ).
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.
Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch
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. Ca n'est pas bloquant en soit, juste que ca ralenti le boot de façon chiante (vu qu'il n'y a rien sur le réseau hors vpn le systeme va essayer pleins de trucs, attribuer des adresses par défaut etc.)
L'autre gros point de ralage concerne les partitions chiffrées, pas mal de modèles de chiffrement sont incompatibles avec systemd aussi.
En fait, tu peux aussi juste rajouter une unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire
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.
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp )
Ma phrase n'est pas claire, c'est de ma faute. Je pensais plutôt aux sockets de l'autre coté d'apache (vers les proxy, les caches, les X-cgi bidouillés), mais c'est vrai que si je fais ouvrir par systemd plutôt que par apache lui-même, je n'ai qu'à m'en prendre à moi même. Ca me paraissait pratique de pouvoir bufferiser les requètes le temps qu'apache redémarre, mais c'est juste pas possible. Tant pis.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 6.
Pour bouger des pid dans le cgroup, c'est écrit dans la doc qui se trouve facilement via "cgroup pid move" sur un moteur de recherche. Exemple de résultat
Sauf que
a - c'est pas si évident que ça de trouver le cgroups qui va bien
b - systemd n'aura pas forcément conscience de ce changement, en fait il est même très fortement déconseillé de forcer une mise à jour ( http://0pointer.de/blog/projects/cgroups-vs-cgroups.html ) extrait :
> systemd will also maintain its own, private, controller-less, named control group hierarchy which is mounted to /sys/fs/cgroup/systemd/. This hierarchy is private property of systemd, and other software should not try to interfere with it. This hierarchy is how systemd makes use of the naming and grouping feature of control groups (A) without actually requiring any kernel controller enabled for that.
Dans la page entière il explique la différence entre les cgroups pour le nommage et les cgroups pour le controle, les seconds étant très impactant en terme de perfs il n'utilise que les premiers. Sauf que derrière vu que c'est privé, que systemd ne veut pas que je l'altère et que je n'ai pas de moyen de savoir quand les altérations des cgroups publics sont prises en compte (ni même si elle le sont) comment je fais pour informer systemd d'un nouveau processus ?
c - dans certains cas (apache, postgresql, postfix etc.) quand le processus maitre se casse la gueule il faut fermer tous les sous process et redémarrer à vide, mais dans d'autres cas (tomcat, sshd par exemple) je ne veux surtout pas tuer les sous process, en cas de redémarrage je veux les garder en vie et les rattacher au cgroup du nouveau processus maitre. Une fois de plus j'ai pas trouvé comment faire.
Pour tes trucs trop compliqués ou spécifiques, je pense qu'il a été dit facile 20 fois "tu peux garder ton script sysv".
Et j'ai dit 20 fois : non je ne peux pas, il ne marche pas dans le cadre de systemd.
Que ce soit parce qu'il lance pleins de processus et que systemd se retrouve à distribuer des watchers partout
Que ce soit parce qu'il met très longtemps à démarrer (gros check/sync au démarrage) et que systemd va mettre son watcher sur le process de synchro au lieu du process maitre (et donc me certifier mordicus que mon service est planté à partir du moment ou celui-ci aura enfin démarré)
Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
Euh… Le truc fait 20 lignes et lance une appli même pas démonisé, un script RC standard avec un peu de réseau, un peu de controle par API en fait 200. Donc non c'est pas la complexité
(削除) que j'aime (削除ここまで)dont j'ai l'habitude.Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère.
Et qui va forcer un reload sur le premier service ? Ou bien j'arrête le premier service et je lance le second ? Et si je dois coder un fichier de conf à la va vite pour palier à un gros soucis il faut d'abord que je créé une nouvelle unit et que je la lance à la main ? Et si j'ai 20 services à mettre en maintenance ca me fait 40 scripts à maintenir ?
Non sérieusement j'aimais bien l'option ou en changeant une variable d'environnement et en lançant un script tout se passait comme je voulais.
Ca doit pas être super du de permettre un systemsct $service overload_reload $nouveau_fichier_de_conf.
Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Je veux pas stopper le service, je veux changer sa conf. J'ai besoin que le service reste actif parce que d'autres éléments non modifiés sont toujours utiles (voire vitaux) à mon système. Par exemple je veux rediriger le DNS du site corporate, pas priver tout le plateau de résolution DNS, je veux ajouter une règle de transformation dans postfix pas arrêter le mail local etc.
Et avec sysvinit j'utilisais les outils de controle de base et ca se passait bien. Avec systemd c'est pas que ca se passe mal, c'est que je n'arrive pas à comprendre tout ce qui se passe et je ne vois pas comment faire pour récupérer/transmettre l'info.
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ).
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.
Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch
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. Ca n'est pas bloquant en soit, juste que ca ralenti le boot de façon chiante (vu qu'il n'y a rien sur le réseau hors vpn le systeme va essayer pleins de trucs, attribuer des adresses par défaut etc.)
L'autre gros point de ralage concerne les partitions chiffrées, pas mal de modèles de chiffrement sont incompatibles avec systemd aussi.
En fait, tu peux aussi juste rajouter une unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire
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.
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp )
Ma phrase n'est pas claire, c'est de ma faute. Je pensais plutôt aux sockets de l'autre coté d'apache (vers les proxy, les caches, les X-cgi bidouillés), mais c'est vrai que si je fais ouvrir par systemd plutôt que par apache lui-même, je n'ai qu'à m'en prendre à moi même. Ca me paraissait pratique de pouvoir bufferiser les requètes le temps qu'apache redémarre, mais c'est juste pas possible. Tant pis.