Sommaire
Bonjour à tous,
Puisqu'il est à nouveau question d'udev ici, il ne me semble pas inutile de résumer les échanges qui ont eu lieu sur la liste de discussion de linux from scratch au mois de mai.
Ces échanges me semblent intéressants car ils montrent en quoi le fork d'udev a pu paraître nécessaire. À moins qu'ils ne montrent au contraire que le fork d'udev n'était pas nécessaire.
Je vous en laisse seuls juges.
L'annonce
Tout a commencé un Vendredi, le 25 mai, par un mail d' Armin K. :
Systemd announce mail arrived today and I'll just post some highlights from Change Log.
Le changelog d'udev indique que désormais, les sources d'udev sont incorporées à systemd, et que systemd doit être compilé pour pouvoir compiler udev :
All udev sources are merged into the systemd source tree now. All future udev development will happen in the systemd tree. It is still fully supported to use the udev daemon and tools without systemd running, like in initramfs or other init systems. Building udev though, will require the build of the systemd tree, but udev can be properly run without systemd.
Or, si udev a besoin de systemd, systemd a besoin quant à lui de dbus et de libcap pour compiler, et Bruce Dubbs s'attriste de devoir introduire dbus à LFS :
We'll need to add dbus to LFS. :( I suppose we will need to do a minimal install in LFS and a more complete install with all the bells and whistles in BLFS.
Jeremy Huntwork propose d'utiliser des alternatives à udev, telle mdev, de busybox. Mais Ken Moffat rappelle que xorg – comme nombre d'applications graphiques – ne peut fonctionner sans udev.
Bryan Kadzban propose alors de modifier l'archive de systemd/udev, pour pouvoir n'installer qu'udev :
Maybe we can hack up the systemd package to install just udev, if there's no option to do that today? It'd be annoying to have to maintain that diff though.
Markku Pesonen espère que ce problème de dépendance de compilation soit résolu upstream, et rappelle que, dans la liste de discussion d'udev, Key Sievers affirmait qu'udev continuerait à pouvoir être compilé comme avant, malgré son incorporation à systemd :
After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly. Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build.
Bruce Dubbs rappelle alors les dépendances de compilation de systemd – dépendances qui n'ont aucune autre utilité sur LFS :
- It wants intltool
- It wants intltool's dependency XML::Parser
- It wants libpcap2 and implicitly it's dependency attr
- It wants pkgconfig but that can be worked around
- It wants usbutils and it's dependency libusb
- It wants pciutils
- It wants D-Bus
And that's just to get through configure.
The problem is that none of these libraries are used for udev.
Comme il le dira plus tard, il est opposé à installer toutes ces dépendances dans LFS rien que pour compiler un paquet qui ne sera pas utilisé :
I am opposed to adding extra libraries to LFS just to satisfy systemd configure requirements for code we are not going to use.
Jeremy Huntwork propose d'insister pour que upstream fasse quelque chose :
Perhaps the best solution is to complain loudly to upstream and hope that enough do so that they build into the package the ability to build and install only the udev components as they said would be possible.
Mais Bruce Dubbs doute que cela soit efficace, et préfère créer un nouveau makefile à udev, makefile qui évite la dépendance de compilation qu'est systemd.
I may do that, but they really haven't been too receptive. I'm going to look to see what is in the 'common' library that udev needs, but doesn't need all those extra libraries. I may be able to just create a custom Makefile that builds/installs just what we need without going through autotools or configure.
Le patch
Dan Nicholson propose alors un patch du système de compilation d'udev, qui pourra être envoyé upstream :
Have any of you guys considered actually making patches and sending them upstream? The autotools are not that scary. Having been both upstream and downstream, my guess is that those guys will accept patches that allow a udev-only build, but they just don't have any interest in doing that work themselves. I'm sure there are more than a few people around who are interested in that scenario (they're already showing up on the hotplug list) who would test and push for the patches. If it's that critical to keep systemd out of LFS, then you'd probably be best served by taking control of the situation. IMO.
Here's an untested patch to get you started.
L'équipe de LFS travaille alors sur le patch… Tout en regrettant que l'équipe d'udev ne s'en soit pas tenue à ses affirmations, ainsi Andrew Benton rappelle la rude vérité :
When they merged udev and systemd they said that it'd be possible to install just udev without systemd but with the very first merged release it is impossible to install udev without all of systemd's dependencies…
Néanmoins, le patch progresse, de sorte que, une semaine après l'incorporation de dbus à systemd, l'équipe de lfs parvient à passer l'étape de la configuration avec son patch, et c'est Andrew Benton qui l'annonce :
It helps. I can get through configure Ok, but I can't see a way to get through make without dbus.
Reste donc à gérer la dépendance à dbus…
La résolution des dépendances
Mais Bruce Dubbs rappelle que, même avec ce patch, la compilation d'udev suppose néanmoins l'installation de pkg-config, qui dépend quant à lui de python :
To answer a question you may not be up to speed on, we don't install pkg-config in lfs because the pkg-config developers inconveniently made it depend on glib. The dependencies are : glib (required), libffi (required), Python (required), pkg-config (recursive, but can work around). We are in the position of needing to install four packages (one incomplete) just to satisfy the systemd build methodology that requires things we don't need for udev.
Il propose de créer un nouveau makefile pour udev plutôt qu'un patch. Mais Andrew Benton lui répond qu'il préfère un patch qui puisse être appliqué upstream.
Se pose alors la question d'ajouter pkg-config à LFS. Le fait qu'il dépende de python est bloquant, et installer une version plus ancienne soulèverait trop de difficultés. In fine, l'équipe trouve un remplaçant à pkg-config – pkg-config-lite, qui a beaucoup moins de dépendances. Aujourd'hui il sembe néanmoins que ce soit pkg-config et non pas pkg-config-lite qui ait été incorporé à LFS.
La solution
Finalement, la même journée, Bruce Dubbs annonce que le patch fonctionne.
Try the attached patch. It ran with only one minor warning (easily fixed) in install.sh from the lfs chapter 6 environment.
Après quelques modifications, et de nombreux tests, Bruce Dubbs décide d'incorporer le patch à LFS :
I rebooted and udev from systemd seems to work with the patch. I think the patch is good. If someone (Matt?) can test and confirm that it works, I'll put it in the book.
Dorénavant, LFS maintient donc un patch permettant à udev de compiler sans systemd, et fournit un paquet contenant une archive d'udev patchée. Je n'ai pas trouvé trace, dans la liste de discussion de LFS, de tentatives d'envoyer ce patch upstream.
# Xorg peut fonctionner sans udev
Posté par Yann LD . Évalué à 9.
C'est faux, Xorg peut très bien fonctionner sans udev, la configuration des périphérique se fait alors de façon moins automatisée (il faut créer manuellement le fichier de conf d'xorg).
[^] # Re: Xorg peut fonctionner sans udev
Posté par Sygne (site web personnel) . Évalué à 7.
Voici ce que dit le mail en question :
J'ai donc résumé un peu trop radicalement le message, je le reconnais.
[^] # Re: Xorg peut fonctionner sans udev
Posté par Damien Thébault . Évalué à 3.
evdev est une interface linux kernel <-> user-space pour les périphériques d'entrée, ainsi que le nom du module kernel qui gère la fonctionnalité, ainsi que le nom d'un module Xorg qui gère la fonctionnalité.
En ce qui concerne la partie linux (module + interface + création du device dans /dev/), evdev n'a besoin de rien. On peut très bien utiliser devtmpfs, mdev ou mknod pour créer les fichiers dans /dev/.
En ce qui concerne la partie Xorg, on peut le configurer dans /etc/X11/xorg.conf, dans une Section "InputDevice" avec Driver "evdev".
Il y a un paramètre "Device" qui permet de renseigner le chemin du device evdev.
En plus de ça, si on veut se passer du xorg.conf, on peut utiliser l'autodétection qui utilisera alors udev depuis Xorg 1.8. Cette autodétection est désactivable si besoin.
Autant utiliser les drivers kbd et mouse est effectivement à éviter, evdev étant supérieur en tous points, autant on peut se passer de udev si on veut.
[^] # Re: Xorg peut fonctionner sans udev
Posté par Sygne (site web personnel) . Évalué à 2.
Et le libudev.pc dont il est question dans le mail, qu'est-ce que c'est ?
[^] # Re: Xorg peut fonctionner sans udev
Posté par Batchyx . Évalué à 2.
Je dirais même plus: Il n'y a pas que le driver evdev qui utilise les interfaces evdev: le driver synaptics (et wacom?) supporte lui aussi (entre autres) evdev, mais offre d'autres fonctionnalités plus pertinentes pour le type de périphérique.
Bon après, j'ai cru lire que ces deux là vont se mettre à utiliser un "future udev backend" … sans doute pour l'autodetection. Mais le xf86-input-synaptics que tu utilise actuellement utilise bien evdev sans avoir besoin d'udev.
[^] # Re: Xorg peut fonctionner sans udev
Posté par Grunt . Évalué à 7.
Hé mais c'est trop bien ça :)
Il était utile le fichier de conf de Xorg !
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Conclusion
Posté par Zenitram (site web personnel) . Évalué à -10.
Beaucoup de bruit pour rien, plutôt que de troller il est plus utile et simple de patcher pour répondre au besoin. Il est pas beau le libre?
[^] # Re: Conclusion
Posté par needs . Évalué à 10. Dernière modification le 05 septembre 2012 à 21:44.
On peut aussi constater à quel point systemd est une plaie pour ces gens là, ils veulent simplement avoir un gestionnaire de périphériques et ils doivent ce démerder avec un gestionnaire de 'services' ?
Et un patch, c'est dur a maintenir car il faut sans-cesse l'adapter à l'upstream, vérifier son fonctionnement etc … Je pense qu'ils s'en seraient bien passé.
Donc non, ce n'est pas beaucoup de bruit pour rien, c'est un réel problème comme le montre bien ce journal, les devs de LFS sont pris au piège car apparemment ils ne peuvent pas utiliser mdev car udev est une dépendance obligatoire de
xf86-input-evdevet dans une moindre mesure de Chromium (source) et ils ce passeraient bien de systemd. Qui à dit que Lennart n'imposait pas son choix ?[^] # Re: Conclusion
Posté par gnumdk (site web personnel) . Évalué à 10.
En même temps, si le but de LFS c'est d'avoir un Linux aux petits oignons sans outils neuneu proof, je vois pas pourquoi ils veulent udev qui a quand même été la première brique vers tout ce qui a suivi… (pour avoir un linux qui fait tout à ta place).
[^] # Re: Conclusion
Posté par Yth (Mastodon) . Évalué à 8.
Parce que evdev c'est plutôt bien, et que udev c'est plutôt efficace aussi ?
Parce que LFS ne cherchent pas à avoir un système minimal, mais un système performant et hautement paramétrable à la fois ?
udev à mon sens ce n'est pas avoir un Linux qui fait tout tout seul à ta place, mais avoir un Linux que tu peux configurer efficacement pour gérer les évènements matériels à chaud.
C'est un outil qui peut être utilisé pour faire plein de choses derrière, mais ce n'est qu'un outil, ce n'est pas lui qui décide de ce qui est fait des évènements matériels, c'est toi qui lui dit ce qu'il doit faire, donc udev ne fait rien à ta place, il te permet de faire des choses.
Yth.
# Questions
Posté par Dreamkey . Évalué à 7.
Bonjour,
est-ce que vous pourriez m'expliquer pourquoi systemd est-il si critiqué ? J'ai bien compris qu'il lui est reproché d'être un gros paquet de code qui essaye de faire le café, qu'il n'est que linux-compatible et que Lennart est un bon trolleur, mais pourquoi ne serait-il pas une alternative viable sur le long terme, c'est-à-dire une fois qu'il se sera peaufiné après quelques versions ?
Même question pour dbus, Bruce Dubbs ne paraît pas aimer devoir l'inclure, mais est-ce "juste" parce qu'avant il était possible de construire LFS sans ? J'avoue ne pas avoir saisi son utilité, comment faisait-on avant ?
Et finalement idem pour pkg-config : je me doute bien que l'inclusion d'udev dans systemd ne soit pas rajouter un "make -C udev/" dans le makefile de systemd, donc qu'est-ce qui justifie l'utilisation de pkg-config pour construire udev ?
En tout cas merci de la dépêche bien détaillée :)
[^] # Re: Questions
Posté par detail_pratique . Évalué à -2.
J'ai également une question : est-ce que vous pourriez m'expliquer ce que veut dire bronsonisé ?
[^] # Re: Questions
Posté par nonas . Évalué à -2.
Il dit qu'il a plus de genoux.
[^] # Re: Questions
Posté par Sygne (site web personnel) . Évalué à 8.
Bonjour,
il y a des réponses à vos questions éparpillées dans la liste de discussion depuis le mois de mai, et jusqu'à aujourd'hui. Voici ce dont je me souviens grosso modo, car j'ai la mémoire courte, et aussi parce que beaucoup de détails m'échappent.
Nombre d'arguments touchent à l'image que se font les développeurs de leur projet (LFS) et de systemd. Et ils ont l'impression que systemd ne convient pas à l'esprit de LFS.
Plus pragmatique est l'argument des dépendances. Elles sont nombreuses pour systemd, et sur LFS, ces dépendances ne seront installées que pour systemd (donc uniquement pour le démarrage du système), ce qui ne fait pas grand sens.
N'oublions pas qu'en outre, sur LFS, les dépendances de compilation sont nécessairement installées, ainsi que les dépendances de ces dépendances, etc. La petite LFS deviendrait obèse d'un coup, beaucoup plus longue à installer.
Il est reproché à Dbus d'être un démon inutile sur LFS.
Quant à pkg-config, c'est une dépendance de compilation décidée upstream. Les développeurs de LFS auraient pu l'outrepasser, mais ils ont choisi de créer un patch plutôt qu'un nouveau makefile. Il y a eu plusieurs échanges à ce sujet en mai, où l'on voit qu'ils ont hésité sur la procédure à suivre. On y voit aussi qu'ils ne comprennent pas pourquoi upstream utilise pkg-config pour un logiciel réservé à linux.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 2.
Comme je le dis plus haut, j'aimerai bien savoir en quoi udev est un démon utile pour LFS, ca me trou vraiment le cul! Genre, Linux From Scratch, ca veut pas dire se taper les mknod à la main quand on rajoute un niveau périph?
Pff, les distribs pour barbu, c'est plus ce que c'était…
[^] # Re: Questions
Posté par Anthony Jaguenaud . Évalué à 10.
Bah, c’est pas parce que tu construis un système embarqué aux petits oignons, que tu ne doives pas mettre en place ce qu’il faut pour que l’utilisateur puisse insérer à chaud un clé usb par exemple. Et franchement, entre udev et hotplug, il n’y a pas photo.
Mais on parle bien de deux choses différentes, un mécanisme pour configurer les périphériques connectés à chaud et le système de démarrage. Un peu comme si, tu insérais la lecture du jpeg dans le noyau parce que c’est trop cool, comme ça, ta lib elle est toute petite.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 5.
Moi, à ta place, j'aurai dit LibreOffice dans le noyau, plus c'est gros, plus ca passe…
Sinon, tu crois vraiment qu'on peut pas insérer une clé USB à chaud sans udev ?
[^] # Re: Questions
Posté par Kaane . Évalué à 10.
est-ce que vous pourriez m'expliquer pourquoi systemd est-il si critiqué ?
De nombreuses raisons, mais voici les principales :
sytemd ne dialogue vraiment qu'avec dbus, si dbus ne se lance pas la machine n'a plus d'init, ou tout du moins plus un init normal, ce qui implique de faire des tests doublé pour la cohérence d'état des machines, un ou dbus démarre, un ou dbus ne démarre pas (ou pas au moment attendu). En plus le coté dialogue exclusif avec dbus nécessite l'utilisation d'un client dbus avec de gros droits si on veut pouvoir traquer un bug qui se déclare à l'init. Cette outil devra être exempt des sécurités cgroups et devra pouvoir accéder à tous les services. Ca fait une faille potentielle de plus.
systemd n'est pas compatible avec autre chose que Linux, et même pas avec autre chose que GNU/Linux à la sauce Red Hat. Bon nombre de configuration de type disques chiffrés/partition délocalisées/configuration dynamique ne sont tout simplement plus possible avec systemd qui s'attend à ce que certains éléments soient à une place bien précise avec des droits bien précis et un ordre de démarrage fixe. Notament au niveau du réseau on retrouve des défauts qui apparaissaient déjà sur networkmanager, par exemple quand il faut d'abord créer un lien VPN (PPTP, GRE ou autre) AVANT de créer une carte réseau et de lancer la couche TCP/IP. De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer le moindre démon. C'est con pour Oracle par exempel qui a besoin de prendre le controle de certains points de montage en RAW et dont le montage normal ne sert qu'au debug et au cold backup. A partir de là systemd prive linux de choses importantes qu'il sait faire (et même bien faire) aujorud'hui - et il oblige en plus les devs à créer plusiseurs version de leur script d'init en fonction de la machine sur laquelle ils sont supposés s'éxecuter.
systemd pose un problème aux outils de contrôle : un truc aussi bête que apachectl devient un casse tête avec systemd, plusieurs utilisateurs peuvent controller le logiciel apache avec cet outil. Mais alors quid de systemd ? Est-ce qu'on ajoute des fonctionnalité DBus à l'outil pour lui permettre de dialoguer avec systemd pour lui dire "au fait le recharge la config" ou est-ce que l'on fait ça dans son dos en esperant qu'ils ne panique pas en voyant les processus apaches se fermer et s'ouvrir du fait d'appels à un outils qui n'est pas dans le même cgroup ? Ou alors est-ce que l'on met tout le monde dans le même cgroup, auquel cas quand on essaye de tuer un apache planté on commence par tuer l'outil qui permet d'interragir avec apache ?
(Bon pour apache les soucis sont résolus rapidement, mais pour tomcat déjà ca se complique et je ne parle pas d'Erlang ou d'autres applis distribuées)
chat échaudé craint l'eau froide : C'est pas comme si les "nouvelles API qui tuent tout" avaient une espérance de vie limité sous Linux, mais ca fait quand même 5 fois en 10 ans que l'on change complètement le paradigme d'acès au périphériques. Linux n'a pas une super réputation sur la pérénité de ses api, et pas mal de mainteneurs commencent sérieusement à en avoir marre de réinventer la roue. Devoir refaire toute la config à cause de polkit/consolekit/udev/hal qui s'enva/dbus/systemd ca amuse 5 minutes, mais là ca fait 3 ans.
Pour l'instant à moins d'une évolution très très léchée du produit par RH on est toujours obligé de gruiker les scripts pour que systemd fasse ce dont tu as besoin et pas ce qu'il veut, notamment pour les processus qui forkent dans tous les sens et qui n'ont pas de support natif de DBus. Et comme DNS, Apache et Postfix ne sont pas supposé en avoir quoi que ce soit à faire de systemd (et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs) ils n'auront probablement jamais de support DBus.
En fait une application unique ne peut pas faire la surveillance/le controle/le restart etc. de toutes les applis possibles et imaginables dans toutes les config possibles et imaginables - ca parait évident dit comme ça mais c'est pourtant ce qu'il essaye de faire. Donc systemd échouera, ou se pervertira jusqu'à avoir autant d'exception et de boilerplates que ses ancètres. Le test grandeur nature est juste une couteuse perte de temps.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 5. Dernière modification le 06 septembre 2012 à 00:28.
Dbus est lancé par systemd après syslog sous Arch alors j'aimerai bien savoir comment tu m'expliques ton argument pourri…
Non systemd peu utiliser dbus pour le lancement des services mais il ne dialogue pas en interne avec dbus.
Donc effectivement, si dbus ne se lance pas, la condition tel interface dbus existe ne pourra pas être vérifiée et sera ignorée. Mais c'est un plus par rapport à sysvinit donc paye ta critique…
Comme udev
On continue dans le n'importe quoi, si tes démons n'ont pas le Wants=local-fs.target, tes fs locaux ne seront pas montés sauf si:
" In addition, systemd adds dependencies of type Wants to this target unit for those mounts listed in /etc/fstab that have the auto and comment=systemd.mount mount options set."
Et en gros, si je comprend bien ton argumentation, les programmes qui ne supportent pas DBus ne fonctionne pas avec systemd, et la marmotte…
Le dialogue avec systemd se fait via socket, pas via dbus qui n'est utilisé que pour valider des conditions!
[^] # Re: Questions
Posté par Kaane . Évalué à 10.
Dbus est lancé par systemd après syslog sous Arch alors j'aimerai bien savoir comment tu m'expliques ton argument pourri…
En fait tout en dans la définition du mot "dialogue". Tant que DBus n'est pas lancé, systemd est sourd. Pas moyen de lui expliquer que tu rajoutes des worker tomcat, pas moyen de lui faire comprendre que tu vas faire un restart manuel avec d'autres paramètres de tels ou tels daemon, pas moyen de lui demander d'arréter de surveiller tel ou tel daemon qui va rentrer en maintenance.
systemd peut agir sur le système, mais le système ne peut pas agir sur lui. Pas de dialogue donc…
Non systemd peu utiliser dbus pour le lancement des services mais il ne dialogue pas en interne avec dbus.
Si si, c'est même comme ça qu'il valide le bon lancement de certaines applis. Par des dialogues avec DBus. Dés que tu as un BusName ou un NotifyAccess dans systemd c'est du dialogue de DBus. Dans cet article écrit par un des plus grand détracteur de systemd que je connaisse c'est très bien expliqué : http://0pointer.de/blog/projects/systemd-for-admins-3.html
Donc effectivement, si dbus ne se lance pas, la condition tel interface dbus existe ne pourra pas être vérifiée et sera ignorée
Et tous les scripts ayant un BusName ou un NotifyAccess dans leur config auront un comportement potentiellement différent et à valider en test.
Comme udev
udev n'existe que sous Linux, mais a un comportement POSIX. Les appels udev sont assez faciles à remplacer par des appels équivalents sous d'autres OS raisonnablement posix.
On continue dans le n'importe quoi, si tes démons n'ont pas le Wants=local-fs.target, tes fs locaux ne seront pas montés sauf si:
Erreur, les wants permettent de définir ce dont on a besoin, pas ce dont on ne veut pas. Si je veux que mon unit arrivent dans un systeme ou "tartempion" n'existe pas, il faut que j'active dans mon script "before = tartampion" ou alors si plusieurs daemon peuvent remplir une condition faire des "Wanted-By = ", sauf que dans le cas de local-fs.target tu l'as dans l'os. Quoi qu'il arrive systemd executera quand même cet unit quand il en a besoin (même si par exemple le daemon qui déchiffre les données n'est pas actif sur une partition chiffré)
Avec Wants=local-fs.target tout ce que j'ai c'est que mes disques locaux ne seront peut-être pas monté. Mais peut-être que si.
Et en gros, si je comprend bien ton argumentation, les programmes qui ne supportent pas DBus ne fonctionne pas avec systemd, et la marmotte…
Ils peuvent être lancé par systemd, mais toutes les fonctions de controle, d'altération, de controle fin etc. ne fonctionneront pas. Donc oui, pas de DBus => appli de controle à part en dehors de systemd.
Le dialogue avec systemd se fait via socket, pas via dbus qui n'est utilisé que pour valider des conditions!
Euh… Non.
Les sockets dans systemd servent à remplacer inetd, moyennant la perte de certaines fonctionnalité, ou des patchs de code ou autres.
Le socket /run/systemd/private est désormais créé par dbus_server_listen (je te laisse deviner sur quelle outil il s'appuie).
Sans DBus systemd est sourd. (Et systemctl ne marche plus)
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 1.
J'avais encore un doute sur le fait que tu ais raison…
Sauf que j'ai testé hier:
- systemctl stop dbus.service
- systemctl stop dbus.socket
dbus est alors coupé
et oh, ca fonctionne et dbus est tjs coupé.
[^] # Re: Questions
Posté par Miguel Moquillon (site web personnel) . Évalué à 8.
Toi, tu ne sais lire que ce qui t'arrange :
Alors lorsqu'il écrit "Et systemctl ne marche plus", ceci signifie tout simplement que ce pourquoi il a été fait ne marche pas (ou plus comme il se doit).
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 7.
Moi ce que je comprend du document de Lennart, c'est que systemd utilise dbus pour mieux controller les processus, en gros, il utilise un service dbus pour savoir quel process il a forké…
Mais cette fonctionnalité n'est valable que pour les process démarré après dbus…
POur les autres, il utilise, attention au magie, un fichier service.pid dans /run comme le faisait sysvinit dans /var/run.
Mais je ne pense pas dans l'exemple de abrt que ce soit systemd qui crée com.redhat.abrt, il s'en sert c'est tout.
Donc en gros, il utilise dbus pour controller des process linké à libdbus, donc si dbus est planté avec sysvinit on avait un démon lancé alors que ce dont il a besoin ne fonctionne pas, avec systemd un process non lancé parce que ce dont il a besoin n'a pas réussi à se lancer.
J'aimerai donc savoir ou est le problème, car je ne le comprend pas.
[^] # Re: Questions
Posté par Kaane . Évalué à 7.
et oh, ca fonctionne et dbus est tjs coupé.
Oui les sockets ont déjà été ouverte par DBus et donc systemsctl peut dialoguer avec systemd.
Maintenant désinstalle DBus et essaye de faire quoi que ce soit.
Ca ne marche pas.
Il faut donc un DBus installé et fonctionnel au moment du boot pour que systemd puisse dialogeur avec systemctl et il faut un dbus actif et fonctionnel pour pouvoir ajouter des watchers/controles/processus dans un cgroup liés à systemd après le boot.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 7.
Hein ? Tu sais comment fonctionne dbus.
C'est pas systemctl -> systemd
C'est obligatoirement systemctl -> dbus-daemon -> systemd donc si dbus ne tourne pas, rien ne tourne… Ce qui n'est pas le cas…
Je viens de faire un:
mv /usr/bin/dbus-daemon /root
Je reboot et magie systemctl fonctionne toujours…
[^] # Re: Questions
Posté par Kaane . Évalué à 2.
Hein ? Tu sais comment fonctionne dbus.
Oui.
C'est pas systemctl -> systemd - C'est obligatoirement systemctl -> dbus-daemon -> systemd
Non.
Je viens de faire un:
mv /usr/bin/dbus-daemon /root
Je reboot et magie systemctl fonctionne toujours…
Donc il y a eu un fallback de rajouté au moins pour systemctl. C'est une bonne chose, plus il y a d'exception dans le truc, plus vite il meurt.
Par contre existe-t-il un moyen de signifier quelquechose à systemd autrement que via DBus (ie pour tous les programmes qui ne sont pas systemsctl) ?
J'avoue volontier avoir très peu investi dans systemd, j'ai regardé, j'ai pas aimé, j'ai arrété.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 0.
Tiens donc, et ça fonctionne comment ? Je sens qu'on va rire…
[^] # Re: Questions
Posté par Kaane . Évalué à 4.
Tiens donc, et ça fonctionne comment ? Je sens qu'on va rire…
Ca s'appelle le mode peer-to-peer en créant via dbus des DirectConnections.
Ensuite même si DBus tombe la connexion tient. (Juste que pour la retrouver et s'y inscrire bonjour).
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 06 septembre 2012 à 13:12.
Ah ben on y vient, c'est c'est comme cela que systemd fonctionne mais cela n'a absolument rien à voir avec dbus-daemon!
«Handles a peer to peer connection between two applications withou a bus daemon.»
Et donc du coup, ton premier argument:
>si dbus ne se lance pas la machine n'a plus d'init
était un gros mensonge, histoire de faire peur à tout le monde, c'est bien, tu viens de t'auto fusiller…
Ou alors, tu voulais dire que Lennart n'aurait pas du utiliser libdbus et recoder un système d'IPC à la main ? SUPER!
Et vient pas me dire que libdbus peut faire segfaulter systemd, parce que cette argument fonctionne aussi avec dash qui peut segfaulter pour une raison x ou y…
[^] # Re: Questions
Posté par Kaane . Évalué à 6.
parce que cette argument fonctionne aussi avec dash qui peut segfaulter pour une raison x ou y…
Tout à fait, c'est d'ailleurs pour ça qu'on utilise pas dash dans les scripts d'init mais sh. Enfin chez les vrai OS en tout cas.
Ou alors, tu voulais dire que Lennart n'aurait pas du utiliser libdbus et recoder un système d'IPC à la main ? SUPER!
Il fait comme il veut du moment que mon executable est compilé en statique est peut se lancer en mode recovery quand seule la partition racine remonte.
était un gros mensonge, histoire de faire peur à tout le monde, c'est bien, tu viens de t'auto fusiller…
Pas un mensonge, sans dbus l'init est inexistant. Sans dbus-daemon, ou si le service n'a pas un support dbus explicite les controles sont très réduits.
Avoir un init c'est pas juste pouvoir lancer et arreter des processus…
[^] # Re: Questions
Posté par Ignatz Ledebur . Évalué à 1.
Euh… dash c'est sh (c'est un port du sh de NetBSD). Tu pensais à bash j'imagine ?
[^] # Re: Questions
Posté par Kaane . Évalué à 2.
Euh… dash c'est sh (c'est un port du sh de NetBSD). Tu pensais à bash j'imagine ?
dash c'est le port de ash si je me souviens bien. C'est vrai qu'il est très léger et très POSIX, ceci dit je n'invoquerais quand même pas dash directement dans mes scripts.
[^] # Re: Questions
Posté par Ignatz Ledebur . Évalué à 0.
Tu m'as fait douter. J'ai donc été zieuté les sources du sh de NetBSD et leur sh est bien un descendant de ash :
Ils ont même conservé le fichier TOUR, attestant de la parenté :
En fait, à ma connaissance, il n'y a pas de descendance à sh. J'avais lu que Bourne détestait le C et avait ainsi joué du pré-processeur pour rapprocher la syntaxe de base du Pascal, rendant le résultat non-maintenable.
Mais bon, j'ai peut-être à tort supposé depuis ton avatar que tu utilisais un *BSD. Peut-être d'autres OS ont-ils d'autres sh non-issus de ash. Tiens ce qui me fait penser… bin, non raté, même chez Busybox, leur ash n'est pas original (il est basé sur dash). :)
[^] # Re: Questions
Posté par Kaane . Évalué à 2.
j'ai peut-être à tort supposé depuis ton avatar que tu utilisais un *BSD
Ah mais je suis totalement BSDiste, viral et barbu comme l'indique mon avatar, et mon /bin/sh de référence est celui de FreeBSD. Je ne crois pas que ce soit un dash ou un ash.
Mais bon l'idée était surtout trollesque - je m'attendais à ce que mon interlocuteur revienne à la charge en me disant que dans mon sh aussi il pouvait y avoir du segfault. Bon après comparer la probabilité de problème entre une appli complète lié à libdbus et une rikiki sh ca aurait été drole.
Ca a pas pris - dommage.
[^] # Re: Questions
Posté par Ignatz Ledebur . Évalué à 1.
Après vérification, le sh de freeBSD est aussi un ash, comme celui de DragonflyBSD, et comme l'était celui OpenBSD avant qu'ils ne le dégagent. À part MirBSD qui a un ksh entièrement maison en sh, il semble que les *BSD aient choisi de bâtir sur l'héritage du code de Berkeley. Le bon vieux principe if it ain't broken, don't fix it, probablement (qui nous ramène subrepticement à systemd).
[^] # Re: Questions
Posté par Prosper . Évalué à 4.
En gros tu trolles comme un goret.
[^] # Re: Questions
Posté par Alex . Évalué à 4.
mdr
Mais c'est un effet assez classique, d'où l'importance d'une première version utilisable
Je me suis rendu compte de la même chose au sujet de java: je trollais modérément ("java est une version raté de smalltalk") en avançant mes arguments (gestion de io, cast vers obj, dépendance dans les jars, etc…).
On m'a fait constater que la plupart des problèmes avaient été corrigés depuis les dernières fois où j'avais été contraint d'utilisé java.
[^] # Re: Questions
Posté par gnumdk (site web personnel) . Évalué à 1.
Je suis relativement convaincu que systemd gère cela depuis le début.
En regardant le code rapidement, il semble qu'il utilise libdbus pour communiquer en interne sur un socket: /var/run/systemd/private et c'est pour cela qu'il demande à dbus-daemon quand il le lance d'utiliser le même socket.
Après, je peux me tromper sur cette analyse à l'arrache du code…
Mais le service dbus-daemon n'a aucun influence sur le fonctionnement de systemd et systemctl.
[^] # Re: Questions
Posté par Kaane . Évalué à 7.
Mais le service dbus-daemon n'a aucun influence sur le fonctionnement de systemd et systemctl.
Très honnêtement, et même si ca a été corrigé depuis apparament, systemd avait besoin de DBus pour démarrer pleinement au départ.
Ensuite la place du socket a été déplacée, les ouvertures de sockets se faisaient de façon légèrement différente d'une version sur l'autre et au final pas mal de gens ont eu droit au fabuleux :
Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
Ceci dit ca fait plaisir que DBus créée maintenant lui même son propre socket (et ca rassure un peu aussi, parcequ'un programme qui prétend pouvoir créer des sockets pour tout le monde mais qui utilise DBus pour fabriquer le sien ca fait un peu peur.)
Pour rentrer à nouveau dans le troll, quid de tous les autres points mentionnés ?
[^] # Re: Questions
Posté par Zenitram (site web personnel) . Évalué à 0.
Heureusement qu'un certain Linux T. n'a pas attendu que son OS soit sans aucun bug avant de le sortir…
C'est une critique sur les gens : regarder une fois, et garder sa critique en étant persuadé que rien n'a changé en 10 ans. Si on fait la même chose pour Linux? Ca ferait peur…
[^] # Re: Questions
Posté par Alex . Évalué à 2.
Pas une question de bogues, mais une question d'être utilisable
Si ça ne marche pas, on passe à autre chose (99% du temps) ou on améliore (1%)
[^] # Re: Questions
Posté par Zenitram (site web personnel) . Évalué à 3.
Ca a l'air de bien marcher pour pas mal de monde… Donc c'est bon pour systemd, qui remplit sa mission malgré les 1% de râleurs.
[^] # Re: Questions
Posté par Alex . Évalué à 3.
je me perd entre tout ces posts
tu sais ce qu'on dit:
1% pour
1% contre
le reste s'en fout (modulo si ça ne marche vraiment pas, à ce moment il n'y aura que des raleurs)
ceux qui se font entendre sont très souvent les râleurs
Les gens qui ont la compétence pour encenser ou critiquer systemd sont à prioris des utilisateurs avancés. Certains ont surement des particularités sur leur système (la partition chiffré en est une) qui ne marcheront pas avec systemd, il est donc logique de trouver plus de râleur ici
Ensuite dans les râleurs il y a ceux qui n'aime simplement pas l’esprit de l'outil
Ensuite il y a les pseudos suisses, comme moi, qui râle et encense en même temps, jsuis pas fan du coté bloat, mais je trouve l'outil pratique
[^] # Re: Questions
Posté par Thomas Douillard . Évalué à 4.
Il a un certain talent pour faire ça tout en récoltant des +10 de manière très fréquente, c'est pas donné à tout le monde.
[^] # Re: Questions
Posté par Ontologia (site web personnel) . Évalué à 3.
Typique de LinuxFr : avis bien argumenté, bien structuré, avec un raisonnement en apparence solide (car ce fut surement le cas à une époque).
A contrario, j'ai vu nombre d'idées intéressantes se faire jeter car mal présentées.
Toujours le même principe : il faut mâcher le boulot du lecteur, la difficulté de comprendre le message est déjà bien suffisante à ses yeux…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Questions
Posté par Misc (site web personnel) . Évalué à 3.
En même temps, la discussion, même basé sur des arguments faux, reste pertinente dans le sens ou ça a un rapport avec le sujet. Et le commentaire, même faux, n'est pas inutile car il permet de présenter des contre vérités ce qui permet de les dissiper.
( sinon, pour avoir +10, faut aussi faire des blagues, ça marche bien )
[^] # Re: Questions
Posté par Yth (Mastodon) . Évalué à 9.
D'un autre côté, un commentaire mal écrit et difficilement compréhensible est moins utile pour le débat qu'un commentaire mieux rédigé, même si le premier contient au fond plus d'éléments pertinents.
On est ici pour communiquer les uns avec les autres, si on communique bien on inclus plus de monde dans le débat et on fait avancer les choses, si on communique mal peu de gens vont suivre et on sclérose le débat.
Donc un commentaire bien rédigé est logiquement, à contenu équivalent, plus « pertinent » qu'un commentaire écrit avec les orteils.
Si Linuxfr reste un site important, c'est aussi parce que la qualité moyenne (en terme de rédaction, de qualité du français utilisé) des commentaires (et surtout des dépêches et journaux), est assez élevée. En gros, ya pas de langage SMS, les textes sont lisibles, bien présentés et bien écrit : le site vit, prospère et gagne en qualité.
Et la communauté Linuxfr dans son ensemble est consciente de ça et « récompense » les bonnes rédactions et les argumentations claires (même si erronées), en « punissant » les commentaires écrit à l'arrache, agressif, ou trollesques.
Et comme on n'est pas non plus là pour se prendre la gueule, et que plus un sujet est sérieux plus il faut l'appréhender avec humour et user de dérision pour désamorcer les trolls et ne pas se raidir sur des avis tranchés, l'humour bien ciblé est lui aussi récompensé.
Yth, en résumé : « si tu sais pas écrire français, comment tu veux que je te comprenne ? ».
[^] # Re: Questions
Posté par dlewin . Évalué à 5. Dernière modification le 07 septembre 2012 à 11:49.
Je confirme car c'est qui me donne l'envie de revenir et m'informer régulièrement ici. Cet échange est véritablement intéressant pour moi qui souhaite toujours apprendre plus sur Linux ainsi que LFS.
Et d'ailleurs je confirme "ne pas se raidir sur des avis tranchés" par mon ressenti lorsque je lis :
ou
(dans un autre commentaire un peu plus bas) que je trouve franchement gratuits. Parfois quand quelqu'un réfute un argument je trouve inutile et désagréable cette impression de "tais-toi et apprends" même s'il à raison, et c'est bien le cas ici.
PS: et si je peux me permettre :
"Si tu ne sais pas écrire Français, comment veux-tu que je te comprenne"
[^] # Re: Questions
Posté par Ignatz Ledebur . Évalué à 3.
C'est un anglicisme. On met une majuscule au substantif quand on parle des gens mais jamais à l'adjectif : «C'est un Français» mais «il est français». C'est une erreur courante quand on lit pas mal d'anglais (nom commun pas de majuscule, gnarf! — oui, oui, je compatis)…
[^] # Re: Questions
Posté par Anonyme . Évalué à 0.
Et toi tu es tellement plus intelligent que les autres membres du site que tu ne tombe pas dans le panneau, bien sur !
[^] # Re: Questions
Posté par rewind (Mastodon) . Évalué à 7.
Ou alors, Lennart inventera une manière de définir des comportements spéciaux, donc un langage de script, et on sera revenu à ce qu'on connaît.
Des fois, je me demande si RH ne fait pas tout ce cirque (que ce soit GNOME3, systemd et tous les trucs un peu chelou de ces dernières années qui sont morts en moins de 10 ans) pour toujours conserver une longueur d'avance sur ses concurrents et pour avoir la maîtrise du truc. Il faudrait faire un historique des projets ratés lancés par RH, je crois qu'on risque d'être surpris.
[^] # Re: Questions
Posté par Misc (site web personnel) . Évalué à 6.
Tu sembles avoir une vision faussé de ce que font les cgroups.
Je te conseille de lire ça http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
puis de voir la doc de lxc, puis de voir que lxc utilise les cgroups, mais que les cgroups ne sont pas lxc.
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. Ensuite, tu peux utiliser selinux, chroot, lxc pour isoler les processes, mais tu va pas demander quand même à isoler un process mais vouloir que tout le monde puisse y toucher.
je te conseille aussi de lire la doc de systemd sur les montages ( genre, le montage en non auto ), et aussi d'avoir ton vocabulaire au point, tu crées pas une carte réseau, tu crées au mieux une interface réseau ( la carte réseau étant pour moi un objet physique ). 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 ).
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", j'ai le sentiment que tu confonds un peu tout.
Quand à avoir un script d'init par machine, que dire à part que c'est soit déjà le cas ( si tu veux un truc propre ), soit pas une chose que systemd va changer, car tu peux encore déposer ton script compatible LSB dans /etc/init.d comme avant. La preuve, c'est que tout n'a pas été migré sur une fedora 17.
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.
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.
Et donc, ton histoire de rajouter du boilerplate sachant que systemd est sorti depuis au moins 1 an, tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ? ( car affirmer, c'est une chose, mais avec des preuves, ça serait sans doute plus crédible, et ça serait pas de trop )
[^] # Re: Questions
Posté par Kaane . É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.
[^] # Re: Questions
Posté par Misc (site web personnel) . Évalué à 5.
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 :
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Moving_a_Process_to_a_Control_Group.html
En fait, la méthode à base de echo, elle est furieusement semblable à ce que tu doit sans doute faire en écrivant dans un fichier la liste des PIDs. ( et sincèrement, ne dit pas "j'ai pas le temps d'apprendre". Si on a le temps de poster sur linuxfr, on a le temps de lire la doc )
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". Voir même, tu peux lancer un script shell via systemd. Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
http://kezhong.wordpress.com/2011/11/19/creating-my-own-systemd-service-files-on-fedora-16x86_64/
pareil, moteur de recherche, temps, linuxfr, etc
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère. En te démerdant bien, systemctl isolate doit même pouvoir faire des trucs plus chiadés qui devrait te permettre de faire encore plus complexe. Ou attends, même mieux, tu changes la config, et tu recharge le service. Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Mais sans doute qu'il y a une raison non exprimé qui fait que faire la même chose, ça va pas marcher ?
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é ). Ou tu le fait via modprobe.conf, pour lancer le script avant de charger le module pour ip ( tout comme certaines distros font pour alsa, pour charger le volume, ou pour les firmwares ). 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 ( à commencer par toi, en fait ), et pourtant, tu es pas bloqué le moins du monde. En fait, tu peux aussi juste rajoute rune unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire, ça va pas casser à l'upgrade d'un rpm. Marvelous, non ?
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp ), la réponse est "la même chose que si tu as lancé apache via xinetd", vu que ( http://0pointer.de/blog/projects/inetd.html ) c'est le même système. En d'autres termes, tout comme lancer apache via xinetd va pas marcher si tu lance apache à coté une 2eme fois ( vu que le port tcp va être ouvert par xinetd ou systemd ), ça va pas marcher des masses de faire ça via systemd.
Mais comme la config par défaut pour apache, c'est justement de faire lancer apachectl ( ou plutot httpd -k ), le souci ne se poseras pas par défaut. Et en fait, si tu configures ça pour marcher en mode socket et que tu utilises le script qui est prévu pour marcher avec l'autre mode ( ie standalone ), c'est plus toi qui fait exprès un truc qui ne va pas marcher par design du mode xinetd d'apache ( ie le souci n'est pas lié à systemd, vu qu'il se pose aussi . Comme se dire "bah j'utilise nginx, pourquoi apachectl marche pas". Réponse, parce que tu as 2 modes différents pas prévus pour être mélangés dans apache, et c'est à apache de gérer le cas comme il faut.
En pratique, le mode inetd n'est plus dans apache 2 ( plus de directive ServerType cf http://httpd.apache.org/docs/2.0/en/upgrading.html ), et donc, ton exemple reste un exemple purement théorique. Mais tu peux continuer à dire que systemd fait mal les choses car les programmes peuvent proposer 2 modes incompatibles de lancement.
Sinon, je voit pas de boilerplate ajouté dans systemd dans tes exemples, je vois juste du boilerplate que tu as ajouté dans ton système, ce qui pour moi est différent ( ie, tu es responsable des kludges que tu fait, le reste du monde s'arrange pour faire des trucs propres ).
[^] # Re: Questions
Posté par Kaane . É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'aimedont 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 Misc (site web personnel) . É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 ).
[^] # Re: Questions
Posté par Kaane . Évalué à 3.
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".
Allez hop zou juste avec OpenVPN qui est une des solutions soutenue par Fedora/RH :
1) On peut pas lancer tout un tas de tunnels en une seule commande (un peu con pour le PPoE+VPN)
https://bugzilla.redhat.com/show_bug.cgi?id=744244
En fait on ne peut même pas activer les services dont les fichiers de conf sont basés sur des templates :
https://bugzilla.redhat.com/show_bug.cgi?id=752774
Au final il faut créer les liens symboliques à la main si on veut plusieurs VPN/VNC/VSFTPD etc. Toute la lourdeur des vieux sysvInit au service de la rigidité systemd.
Confirmé sur le site officiel de Fedora : http://fedoraproject.org/wiki/Openvpn, à partir de Fedora16 il faut éditer les liens symboliques à la main…
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 ?
Interfaces actives, possibilité d'envoyer et de recevoir des trames.
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.
Le truc c'est que ca fait beaucoup trop.
J'ai besoin d'activer iptables AVANT tcp/ip (enfin besoin est un bien grand mot - disons que ca m'évite de patienter/tuer dhclient à la main et de relancer les scripts à la main.) Sauf systemd a besoin que tout network remonte d'un bloc (sinon il panique).
Voici ce que je voudrais qu'il se passe :
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) chargement des iptables (dont j'ai besoin pour mes VPN)
c) connection pptp
d) connection VPN
e) chargement IP et initialisation de la couche IP pour int0
Ce qu'il se passe
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) Tout network rapplique avec IP et tout le toutim
c) chargement de iptables
c - en parallèle et je peux rien y changer) La couche IP s'initialise pour int0, dhclient commence à tourner dans le vide
d) connection pptp
e) connection VPN : echec vu que IP et dhclient ont déjà la main sur int0
f) login prompt
g) à la mano on down int0
h) à la mano on relance VPN
i) à la mano on up int0
Alors bien sur on peut tricher en ne créant le bridge et le VPN qu'une fois que tout le reste a démarré, mais ca ralenti le boot, et les config deviennent chiante à lire, surtout qu'il ne faut pas oublier d'effacer/refaire les liens symboliques en cas de changement.
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload.
Et tu fais ca comment en systemd ? Il y a deux reload en systemd
systemctl nomduservice reload -> recharge la config compilée pour nomduservice, ignore complètement le fichier ini
systemctl daemon-reload -> recompile toutes les configs de tous les services activés.
Ben que je suis en maintenance, je ne veux ni l'un ni l'autre et il n'y en a pas de troisième.
ATTENTION : systemctl enable et systemctl disable lancent aussi une recompilation de toutes les configs.
Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part"
Et comment je dis à systemd de faire un reload d'un service mais avec un autre fichier de config ? J'ai 0 commande pour le faire, le seul truc que je peux faire c'est créer à la main des liens symboliques, éteindre le service et le relancer avec un autre nom en utilisant la conf du lien symbolique. Mais faire un reload depuis un nouveau fichier de config n'est pas possible en systemd (et vu la gestion des dépendances auto-évaluées ca ne le sera probablement jamais.)
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
Sans sytemd je suis propre (un seul fichier coherent avec lui même qui gère tout ce qui a besoin d'être pris en compte du début à la fin) avec systemd je ne sais pas faire. Donc oui je sauvegarde des fichiers temporaires et je les lits dans un autre script et oui c'est crade et oui je voudrais faire autrement, mais je peux pas.
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".
a) C'est pas que la version "utilise le fichier PID" ne me plait pas, au contraire j'adorerai l'utiliser. C'est qu'elle ne marche pas vu que systemd ne relit pas le fichier régulièrement. Il le lit une fois, met les infos en mémoire et c'est fini.
b) Faire plusieurs unit ne fonctionne pas non plus.
En init classique mon premier programme de synchro récupère pleins de paramètres et lance le second programme avec ces paramètres. Hors je ne sais pas passer de paramètres d'une unit à l'autre en systemd. (Et là pourtant j'ai cherché) setenv ne fonctionne que dans l'inti et est accessible à tous les enfants (donc vachement pratique si on veut lancer plusieurs serveurs).
Pour finir j'ai pas besoin d'une unit pour le logiciel de sync, qui va nécessairement s’arrêter et qui n'a jamais besoin d'être lancé seul (limite ca serait même une très mauvaise idée).
Comme je suppose que tu va me dire "j'utilise pas pam"
Si j'utilise pam, mais le problème n'est pas là. C'est très bien que pam déplace les instance sshd d'un cgroup à l'autre. Mais ca me rajoute encore un truc de plus pour que ca fonctionne normalement. Et en plus même si j'ai pam, tout le monde ne se logue pas nécessairement via pam. Si je me logue par certif il se passe quoi ? Et par kerberos ? Et par ldap ? Et si le process d'authentification n'est pas sur la même machine que le ssh ? Et si c'est même pas un linux ?
Est-ce que ca marche si j'oblige tout le monde à passer par pam et que j'utilise les modules pam-* qui vont bien ? Et quand je met à jour il se passe quoi ?
Le truc c'est pas que ce soit impossible, c'est que ca me complique horriblement la vie. Et j'aime pas monter une usine à gaz pour retomber sur exactement le même résultat qu'avant.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner),
Ca doit pas être trop difficile à deviner vu que tu t'en sors.
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
Oui mais si on reprend les point précédents, à savoir
- systemd ne lance pas automatiquement les fichiers basé sur templates, il faut rajouter les liens symboliques à la main
- chaque serveur peut avoir plusieurs workers, donc plusieurs processus et j'aimerais bien tuer tous les processus d'un serveur sans abimer les autres (par exemple relancer tomcat admin mais pas les applis)
- les fichiers de config ne sont pas raffraichits automatiquement quand on les modifie.
Tu mets tout ça ensemble et tu arrives a des situations sympas avec ta solution :
Par exemple si un dev veut modifier le catalina ou créer un nouveau serveur, il faut qu'il te passe un coup de fil (ou qu'il ait les droits admin - et ça, c'est pas possible).
Comment tomcat admin va-t-il faire pour raccrocher les wagons ? Qu'est-ce qu'il se passe si je relance un site depuis tomcat-admin et pas depuis systemctl ?
Si j'ai un worker qui déconne ? Comment je le tue ? (je veux dire à part avec les droits root et un bon gros SIGKILL dans sa face) ?
etc. etc.
# je vais dire une betise, mais de mon temps on avait des options à ./configure
Posté par NeoX . Évalué à 10.
on pouvait dire --exclude libaexclure ou --without-libaexclure
et là on ne pourrait pas faire pareil avec la configuration de udev et lui dire
pour ne plus avoir les dependances ?
mince alors, les bonnes habitudes se perdent :(
[^] # Re: je vais dire une betise, mais de mon temps on avait des options à ./configure
Posté par Anthony Jaguenaud . Évalué à 8.
Ça c’était l’époque ou les gens essayé de mutualiser le code : une et une seule libjpeg, une libgif… aujourd’hui, tu as un gros binaire qui contient tous les formats. « Mais comprenez que c’est pour votre bien, il y a des options non gérés par la lib.
— N’auriez-vous pas pu discuter avec les dév de la lib en question.
— Non, quand je leur ai dit que leur lib était merdique, ils ont rien voulu savoir. »
Voilà ce que devient l’écosystème GNU/Linux, en tous les cas l’impression que ça donne. Plus de respect, les gens sont pressés de rattraper les OS privateurs, et du coup fonce sans chercher à mutualiser grand chose. Freedesktop c’était bien, mais tout le monde ne l’applique pas. À commencer par systemd qui met les logs ailleurs que dans /var si j’ai bien compris.
Ça existe toujours, de pouvoir configurer, mais le monsieur SystemD il en a rien a foutre, il a décidé que c’était mieux comme ça. De là à supposer que c’est par incompétence, je laisserai le sujet à nos trolleurs.
[^] # Re: je vais dire une betise, mais de mon temps on avait des options à ./configure
Posté par gnumdk (site web personnel) . Évalué à 3.
Non, t'as rien compris, il les mets dans un tmpfs tant que tu n'a pas créer /var/log/systemd…
Ce qui est logique, sur un desktop, j'ai pas besoin de logrotate et compagnie, les logs de la session en cours me sont largement suffisant.
[^] # Re: je vais dire une betise, mais de mon temps on avait des options à ./configure
Posté par Anthony Jaguenaud . Évalué à 5.
Ok, merci.
Pourquoi ne ferait-il pas un log rotate tout seul comme un grand ? Genre sur 2-3 sessions. Parce que en cas de crash sur une session, c’est trop cool de pas savoir ce qui est arrivé ;-)
[^] # Re: je vais dire une betise, mais de mon temps on avait des options à ./configure
Posté par gnumdk (site web personnel) . Évalué à 1.
Ben a ce moment là tu crée le dossier… Enfin c'est sous Arch hein, j'imagine que sous Fedora, le dossier /var/log/systemd existe par défaut.
[^] # Re: je vais dire une betise, mais de mon temps on avait des options à ./configure
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Une bonne lecture à ce sujet (en anglais) : A Generation Lost in the Bazaar par PHK.
# résumé
Posté par pralines . Évalué à -1.
si j'ai bien suivi : systemd a besoin de Dbus, mais Dbus est utile (et quasiment obligatoire) pour d'autres composants, donc la fusion nous oblige à installer systemd
les dev de Dbus avaient plus ou moins promis que la fusion n'empêcherait pas l'usage de Dbus sans systemd, mais dans les faits, pour compiler Dbus il faut compiler systemd et toutes ses dépendances, dans le meilleur des cas on peut conserver l'ancien init mais on se retrouve tout de même avec systemd installé…
avec de telles pratiques, la prochaine étape c'est Gnome (et sa galaxie d'applications) qui va nécessiter systemd (Ubuntu et son upstart ne vont pas être content :-)
bon c'est pas la mort, si c'est un mauvais choix le retour en arrière est possible (le plus tôt sera le mieux), ça c'est déjà vu
en attendant (et avant qu'on arrive Gnome OS) il reste des alternatives : petites distribs (les gars de LFS ont déjà fait un script pour compiler Dbus sans systemd, il sera peut-être repris par d'autres) et BSD…
mais ce qui est regrettable, c'est qu'une bonne partie de ces "discussions" autour de systemd (et de cette fusion) sont du gaspillage de temps et d'énergies qui seraient probablement mieux employés
et si les dev de Dbus veulent refiler leur bébé ou bénéficier de l'aide de Redhat, c'est leur droit, mais ça serait bien de le dire clairement au lieu de laisser tout le monde s'interroger sur des théories complotistes et d'alimenter les trolls et les flamewars
Envoyé depuis mon Archlinux
[^] # Re: résumé
Posté par allcolor (site web personnel) . Évalué à 6.
Apparemment non, tu confonds udev et dbus dejà…
[^] # Re: résumé
Posté par pralines . Évalué à -3.
MDR :-)
Envoyé depuis mon Archlinux
[^] # Re: résumé
Posté par nud . Évalué à 1.
Tu n'as pas bien suivi.
Non, la fusion oblige juste à compiler systemd, mais udev reste fonctionnellement indépendant.
Non, On peut toujours utiliser dbus sans systemd… Le problème est ici udev, qui est compilé avec systemd, qui nécessite la libdbus.
Non, Gnome utilise juste de certaines interfaces dbus simples implémentées par systemd et qui pourraient être implémentées par d'autres démons de la même façon (genre org.freedestktop.hostname1). On ne peut pas même parler de dépendance: si tu n'as pas de démon qui implémente cette interface tu peux juste pas changer ton hostname depuis la GUI.
Non, dbus a pas besoin de systemd, c'est udev qui a été fusionné, pas dbus.
[^] # Re: résumé
Posté par pralines . Évalué à 0.
première chose, dans mon commentaire il faut remplacer tous les "dbus" par "udev" (bévue qui n'aide pas à faire avancer le schmilblick…)
ensuite,
ok, la compilation donne des binaires indépendants, mais on a bien :
tout dépends de ce qu'on entend par "installer",
(avant le travail de LFS) pour avoir udev, il faut compiler systemd, donc systemd (et ses dépendances) est bel et bien présent dans le système, même si il n'est pas démarré,
c'est bien ce qui est reproché à l'opération de fusion systemd/udev non ?
Envoyé depuis mon Archlinux
[^] # Re: résumé
Posté par nud . Évalué à 2.
make vs make install.
Compiler quelque chose n'impose pas de l'installer, par contre cela impose d'installer toutes les dépendances de compilation. C'est le problème mentionné ici: le mainteneur de lfs ne veut pas installer systemd mais la fusion lui impose d'installer les dépendances de compilation de celui-ci, qui comprennent la libdbus.
Après il pourrait probablement installer la libdbus sans installer le dbus complet, comme c'est déjà le cas sur une debian serveur par exemple.
[^] # Re: résumé
Posté par pralines . Évalué à 0.
vu, merci
j'avais "presque" compris/suivi… :-) :-) :-)
Envoyé depuis mon Archlinux
[^] # Re: résumé
Posté par claudex . Évalué à 3.
Ce que fait d'ailleurs Ubuntu avec upstart.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.