En parlant d'un problème de cgroups sur le forum gentoo, un autre utilisateur à glissé un lien sur cet article: Group Scheduling, dans lequel un zigoto qui n'en loupe pas une pour faire des idioties déclare:
Lennart Poetering de son côté s'est empressé d'intervenir pour répondre à Linus et pour critiquer ce patch. Il propose une approche basée, vous vous en doutez, sur son nouveau démon d'init « systemd » :
Tout ça est complètement inutile pour les utilisateurs normaux >
Il y a quelque temps, j'achète un portable et je me dis que comme il est moins puissant que ma tour, je vais installer Debian plutôt que gentoo. L'install se passe bien, Je résume. Dans l'autostart de fvwm-crystal, j'ai qjackctl et gladish, deux programmes normaux pour ce zigoto. Je commence à configurer jack, et je découvre que le cgroup qui m'intéresse n'est pas dans le kernel Debian. Je ne souhaite pas utiliser un kernel temps réel car avec les cgroups je peux obtenir la même chose, du temps réel pour mes applications audio, et en même temps avoir la stabilité à toute épreuve d'un kernel vanilla. Je fais donc mon propre kernel, et paf, libcgroup de Debian ne fonctionne pas. Je fais de la spéléologie dans les dépôts de Debian et dans les rapports de bug pour me faire une version de libcgroup débarassée du support de systèmd. ça marche bien, à part un léger détail. systemd passait son temps à mettre des trucs dans mon cgroup temps réel qui n'avaient rien à y faire. Résultat: même les magick key étaient mortes quand, comme dans le gag de Fernand Reynaud, le système était tellement froid qu'il plantait après un certain temps.
Ce mec est une plaie. Il en loupe pas une. Déjà avec udev, son premier exploit fut de planter le chargement par le kernel du firmware associé à certains modules. Il n'avait alors jamais reconnu ses tords et les développeurs du kernel ont dû patcher le kernel. Imaginez si le kernel devait être patché pour chaque bug du système! EDIT: Là, je me suis trompé, c'est en fait lui qui avait signalé ce bug, voir plus bas. Je retire donc la plaie. ENDEDIT. Ensuite il nous a valu la catastrophe *kit, quelque chose de totalement inutile sauf pour quelques grandes entreprises paranoïaques - celles-là même qui collaborent avec la NSA et ce genre d'agences -, et tellement mal foutu qu'il faut incorporer un interpréteur java script dans le coeur du système, ceci alors que l'immense majorité des administrateurs système ne connaissent pas java script et qu'ils ont autre chose à faire que l'apprendre. Et maintenant 3 ans plus tard, son patch pour systemd plante toujours les cgroups quand on est pas ce que cet inénarrable appelle un utilisateur normal.
Résultat des courses, j'ai arrêté de perdre mon temps avec ses conneries et j'ai installé gentoo sur le portable. Sur le long terme, il faut vraiment le stopper ce mec, c'est une plaie qui n'en loupe pas une pour casser le système. Il est totalement imbu de lui même et persuadé, comme il le laisse très bien entendre, que les utilisateurs qui ne sont pas contant avec ses programmes sont des anormaux. Alors l'anormal, tu vois ce qu'il va lui dire si jamais il le rencontre! J'espère pour lui que sa femme sera pas là pour voir ça parce qu'autrement, ce sera le divorce assuré!
Que cela lui plaise ou non, il y a deux parties dans GNU/Linux, il y a GNU et il y a le kernel. Le kernel est fantastique car dans l'immense majorité des cas, il faut son travail sans qu'on l'aperçoive et il le fait remarquablement bien. Quand à ce gens-là, comme disait Jaqcques Brel, qui prend les autres pour des anormaux, il n'en loupe pas une pour tout casser. Systemd est une bonne idée, mais comme le montre ce problème et bien d'autres, son implémentation est une catastrophe.
# Re:
Posté par Tonton Benoit . Évalué à 5.
J'ai du mal à voir la logique entre :
Ok Debian = pas systemd par défaut, donc
Jusque là ça va, pas systemd donc tu recompile la libcg sans systemd, Ok
Et finalement tu utilise systemd à la place de cgdaemon ?
Pour ton "problème", supposé que s'en soit un et pas une simple question d'héritage des propriétés du cgroups parent (du coup normal que dans un univers qui n'en utilise aucun (Gentoo sans Systemd) ton cgroups n'hérite de rien), c'est quoi la démarche que je teste sous Gentoo/Systemd ?
[^] # Re:
Posté par Domi . Évalué à 1. Dernière modification le 13 janvier 2014 à 01:53.
Quoi qu'il en soit, quand j'ai installé Debian, systemd à été installé. De plus, j'ai installé gentoo ce qui a résolu mon problème (voir plus bas).
Le problème de systèmed avec les cgroups est qu'il installe, comme je l'ai compris en lisant ce qui dit Lennart dans l'article de linux.fr, j'ai aussi lu l'entier de ce qu'il dit sur gmane (le lien est dans l'article), le problème est que systemd implémente seulement un subset des cgroups qui correspond à l'option automatique du kernel, qu'il prend le contrôle des cgroups, et que contrairement au kernel associé avec libcgroup/cgroup-bin, systemd ne met aucune réelle possibilité de setup à disposition de l'utilisateur.
Ceci implique que n'importe quel utilisateur qui utilise autre chose que la configuration automatique des cgroups dans le kernel ne peut pas utiliser systemd. Donc, la communauté audio pro n'est sûrement pas la seule concernée par ce problème avec systemd.
La cause de ce problème est pour moi une fausse conception de ce que fait un utilisateur avec son pc. Pour moi, un pc ça sert à travailler. Pour le développeur en chef de systemd, comme il le dit très bien dans son mail sur gmane, un pc sert à faire tourner un GUI et toutes les autres utilisations ne sont pas relevantes.
Ce qui implique que pour résoudre ce problème, il faudrait revoir l'API de systemd pour qu'il supporte toutes les fonctions cgroups du kernel, ceci même en mode non automatique, et pour qu'un plus systemd soit capable de proposer un interface de configuration des cgroups à l'utilisateur.
Quand à mon gentoo, une partie de mes USE flags sont "-systemd -consolekit -policykit -pulseaudio -udisks -udisks2", donc un système léger sans tous ses machins superflus qui apportent plus de problèmes que de solutions. Je ne remet pas en cause l'idée de systemd, mais je constate simplement que son implémentation actuelle est contraire à l'esprit de GNU/Linux qui est d'offrir le choix aux utilisateurs. LEs cgroups du kernel, en conjonction avec libcgroup/cgroup-bin, permettent d'optimiser une machine donnée pour n'importe quelle sorte de charge de travail. Avec systemd, seule une configuration par défaut est proposée, et il n'y a aucune possibilité de sortir de cette configuration par défaut. De plus la documentation est quasi inexistante, ce qui est normal vu le peu de possibilités de configuration.
Lennart le dit lui même:
Ce qui implique que son implémentation des cgroups dans systemd est à moitié incomplète.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Tonton Benoit . Évalué à 5.
http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
J'imagine que tu a déjà lu cette page, qui mitige déjà pas mal tes propos sur la mauvaise volonté des devs systemd.
Quoi qu'il en soit si systemd a pu perturber la création de ton cgroup c'est qu'il étais le pid 0 et ton service lancé via la couche de compatibilité SysV si j'en croit le lien au dessus. La solution aurait été simplement de passer soit à du full systemd (et modifier le fichier du service pour ajouter le realtime à son cgroup) soit de passer à du full SysV avec init=/sbin/init vue que les systemdaises ne t'intéressent pas.
Bref loin d'y avoir mort d'homme et plus une question de mentalité que de systemd, habitué, comme moi, à Gentoo et ses useflags tu a du mal à te satisfaire des choix des mainteneurs des distribs binaires.
[^] # Re:
Posté par Domi . Évalué à 1.
J'ai certainement du la lire à l'époque où j'ai installé ce Debian. Je me rappelle avoir tout essayé, ce qui ne veut pas dire que j'ai forcément fait tout juste, mais comme mon système passait son temps à se bloquer, et que personne n'a pu m'aider sur le forum de Debian, même pas avec un pointeur sur de la doc ou en me disant que je pouvais virer systemd et le remplacer par init, je suis rapidement passé à autre chose et j'ai reformaté et contrôlé le disque avant d'installer gentoo.
Ce n'est que hier en lisant le mail de Lennart que j'ai commencé à comprendre qu'une configuration des cgroups comme la mienne ne peut simplement pas fonctionner avec systemd dans l'état actuel des cgroups et de systemd. Je n'ai qu'un seul cgroup, un groupe cpu temps réel, et comme c'est le seul cgroup cpu, systemd voit que c'est un groupe cpu et il le pollue, ce qui tôt ou tard résulte en un blocage total du système.
De plus, en parallèle à cette discussion, j'en ai une avec les développeurs de systemd, et un d'entre eux m'a conseillé, comme j'ai une config custom des cgroups, de ne pas utiliser systemd. Ce qui me donne raison. Le stade suivant pour moi est d'aller voir les devs des cgroups du kernel car il m'a dit qu'ils sont en train de tout changer.
Quand aux choix de Debian, j'ai été surpris de la facilité pour virer *kit. Je ne dénigre absolument pas Debian, c'est une distribution qui a fait ses preuves et que j'avais déjà utilisée dans le passé avant gentoo. Il y a aussi eu Suse que j'ai utilisé pendant de nombreuses années avant Debian, plus un intermède gentoo au milieu de Debian. Donc pas mal d'années sous GNU/Linux (depuis mon 386) et sous différentes distributions. Il y en a eu encore d'autres comme Agnula et Demundi, basées sur Debian, pour ne citer que celles que j'ai réellement utilisées.
Autrement, j'ai aussi essayé AROS. Excellent système dont le bureau, même en tant qu'hôte linux, est beaucoup plus rapide que ceux de GNU/Linux. Malheureusement, il y a encore peu de logiciels disponibles.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par gouttegd (site web personnel) . Évalué à 2.
En fait, à terme systemd doit être le seul à utiliser les cgroups de manière à les cacher complètement au reste du système. Il introduit pour ça les « slices », qui sont la seule chose que le code utilisateur est censé connaître et utiliser pendant que lui (systemd) utilise les cgroups en arrière-plan.
“Direct access to the cgroup tree is on is way out and that must be clear to everybody.” — L. Poettering
[^] # Re:
Posté par Domi . Évalué à 1.
Merci pour le lien. Voilà qui me donne une raison de plus d'aller discuter avec les devs des cgroups du kernel.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Tonton Benoit . Évalué à 2.
Bien que posté il y a déjà fort longtemps vu le rythme d'évolution de systemd ce message n'est pas encore d'actualité, certes systemd a bien introduit les slices dans son namespace de cgroups, mais j'arrive encore très bien a utiliser cgconfigparser pour créer un cgroup à coté de systemd sans qu'il s'en mêle et les options pour spécifier les contrôleurs à ajouter à un service sont encore présentes.
De plus la fin du message est rassurante, y'aura pas de perte de fonctionnalités, juste un changement de méthodes :)
C'est l'avant dernier paragraphe qui me laisse dubitatif, j'aurait vraiment pas pensé que le "signe-writer" soit encouragé par les devs du noyau. J'aurait plutôt vu une évolution genre chaqu'un sa hiérarchie.
[^] # Re:
Posté par kursus_hc . Évalué à 2.
Nope. Systemd n'est pas installé par défaut sous Debian, et encore moins activé.
https://wiki.debian.org/systemd
Quelle version de Debian utilises-tu ? Si c'est une sid comment as-tu fait pour l'installer ?
[^] # Re:
Posté par Domi . Évalué à 1.
Aucune, j'ai formaté et contrôlé le disque avant d'installer gentoo. Donc je n'ai aucun moyen de savoir pourquoi systemd avait été installé. Et de nouveau, je n'ai rien contre Debian qui est une excellente distribution, ce sujet est sur systemd et les cgroups.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par kursus_hc . Évalué à 2. Dernière modification le 14 janvier 2014 à 04:16.
Oui j'avais bien compris, c'était juste pour signaler que ton diagnostic a été très probablement perturbé par le fait que systemd n'était pas actif lors de tes tests (la seule et unique façon de l'activer est de le faire à la main).
[^] # Re:
Posté par Domi . Évalué à 1.
Tout ce que je sais est que sans systemd, la même configuration des cgroups fonctionne parfaitement dans mon installation actuelle ainsi que dans la précédente, et que dans celle du milieu avec systemd, je me retrouvais avec des trucs que je n'ai pas configuré dans mon groupe temps réel. Et que comme ils n'étaient pas configurés, ce ne peut pas être cgroup-bin/libcgroup qui les y a mis.
De plus, comme ce groupe temps réel utilise le cgroup cpu et que systemd utilise aussi le groupe cpu, je ne vois pas quel programme autre que systemd pouvait mettre ces trucs dans mon groupe temps réel.
Maintenant, que j'ai vu passer un message d'apt-get me demandant d'activer systemd est une possibilité. Quand j'ai vu que systemd était installé, je ne le connaissais pas, et je n'avais à priori rien contre. Au début tout allait bien, c'est quand, après avoir installé mon kernel dans lequel j'ai viré toutes les options des cgroups sauf le groupe cpu et son séquenceur temps réel, j'ai installé et configuré cgroup-bin, que les problèmes ont commencé et que je me suis retrouvé avec un système qui passait son temps à se bloquer sans rémission possible.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par kursus_hc . Évalué à 2.
Encore une fois ce n'est pas possible sous Debian. Une distrib dérivée peut-être mais pas Debian, où installer systemd ne le fait pas s'activer.
# Scheduler Temps reel
Posté par Anthony Jaguenaud . Évalué à 1.
Le scheduler temps réel est intégré. Il suffit d'utiliser
schedtool.La seule chose, c'est que le noyau sera prioritaire sur ton process.
[^] # Re: Scheduler Temps reel
Posté par Domi . Évalué à 1. Dernière modification le 13 janvier 2014 à 21:04.
Mon cgroup temps réel fournit cpu.rt_runtime_us, ce qui est comparable au temps réel fourni par un kernel -rt, et qui n'est pas fourni avec le kernel standard de Debian. Pour l'avoir, j'ai du compilé mon propre kernel à partir des sources de celui de Debian. Donc nous ne devons pas parler du même temps réel. Je parle de CONFIG_RT_GROUP_SCHED, pas de SCHED_FIFO.
http://trac.jackaudio.org/wiki/Cgroups
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Scheduler Temps reel
Posté par Anthony Jaguenaud . Évalué à 2.
En fait, je répondais uniquement pour :
J’ai cru comprendre, que tu avais besoin que « jack » soit exécuté en priorité. Donc je proposais une solution sans les cgroups, ni de noyau RT, les noyaux Linux intègrent automatiquement (il me semble) les schedulling de POSIX. Je ne connais pas les cgroups, et pour une fois, je ne voulais pas entrer dans une discussion systemD… juste t’apporter une solution potentielle. J’ai déjà utilisé ça pour jouer à un jeu en attendant la mise à jour de KDE sur ma gentoo ;-)
[^] # Re: Scheduler Temps reel
Posté par gouttegd (site web personnel) . Évalué à 2.
Tu veux dire que le noyau fourni par défaut sous Debian n’est pas configuré avec CONFIG_RT_GROUP_SCHED ? Si c’est le cas, alors la méthode d’Anthony devrait marcher.
Pour rappel, il y a deux façons incompatibles de donner des privilèges temps-réels à un processus sous Linux, selon que CONFIG_RT_GROUP_SCHED soit activé ou non.
Sans CONFIG_RT_GROUP_SCHED, un processus demande une politique d’ordonnancement temps-réel (SCHED_FIFO ou SCHED_RR) et une priorité en appelant sched_setscheduler(2). Le système accède à cette demande si le processus est autorisé, c’est-à-dire si la “resource limit” RLIMIT_RTPRIO associée à ce processus est supérieure à la priorité demandée. En règle générale, la limite RLIMIT_RTPRIO (comme toutes les autres ”resource limits”) pour un utilisateur donné est définie à la connexion de ce dernier, via un module PAM qui applique des règles décrites dans
/etc/security/limits.conf.Si le noyau est compilé avec CONFIG_RT_GROUP_SCHED, un processus obtient une politique d’ordonnancement temps-réel de facto en se plaçant (ou en étant placé) dans un cgroup auquel on a attribué une « fraction de temps réel » (paramètre cpu.rt_runtime_us > 0).
Les deux méthodes sont incompatibles parce que la seconde invalide complètement la première : si CONFIG_RT_GROUP_SCHED est activé, demander et obtenir une politique d’ordonnancement temps réel avec sched_setscheduler(2) ne sert à rien tant que le processus n’est pas placé dans un cgroup avec un cpu.rt_runtime_us non-nul (le piège étant que l’appel à sched_setscheduler(2) n’échoue pas — pour le processus, tout semble se passer comme s’il avait bel et bien obtenu la politique d’ordonnancement qu’il demandait). Inversement, une fois un processus placé dans un cgroup « temps réel », il a de facto une politique d’ordonnancement temps réel même s’il ne l’a pas explicitement demandé.
[^] # Re: Scheduler Temps reel
Posté par Domi . Évalué à 1. Dernière modification le 14 janvier 2014 à 15:16.
Le patch -rt, comme RT_GROUP_SCHED, apportent quelque chose en plus. Voir http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler?page=0
Avec JACK, les deux solutions me permettent d'obtenir une latence audio dans JACK aussi faible qu'une milliseconde, ce qui me permet d'avoir un système fiable dans tous les cas avec une latence comprise entre 10 et 20 ms. Un kernel standard ne permet de faire ça qu'avec RT_GROUP_SCHED.
Un autre article intéressant sur l'audio est celui-ci: http://lwn.net/Articles/339316/
Il montre pourquoi l'audio est un gros bordel sous GNU/Linux. Il montre aussi deux choses sur Lennart. D'abord c'est un mec plein de bonne volonté et qui s'investit beaucoup. Ensuite il a un ego disproportionné et quand sa solution n'est pas adoptée ou est critiquée, plutôt que d'accepter la critique et discuter de ce qui peut être changé, il se braque et traite ses interlocuteurs de "desktop haters". Ce qui clos la discussion.
Avec JACK, et une dizaine de lignes dans mon .asoundrc, j'interface JACK et les applications ALSA, ceci sans latence supplémentaire, et chaque application ALSA apparaît dans le graphe de connexion de qjackctl, j'obtiens à peu près la même chose qu'avec pulseaudio, mais avec une latence constance au lieu d'avoir une latence qui augmente au premier xrun dans pulseaudio, avec comme seule possibilité pour la faire redescendre de devoir stopper et redémarrer pulse. http://www.linuxmao.org/ALSA+Router+un+flux+ALSA+vers+JACK Quand je vois ça, je suis sur et certain que si la communauté audio pro avait été écoutée, au lieu de développer un système non professionnel comme pulseauedio, il aurait été possible, en construisant uniquement sur ALSA et JACK, d'obtenir la même chose, mais mieux car professionnel, et ceci vraisemblablement avec bien moins d'efforts que ceux qui ont été mis en oeuvre pour développer pulse, car toutes les briques de base existent.
Quand à systemd, selon plusieurs développeurs de la LAD (liste Linux Audio Development), même si certains d'entre eux l'utilisent, il est en train de devenir un plus grand problème que celui qu'il est censé résoudre, ceci pour la raison que systemd fourni des politiques de gestion du système au lieu de fournir les moyens de créer des politiques de gestion. Ce qui limite la liberté du choix des utilisateurs de créer leurs propres politiques de gestion du système. Et quand je parle de ce problème avec eux, les développeurs de systemd me répondent que Linux n'a jamais été une question de choix, ce qui clos toute discussion.
Je comprends très bien, étant moi-même manager de plusieurs projets, que la liberté de choix d'un développeur peut venir en conflit avec la liberté de choix des utilisateurs, mais j'estime aussi que cela fait partie du devoir d'un développeur, s'il casse quelque chose offert à ses utilisateurs, de proposer une nouvelle façon de le faire. Pour cela, je suis toujours très clair avec les nouveaux développeurs qui joignent mes projets: ils peuvent faire ce qu'ils veulent tant qu'ils ne cassent pas les fonctions existantes des programmes. Ils peuvent les modifier, mais les fonctionnalités présentes avant leurs modifications doivent continuer à exister.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Scheduler Temps reel
Posté par Domi . Évalué à 1.
Et je rajouterais même que je connaît de nombreux développeurs, et pas des moindres pour certains, qui entre autre à cause de ce genre de problèmes, ont pris la décision de migrer sur d'autres systèmes, à commencer par FreeBSD, quand ce n'est pas déjà fait.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# bullshit
Posté par xcomcmdr . Évalué à 2. Dernière modification le 13 janvier 2014 à 21:17.
Si tu parles de ce thread sur la LKML, Lennart n'y est pas du tout impliqué, de près ou de loin, il me semble. C'est le mainteneur de udev qui se fait engueuler par Linus.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: bullshit
Posté par Domi . Évalué à 1.
Tu as raison, il n'est pour rien dans ce coup là. En fait c'est même lui qui avait signalé ce bug. Je vais éditer le premier message si c'est possible pour qu'il reflète ça.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# Et gnome dans tout ça
Posté par Domi . Évalué à 1.
Il semble qu'il y ait encore un autre problème lié à systemd, c'est Gnome. La dernière version de Gnome a besoin de systemd pour que toutes ses fonctions soient disponibles. http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide#Systemd Ce qui laisse peu de choix pour une distribution binaire:
De toute façon, l'avenir nous dira si systemd va vraiment s'imposer ou s'il va finir comme Hal.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.