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 Kaane . En réponse au journal Linux from scratch face à udev. É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)