Bonjour
je me demande si les versions glibc systemd et kernel doivent être corréler ?
je m'explique si je veut, par exemple, mettre un noyau 4 sur une distribution qui utilise systemd je doit espérer que systemd soit à jour et le compiler aussi ?
ou si je veut faire un lfs avec systemd impossible sans utiliser des versions spécifique ?
T.
# Versions minimum
Posté par Renault (site web personnel) . Évalué à 2.
Ces logiciels sont liés, car ils dépendent de fonctionnalités disponibles à partir d'une certaine version du noyau Linux. C'est rarement lié à une version spécifique, plutôt à une borne inférieure (ne pas utiliser un systemd récent sur un noyau très ancien par exemple).
Tout ceci doit être accessible sur la page officielle de ces projets, voire dans les notes d'installation de leurs sources.
[^] # Re: Versions minimum
Posté par totof2000 . Évalué à -1.
Hum … On va encore dire que je critique systemd, mais je n'ai pas de souvenir de telle dépendance avec sysvinit ou upstart, par exemple.
[^] # Re: Versions minimum
Posté par Renault (site web personnel) . Évalué à 3.
Oui, car tu es de mauvaise foi. Les cgroups, fonctionnalité du noyau essentiel pour systemd n'existe que depuis le noyau 2.6.32 environ, de fait, les noyaux antérieurs sont inutilisables avec.
Mais je te rassure, c'est le cas pour presque tout les outils systèmes qui récupèrent des informations auprès de Linux pour fonctionner. On peut reparler longuement de la quantité d'outils qui a du s'adapter à tous les changements dans /sys et /proc par exemple. La plupart des logiciels d'aujourd'hui ne fonctionneraient pas sans adaptation avec un Linux 1.0, que veux-tu ? Ce n'est pas pour autant que tous ces programmes sont pourris.
[^] # Re: Versions minimum
Posté par xcomcmdr . Évalué à 4.
Source ? Preuve ?
Au contraire, cela ne m'étonnerait pas que SysV et Upstart aient eux aussi une version minimum requise pour la glibc. Faut pas rêver.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Versions minimum
Posté par totof2000 . Évalué à 2.
Relis ma phrase : j'ai bien précisé que je n'avais pas souvenir, je n'ai pas dit que ce n'est pas le cas.
[^] # Re: Versions minimum
Posté par GnunuX (site web personnel) . Évalué à 5.
Ta remarque est idiote.
Tu commences ta phrase en laissant entendre que tu émets une critique sur systemd du fait de la dépendance, en comparant, non pas le fait qu'il y a des dépendances fortes sur upstart, mais uniquement du fait que ta mémoire te joue des tours.
Donc en gros ta critique c'est : "systemd c'est de la merde, la preuve je suis amnésic quand on me parle d'upstart".
[^] # Re: Versions minimum
Posté par totof2000 . Évalué à 0.
C'est toi qui le prends comme ça :
De mémoire, je ne me souviens pas avoir eu à me soucier d'une quelconque dépendance avec sysinit ou upstart lorsque j'ai fait des mises à jour ou des downgrades de noyau. Donc ça signifie pour moi 2 choses : soit ma mémoire est défaillante, soit je n'ai pas rencontré ce cas. Et de mémoire je ne me souviens pas avoir lu quoi que ce soit concernant un problème de version de sysvinit par rapport à la version de noyau (d'ailleurs ça m'étonnerait qu'il y ait le moindre problème de compatibilité avec sysvinit, dans la mesure ou le code source n'utilise que des appels système que l'on trouve dans n'importe quelle version de libc). Comme je ne prétends pas être infaillible, c'est pour ça que je mets ma mémoire en doute.
Maintenant tu en déduis peut-être que je veux dire que "systemd c'est de la merde" mais ce n'est pas ce que je voulais dire. Je voulais seulement mettre en évidence que l'un des points que les détracteurs de systemd mettent en avant (et qui a été déjà débattu ici) semble s'avérer ici : et tu remarqueras ici que celui qui ferme la discussion avec des attaques personnelles, ce n'est pas moi (on reproche souvent ce point à ceux qui sont contre systemd, mais vous avez démontré ici que ce n'est pas propre à ceux-ci, on trouve ce genre de réaction des deux côtés).
Alors si tu as des exemples concrets, je suis prêt à te lire (toi ou n'importe qui d'autre).
[^] # Re: Versions minimum
Posté par GnunuX (site web personnel) . Évalué à 3.
Euh, systemd demande une version minimum du noyau … upstart demande une version minimum du noyau. C'est un problème pour systemd, mais tout à fait normal pour upstart. C'est bien cela ?
upstart : http://upstart.ubuntu.com/faq.html#requirements-building
Pour sysinit, ne voyant pas à quel projet tu fais référence (http://sysinit.sourceforge.net/ ?) je n'en sais rien.
[^] # Re: Versions minimum
Posté par totof2000 . Évalué à 1.
Non, j'ai simplement dit que je n'ai pas souvenir d'avoir rencontré le problème.
Par exemple. Et on peut noter que "The system initialization portion has no external requirements except a working BASH shell."
# glibc non, systemd peut-être
Posté par gouttegd . Évalué à 2. Dernière modification le 17 avril 2015 à 01:14.
Pour Systemd, je ne sais pas trop¹, mais pour la glibc, d’aussi loin que je me souvienne, ça ne m’a jamais posé le moindre problème de mettre continuellement à jour le noyau tout en gardant une glibc vieille de parfois plusieurs années (là par exemple, j’ai une glibc 2.17 datant de 2012 sur un noyau 3.18 compilé le mois dernier). Même le passage du noyau 2.4 au noyau 2.6 (utiliser un noyau 2.6 avec une glibc — et plus généralement tout l’userspace —compilée contre un noyau 2.4) n’avait posé aucun souci à l’époque.
En revanche, si le noyau proprement dit peut être « désynchronisé » de la glibc, pour les développeurs ou ceux qui installent des logiciels à partir des sources il est très fortement conseillé que les fichiers d’en-tête du noyau (
/usr/include/linux) restent ceux contre lesquels la glibc a été compilée.Dans ce sens-là, a priori, non. Ce serait plutôt dans l’autre sens (installer la dernière version de systemd avec un noyau plus ancien) qu’il pourrait y avoir problème.¹
¹ J’ai le vague souvenir
d’un trolld’une discussion ici-même où quelqu’un faisait part d’un message de Poettering expliquant qu’il entendait coller de très près au noyau Linux, et qu’il n’était pas exclu que des versions de systemd exigent une version suffisamment récente du noyau. N’utilisant pas systemd, je ne sais pas ce qu’il en est dans les faits.[^] # Re: glibc non, systemd peut-être
Posté par Renault (site web personnel) . Évalué à 3.
Une glibc de 2012, ce n'est pas ce que j'appellerais vieux. ;)
Note que la glibc dépend de certaines versions du noyau, à partir de la glibc 2.17 (décembre 2012) demande une version de Linux d'au moins 2.6.16 qui est certes très ancien.
L'inverse est tout aussi vrai, des appels systèmes de Linux nécessitent des versions de glibc particulières. Typiquement le noyau 2.6.36 (octobre 2010) dépend pour certaines choses de la glibc 2.13 (janvier 2011, sisi, une version d'après !).
Mais Linux et glibc collaborent beaucoup pour maintenir une stabilité de l'ABI et éviter ce type de dépendances mutuelles, mais très clairement, tu ne peux pas utiliser de versions trop décolorées (quelques années ça passe, mais après tu commences à courir des risques).
Bref, ce n'est pas si indépendant qu'on pourrait le penser. Ce qui est normal après tout, ces logiciels sont liés car indispensables l'un de l'autre.
[^] # Re: glibc non, systemd peut-être
Posté par gouttegd . Évalué à 2.
Au moins ça correspond à une situation plus vraisemblable (et probablement plus proche de ce que l’auteur de la question avait à l’esprit) que de parler de faire fonctionner « des logiciels d’aujourd’hui avec un Linux 1.0 ».
Ce sont « des appels systèmes » qui nécessitent une version suffisamment récente de la glibc, pas le noyau dans son ensemble. Le noyau reste complètement utilisable sans ça, simplement tes programmes ne bénéficieront pas des toutes dernières fonctionnalités.
C’est pour ça que quand je mets à jour mon noyau, je rajoute toujours une lingette de Decolor Stop®, comme ça ma glibc et mon noyau gardent toutes leurs couleurs éclatantes.
[^] # Re: glibc non, systemd peut-être
Posté par Renault (site web personnel) . Évalué à 3.
Je répondais pour le coup à toto2000 qui revient sans cesse au troll sur systemd sur ce type de sujets alors que ça n'a pas lieu d'être. Le lien entre Linux et l'espace utilisateur n'a jamais été parfait, il y a toujours un couplage nécessaire même si parfois tu as de grandes marges de manœuvre.
Tu peux avoir un couplage plus fort, je n'ai pas remonté l'historique assez loin. Un noyau est forcément dépendant de ce que propose sa libc, la stabilité de se lien et la communication entre les deux projets limite en effet cette problématique. Note que Linux n'est pas compilable sur autre chose qu'un GCC plutôt récent, le couplage est plus fort d'ailleurs entre els deux.
Je pense que tu avais compris que je voulais dire "décorrélé". ;)
Mais je prends note de tes pratiques, je vais m'en inspirer !
[^] # Re: glibc non, systemd peut-être
Posté par gouttegd . Évalué à 2. Dernière modification le 17 avril 2015 à 11:15.
Pas vraiment, non. Ce sont surtout les programmes en espace utilisateur qui dépendent beaucoup de ce que propose la libc.
Il y a plus de couplage entre la glibc et le reste de l’espace utilisateur, qu’entre le noyau et l’espace utilisateur (y compris la glibc).
Ça se traduit par le fait que mettre à jour la glibc est plus délicat que de mettre à jour le noyau : notamment, il n’est pas rare que de nombreux programmes en espace utilisateur doivent carrément être recompilés (pas forcément mis à jour, mais recompilés quand même) contre la nouvelle glibc pour fonctionner, alors qu’une mise à jour du noyau n’impose jamais de recompiler quoi que ce soit (ni la glibc, ni le reste de l’espace utilisateur).
[^] # Re: glibc non, systemd peut-être
Posté par totof2000 . Évalué à 2.
Tu contestes le fait qu'avec systemd tu réduis cette marge de manoeuvre ?
Admettons par exempel que pour un serveur ou un poste e travail ça ne change pas grand chose, parce que les fonctionnalités qui sont gérées par systemd aujourd'hui étaient gérées par d'autres sous-systèmes qui det tpute façon auraint besoin de la bonne version du noyau ou de la libc. Maintenant, prenons le cas d'un système plus minimaliste ne faisant pas appel à toutes ces fonctionnalités : que se passe-t-il alors ? Peut-on par exemple utiliser systemd avec un noyau qui n'aurait pas par exemple les cgroups (ou toute autre fonctionnalité avancée ) d'activés ?
C'est une vraie question, pas un troll : je veux juste avoir si systemd est aussi modulaire que les autres systèmes de démarrage.
[^] # Re: glibc non, systemd peut-être
Posté par xcomcmdr . Évalué à 1. Dernière modification le 19 avril 2015 à 12:27.
Non. Y'a un socle minimum d'API du kernel linux sur lesquels systemd est bâti. C'est à dire avoir un kernel qui est (au maximum, et aujourd'hui) vieux de 2 ans.
En contrepartie, systemd t'apporte bien plus que SysV seul, et te fournit un ensemble d'outils cohérents et intégrés. Plus besoin de bricoler pour un tas de cas d'utilisation déjà couverts.
C'est ça qui séduit dans systemd.
Et puis je doute que le cas "je veux utiliser un kernel vieux de plus de 2 ans et me bricoler un systemd-like avec SysV et Dieu sait quoi de dizaines d'outils disparates tierces" soit très courant.
Moi, j'voudrais savoir si SysV ou Upstart ont ne serait-ce que 50% des fonctionnalités du projet systemd. Rien que de pouvoir tuer un service complexe de manière fiable sans besoin de bricoler avec les cgroups (vu que systemd le fait déjà pour moi), ce serait déjà une énorme avancée… :-p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: glibc non, systemd peut-être
Posté par totof2000 . Évalué à 2.
Ok, 2 ans ça me parait raisonnable.
L'idée que j'ai en tête, c'est l'utilisation d'une distribution "généraliste" dans une carte style raspberry pi, pour lequel par exemple les versions les plus récentes du noyau ne seraient pas supporté (car nécessité de le patcher mais patch pas dispo pour le noyau courant de la distribution), ou sur laquelle on voudrait faire tourner un linux allégé d'un tas de choses dont systemd aurait besoin, mais inutile dans le cas de figure ou on veut utiliser la carte. Le support à 2 ans, comme dit plus haut ne devrait pas poser problème, par contre je crains que systemd ne pousse à intégrer un noyau et des libs inutiles. Mais je me trompe peut-être, et dans ce cas, merci de me le préciser (comme dit plus haut, je ne trolle pas, il s'agit d'un cas d'utilisation plus ou moins courant pour des personnes qui font un peu plus qu'utiliser une distrib serveur ou desktop).
Trop de fonctionnalités tue les fonctionnalités, il y a des cas ou ces fonctionnalités peuvent être inutiles. L'avantage de sysvinit était justement de pouvoir adapter une distrib généraliste à un niveau minimaliste. Personnellement une de mes craintes à propos de systemd, c'est une perte de possibilités de personalisation.
[^] # Re: glibc non, systemd peut-être
Posté par ookaze . Évalué à 3.
Je tourne avec systemd sur Raspberry Pi depuis des mois, aucun problème de ce côté-là.
systemd est parfait pour cela, les options inutiles peuvent être omises à la compilation sans le moindre souci. Les options non disponibles pour cause de bibliothèques manquantes sont automatiquement écartées donc aucun souci non plus.
En revanche, il faut utiliser la glibc, de nombreuses fonctionnalités extrêmement utiles manquent aux libc minimalistes.
C'est faux, trop de fonctionnalités n'a jamais tué les fonctionnalités dans un cas de figure comme celui de systemd. Ces fonctionnalités sont de l'ordre de la commodité, comme des options sur une voiture. Au pire elles ne sont pas utilisées, mais en général, si on les achète, c'est pour les utiliser. systemd c'est pareil, si on ajoute des fonctionnalités, c'est pour les utiliser à priori vu que ça peut (pas toujours) affecter l'empreinte mémoire de certains daemons de systemd.
Les seules bibliothèques requises par systemd sont quasi obligatoires sur tout système GNU/Linux un minimum sécurisé : glibc >= 2.14 (bientôt 2.16), libcap, libmount d'util-linux.
Même dbus est optionnel mais alors systemd devient très compliqué à utiliser, donc je rajouterai quand même dbus en composant supplémentaire perçu comme inutile ailleurs.
Pour un système embarqué, systemd est clairement meilleur que sysvinit auquel s'ajoute au moins un daemon par fonctionnalité de systemd et des tonnes de scripts, l'empreinte mémoire de systemd et ses "aides" est clairement plus faible, principalement parce que beaucoup de fonctionnalités sont partagées et pas dupliquées. J'ai pu dégager des trucs devenus inutiles et clairement inférieurs (moins fiables) comme xinetd, autofs (sauf si la conf est dans LDAP), dhcpcd, mes scripts d'initialisation réseau, l'initialisation du stockage, … Quand je vois le temps que j'ai passé à affiner dhcpcd avec mon firewall et bind afin qu'ils redémarrent correctement en cas de coupure réseau (ça m'a pris des jours avec des horreurs comme des timeout), et la simplicité avec laquelle j'ai fait la même chose avec systemd, c'est consternant.
[^] # Re: glibc non, systemd peut-être
Posté par totof2000 . Évalué à 2.
Merci pour ce retour pratique.
# Rien à faire à part savoir compiler un noyau
Posté par ookaze . Évalué à 2.
TLDR; Il n'y a rien à recompiler, ni glibc, ni systemd.
Si tu veux mettre un noyau 4, sous-entendu non packagé et donc compilé par toi, sur une distribution, il faut que tu maîtrises ta distribution et la compilation du noyau, en particulier les options de compatibilité avec la glibc du noyau et les différences de patch entre le kernel upstream et celui de ta distribution.
Vu que tu utilises la version la plus récente du noyau Linux et que tu parles d'une distribution incluant systemd, il n'y aura aucun autre problème à prévoir.
Si tu veux faire une LFS avec systemd, je suppose que tu utiliseras les versions les plus récentes de la Glibc et de systemd, donc il n'y aura aucun problème non plus.
Excepté qu'il faut connaître les options minimum à placer dans le noyau pour que systemd fonctionne correctement. Je dis ça parce qu'un problème qui revient souvent sur la ML de dév de systemd, c'est que les gens n'ont pas mis l'option CONFIG_FHANDLE dans leur noyau.
# Ok pour moi
Posté par tontonMax . Évalué à 1.
Merci de vos réponses !
même si on est vendredi pas la peine d'essayer de gagner des points Goldwin avec mon post de forum
bisou
# LFS ....
Posté par myou (site web personnel) . Évalué à 1.
Pour la partie de ton message évoquant la construction d'une LFS avec systemd, tu pourras sans aucun problème a la fin mettre un noyau linux 4. Je ne pense pas que cela puisse poser des problèmes particuliers.
Pour mémoire, tu peux trouver la dernière version de LFS-systemd ici et en français en plus ;o).
En lisant ce livre, tu pourras voir que par exemple pour glibc, c'est la version 2.21 qui est utilisée.
Pour systemd, c'est la version 219.
Pour discuter de LFS, je te propose de passer sur notre canal IRC (#lfs-fr sur freenode). Tu pourras avoir les réponses à toutes tes questions, et tu pourras même avoir de l'aide dans ta construction en cas de problème.
A bientôt ;o)
Denis
LFSiste convaincu ;o)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.