Archlinux.fr [Forums]

Bonjour,

Mon interface réseau est configurée avec un adressage IP static. J'ai utilisé la manip que j'ai décrite ici : http://wiki.archlinux.fr/Systemd#R.C3.A9seau

Mon problème est le suivant : il faut que je reboot plusieurs fois avant que je puisse réellement avoir accès au réseau. Dans tous les cas, le service est bien lancé par systemd, mon interface réseau est correctement montée, j'ai la bonne adresse IP, le bon netmask, la bonne passerelle, la configuration DNS est valide, pas d'erreurs dans systemd, mais si je fais un simple "ping ma_passerelle" ou "ping google.com", rien ne sort, impossible de joindre quelque chose même sur mon réseau interne. Je reboot plusieurs fois, sans rien toucher à la configuration, et ça finit par fonctionner.

Avez-vous une idée, une piste que je pourrais suivre ? Il n'y a rien dans les logs.

Je n'aurais jamais autant rebooté cette machine que depuis mon passage à systemd

Quelques questions subsidiaires au passage, moins importantes :

- Puis-je dire à systemd de charger le service réseau avant toute chose, avec le principe de dépendance ? Je trouve ça moche dans les logs de voir des warning comme syslog-ng qui ne se lance pas parce que le réseau ne l'est pas encore (même si le service syslog-ng finit par réussir à lancer syslog-ng quand le réseau devient fonctionnel)

- Mon /var/tmp est un lien symbolique vers /tmp. Apparemment, systemd n'aime pas ça, et refuse de charger le service ntpd avec l'erreur status=226/NAMESPACE. Pourquoi ? J'ai "patché" le problème en remplaçant le lien symbolique par un mount de type bind, mais c'est moche.

- Au démarrage, j'ai le message d'erreur suivant, sans gravité :

Nov 9 05:22:30 localhost dbus[511]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.Avahi.service' for details.

En effet, je n'utilise pas Avahi, qui ne m'est d'aucune utilité. Comment puis-je dire au service dbus de ne pas tenter de le lancer ? Je ne vois pas d'unit nommée dbus-org.freedesktop.Avahi.service

- systemctl disable systemd-journald ne semble avoir aucun effet, sans message d'erreur. Comment puis-je désactiver l'unit systemd-journald ?

- J'utilise kde4 et suis passé en full systemd. Puis-je désactiver console-kit-log-system-start.service ?

Merci !

Tu as vérifié qu'il n'y a pas un autre service réseau qui tourne ?

neves a écrit :- Puis-je dire à systemd de charger le service réseau avant toute chose, avec le principe de dépendance ? Je trouve ça moche dans les logs de voir des warning comme syslog-ng qui ne se lance pas parce que le réseau ne l'est pas encore (même si le service syslog-ng finit par réussir à lancer syslog-ng quand le réseau devient fonctionnel)

M'étonne que syslog-ng ait besoin du réseau.

On peut voir son journal ?

neves a écrit :- systemctl disable systemd-journald ne semble avoir aucun effet, sans message d'erreur. Comment puis-je désactiver l'unit systemd-journald

Je suppose qu'il faudrait le masquer (il est lancé statiquement)... mais attention, si je ne me trompe pas (pas fait l'essai dans ce sens), ça va t'obliger à modifier /etc/syslog-ng/syslog-ng.conf qui par défaut se redirige vers systemd (il te faudra alors modifier unix-dgram("/run/systemd/journal/syslog" en unix-dgram("/dev/log"));.
Par contre, tu peux masquer les autres services qui échouent (car demandées par d'autres services mais dont tu n'as pas l'utilitié, comme plymouth et cie). Rien de bloquant de toutes manières.

neves a écrit :- J'utilise kde4 et suis passé en full systemd. Puis-je désactiver console-kit-log-system-start.service ?

Tu ne devrais même plus l'avoir donc je suppose que oui.

FoolEcho a écrit :Tu as vérifié qu'il n'y a pas un autre service réseau qui tourne ?

Nop il n'y a pas d'autre service réseau (cette machine a toujours été configurée avec une IP statique).

$> systemctl | grep -i network
network.service loaded active exited Network Connectivity
ntpd.service loaded active running Network Time Service
network.target loaded active active Network

FoolEcho a écrit :M'étonne que syslog-ng ait besoin du réseau.
On peut voir son journal ?

En fait il a besoin du réseau parce qu'il centralise les logs d'autres machines, il écoute donc sur un port UDP pour ça.
Je viens de supprimer /var/log/journal pour que les journaux soient dans /run et donc réinitialisé à chaque boot, donc je n'ai plus rien là. Et comme je suis à distance actuellement je ne peux pas rebooter (y'a une chance sur deux pour qu'au reboot la machine n'ai pas le réseau), donc voilà les logs à l'ancienne :

$> grep systemd /var/log/everything.log | grep syslog-ng
Nov 9 05:22:16 localhost [ 19.105021] systemd[1]: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Nov 9 05:22:16 localhost [ 19.106814] systemd[1]: Unit syslog-ng.service entered failed state

Pas beaucoup d'info donc, mais ensuite le service est OK :

$> systemctl status syslog-ng
syslog-ng.service - System Logger Daemon
Loaded: loaded (/usr/lib/systemd/system/syslog-ng.service; enabled)
Active: active (running) since Fri, 2012-11-09 10:56:06 CET; 25min ago
Docs: man:syslog-ng(8)
Main PID: 2897 (syslog-ng)
CGroup: name=systemd:/system/syslog-ng.service
└ 2897 /usr/sbin/syslog-ng -F

(la date de démarrage ne correspond pas aux logs mais c'est normal, j'ai redémarré l'unit entre temps)

FoolEcho a écrit :Je suppose qu'il faudrait le masquer (il est lancé statiquement)... mais attention, si je ne me trompe pas (pas fait l'essai dans ce sens), ça va t'obliger à modifier /etc/syslog-ng/syslog-ng.conf qui par défaut se redirige vers systemd (il te faudra alors modifier unix-dgram("/run/systemd/journal/syslog" en unix-dgram("/dev/log"));.

Ok je vais tenter ça. Pour syslog-ng.conf, pas de soucis, j'ai déjà remis mon syslog-ng perso avec ses filtres et son dispatch de logs là où il faut. D'ailleurs pour ma culture personnelle, peut on monitorer des logs avec fail2ban quand on n'utilise que journald ?

FoolEcho a écrit :Tu ne devrais même plus l'avoir donc je suppose que oui.

Génial, bonne nouvelle, merci !

neves a écrit : - Puis-je dire à systemd de charger le service réseau avant toute chose, avec le principe de dépendance ?

Avant toute chose, je ne sais pas, mais par contre, tu peux lui dire de se charger avant syslog en rajoutant un Before=syslog.service à network.service ou After=network.target à syslog-ng.service.

neves a écrit : - Mon /var/tmp est un lien symbolique vers /tmp. Apparemment, systemd n'aime pas ça, et refuse de charger le service ntpd avec l'erreur status=226/NAMESPACE. Pourquoi ?

Parce que le fichier .service demande à systemd de créer un dossier tmp privé (PrivateTmp=True) qui est un bind d'un dossier dans /var/tmp vers le /tmp dans le workspace du service et qu'un lien l'empêche de le faire.

neves a écrit : Comment puis-je dire au service dbus de ne pas tenter de le lancer ? Je ne vois pas d'unit nommée dbus-org.freedesktop.Avahi.service

C'est pas une unité, c'est /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service.
Si tu n'as pas besoin de avahi, tu peux supprimer le paquet.

neves a écrit : - systemctl disable systemd-journald ne semble avoir aucun effet, sans message d'erreur. Comment puis-je désactiver l'unit systemd-journald ?

Je suis pas sûr que systemd puisse se passer de journald.

En ce qui concerne le réseau, est ce qu'en faisant la configuration manuellement (en dehors de systemd), ça fonctionne à tous les coups?

tuxce a écrit :Avant toute chose, je ne sais pas, mais par contre, tu peux lui dire de se charger avant syslog en rajoutant un Before=syslog.service à network.service ou After=network.target à syslog-ng.service.

Ah, ça c'est bien, merci. Je testerais ça ce soir. Dans le même principe, peut-on imposer un ordre pour les points de montage, pour éviter les x-systemd-automount ?

Ok pour l'explication de PrivateTmp. D'après toi, du coup, quelle est la solution la plus propre ? Laisser /var/tmp en mount/bind sur /tmp ou mettre PrivateTmp=False pour ntpd ? Mon /tmp est une partition chiffrée, je ne souhaite pas que quelque chose écrive dans /var/tmp en clair, et sur mon disque / (/var est sur /) qui n'a plus beaucoup de place.

tuxce a écrit :C'est pas une unité, c'est /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service.

D'accord. Du coup comment je sais que systemd lance ça, en utilisant systemctl ? Y'a-t-il d'autres services du même genre qui n'apparaissent pas quand on fait un "systemctl -a" ?

tuxce a écrit :Si tu n'as pas besoin de avahi, tu peux supprimer le paquet.

A mon grand malheur, je ne pense pas, Avahi est une dépendance pour trop d'autres paquets (libcups donc cups, samba et gtk2/3, etc.). Par contre je peux empêcher le service de se lancer (et d'ailleurs il ne se lance pas avec systemd non plus, mais il essaye et ça fait une erreur. C'est pas important mais c'est pas très joli non plus.

tuxce a écrit :En ce qui concerne le réseau, est ce qu'en faisant la configuration manuellement (en dehors de systemd), ça fonctionne à tous les coups?

Si j'ai démarré avec systemd et que j'ai le problème, je n'arrive pas a rétablir le réseau même manuellement, je n'ai pour l'instant pas trouvé d'autre solution que de rebooter plusieurs fois jusqu'à ce que ça fonctionne de nouveau. La même configuration dans feu rc.conf fonctionnait sans soucis.

neves a écrit :Dans le même principe, peut-on imposer un ordre pour les points de montage, pour éviter les x-systemd-automount ?

La réponse courte serait oui. Ceci dit, ton souci était que le périphérique (/dev/mapper/array-root) n'apparaissait pas, normalement, les unités de montage ont comme dépendance leur périphérique, et vu que tu as rajouté le service lvm qui le fait apparaître (pour info, ce service va être remplacé (cf. lvm2 dans testing)), tu devrais plus avoir besoin de x-systemd-automount.
Pour les dépendances: /etc/fstab sert à générer autant d'unité (.mount , .automount ou .swap) que de dossier à monter, le truc, c'est d'enlever la ligne du /etc/fstab et de créer une unité (le nom de l'unité doit refléter le nom du périphérique) pour monter ce que tu veux avec comme dépendances ce que tu souhaites.

neves a écrit : Ok pour l'explication de PrivateTmp. D'après toi, du coup, quelle est la solution la plus propre ? Laisser /var/tmp en mount/bind sur /tmp ou mettre PrivateTmp=False pour ntpd ?

A part si tu veux modifier tous les .service qui aurait ce flag, un mount en bind me paraît une bonne solution.

neves a écrit : D'accord. Du coup comment je sais que systemd lance ça, en utilisant systemctl ?

Comme tu as dit dans le post d'avant, c'est pas systemd qui le lance, c'est dbus (le .service n'a pas de rapport avec les .service de systemd)
Tu devrais voir si tu n'as pas un service comme par exemple le bluetooth qui tenterait de faire appel à avahi. (mais c'est quand même chercher la petite bête

)

neves a écrit : Y'a-t-il d'autres services du même genre qui n'apparaissent pas quand on fait un "systemctl -a" ?

Tous s'affichent.

neves a écrit : Si j'ai démarré avec systemd et que j'ai le problème, je n'arrive pas a rétablir le réseau même manuellement, je n'ai pour l'instant pas trouvé d'autre solution que de rebooter plusieurs fois jusqu'à ce que ça fonctionne de nouveau. La même configuration dans feu rc.conf fonctionnait sans soucis.

Essaie sans avoir le service et en configurant manuellement.
Parce que je vois pas trop comment ça peut avoir un rapport avec systemd, c'est quand même plus un truc en lien avec le noyau. Sur rc.conf, t'étais avec une autre version de noyau, non ?

Je commence à voir le bout du tunnel dans cette migration à systemd

Pour l'ordre de montage, je ne pensais pas à mon (ancien et maintenant résolu) problème de raid mais plus à mes montages samba, et spécialement à un que je monte dans un dossier du raid. Enfin ça marche en automount donc c'est bon.

En tout cas, l'ajout de After=network.target à /usr/lib/systemd/system/syslog-ng.service a correctement rempli son rôle.

tuxce a écrit :Comme tu as dit dans le post d'avant, c'est pas systemd qui le lance, c'est dbus (le .service n'a pas de rapport avec les .service de systemd)
Tu devrais voir si tu n'as pas un service comme par exemple le bluetooth qui tenterait de faire appel à avahi. (mais c'est quand même chercher la petite bête )

Ok, quand on a compris qu'un .service n'est pas forcement un service systemd, mais peut aussi être un service dbus, tout s'éclaire

Du coup, même si ce n'est plus lié à systemd, comment peut-on lister les services que lance dbus au démarrage de mon PC ?

Pas de bluetooth sur cette machine. La ligne d'erreur au démarrage n'apparait plus en supprimant simplement le fichier que tu m'as indiqué plus tôt, à savoir /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service. Merci ! Mon démarrage est de nouveau clean sans aucun message d'erreurs

Tant qu'on en est à faire du hors-sujet avec dbus, est-ce que j'ai réellement besoin de upowerd, polkitd et udiskd (sur une station de travail fixe, avec kde4 qui les demande peut être) ?

tuxce a écrit :Essaie sans avoir le service et en configurant manuellement.
Parce que je vois pas trop comment ça peut avoir un rapport avec systemd, c'est quand même plus un truc en lien avec le noyau. Sur rc.conf, t'étais avec une autre version de noyau, non ?

J'ai l'air un peu c*n maintenant, parce que je n'arrive plus à reproduire le problème (alors que la nuit dernière c'était vraiment facile). J'ai vu dans les logs un bug du kernel, en effet, qui devait en être la cause ( Une personne a le même problème ici : https://bbs.archlinux.org/viewtopic.php?id=152431 ). Bref, ce n'était pas lié à systemd.

Une dernière question : maintenant que je suis en full systemd, on est d'accord que je peux sans scrupules faire un rm -rf /etc/rc.* ?

neves a écrit :Du coup, même si ce n'est plus lié à systemd, comment peut-on lister les services que lance dbus au démarrage de mon PC ?

dbus ne lance rien. Il permet juste à des services qui s'enregistrent auprès de lui de «se causer» entre elles (après on peut surveiller ce qui s'échange, ou voir ce qui est enregistré via dbus-monitor et cie).

neves a écrit :Tant qu'on en est à faire du hors-sujet avec dbus, est-ce que j'ai réellement besoin de upowerd, polkitd et udiskd (sur une station de travail fixe, avec kde4 qui les demande peut être) ?

Tout ça vient avec kde, donc tu en auras au moins besoin en tant que dépendances.
Maintenant tu peux toujours configurer pour ne pas utiliser tel ou tel composant (ou limiter l'usage), c'est pas ce qui manque avec KDE.
Pour upowerd, il me semble qu'il sert aussi pour l'économiseur d'écran... Pour polkitd, si tu as besoin d'administrer depuis KDE tu en auras besoin... ou pour udisks (pour monter un disque...).
Tu as des infos là-dessus dans le wiki.

neves a écrit :Une dernière question : maintenant que je suis en full systemd, on est d'accord que je peux sans scrupules faire un rm -rf /etc/rc.* ?

Techniquement oui... mais ce n'est pas plus simple d'attendre que les mises à jours futures (courant janvier) procèdent à ce nettoyage plutôt que de casser quelques paquets ?

FoolEcho a écrit :dbus ne lance rien. Il permet juste à des services qui s'enregistrent auprès de lui de «se causer» entre elles (après on peut surveiller ce qui s'échange, ou voir ce qui est enregistré via dbus-monitor et cie).

Ok, systemd lance dbus, puis lance d'autres services qui se servent de dbus. Upower est lancé par systemd via upower.service, Policy Kit via polkit.service et UDisks via udisks.service. Mais du coup, qui essayait de lancer Avahi (org.freedesktop.Avahi.service), si ni systemd ni dbus ne s'en occupait ? J'ai lu que dbus-daemon lançait automatiquement upowerd par exemple ; comment je sais ce que lance dbus-daemon, et les services actuellement enregistrés et exposés par dbus ?
Avec dbus-monitor on peut voir ce qu'il se passe sur dbus, ça fait un peu peur de voir ce qui passe par dbus quand on utilise kde4 (le contenu de mon clipboard en clair par exemple, j'y réfléchirais à deux fois avant de copier/coller un mot de passe maintenant)

FoolEcho a écrit :Tout ça vient avec kde, donc tu en auras au moins besoin en tant que dépendances.
Maintenant tu peux toujours configurer pour ne pas utiliser tel ou tel composant (ou limiter l'usage), c'est pas ce qui manque avec KDE.
Pour upowerd, il me semble qu'il sert aussi pour l'économiseur d'écran... Pour polkitd, si tu as besoin d'administrer depuis KDE tu en auras besoin... ou pour udisks (pour monter un disque...).
Tu as des infos là-dessus dans le wiki.

Ok, après lecture du wiki, udisks est en effet nécessaire pour monter un périphérique USB en tant qu'utilisateur, par exemple. Et il a besoin de polkit. Ce qui m'a induit en erreur quant à l'utilité de polkit, c'est qu'au chargement il écrit :

Nov 10 18:08:50 xxx polkitd[739]: Loading rules from directory /etc/polkit-1/rules.d
Nov 10 18:08:50 xxx polkitd[739]: Loading rules from directory /usr/share/polkit-1/rules.d

et que le premier dossier ne contient qu'un fichier presque vide et le second rien du tout. J'ai donc pensé qu'il était chargé mais ne servait à rien. Je me sentirais plus rassuré si je pouvais me passer de polkit et de la nouvelle surface d'attaque qu'il expose, mais je ne sais pas s'il ne sert que dans ce cas là.

Upower permet le suspend to ram et suspend to disk. Je peux m'en passer s'il ne sert qu'à ça, mais ce n'est pas clair, je ne sais pas vraiment ce qui en dépend.

J'ai pas regardé dans le détail, mais si tu as cups, il y a de fortes chances que ce soit lui qui essaie d'interagir avec avahi (mais bon, à part le côté esthétique que tu sembles chercher, ça n'a aucune incidence).

neves a écrit :Avec dbus-monitor on peut voir ce qu'il se passe sur dbus, ça fait un peu peur de voir ce qui passe par dbus quand on utilise kde4 (le contenu de mon clipboard en clair par exemple, j'y réfléchirais à deux fois avant de copier/coller un mot de passe maintenant)

Ça ne crée pas de failles. C'est sur ta propre session dbus, donc hors root, personne d'autre ne peut y accèder... pareil pour polkit.

Pour voir ce que trafique tel ou tel, tu as par exemple:

Code : Tout sélectionner

journalctl /usr/bin/dbus-daemon

(ou par le PID, etc. voir wiki/man ... vois aussi logind, http://wiki.archlinux.fr/Systemd/logind)

(côté dbus, il y a aussi des utilitaires plus spécifiques... je ne sais plus inspector-quelque-chose, en cherchant des paquets avec dbus comme mot-clé, tu vas en trouver)

FoolEcho a écrit :J'ai pas regardé dans le détail, mais si tu as cups, il y a de fortes chances que ce soit lui qui essaie d'interagir avec avahi (mais bon, à part le côté esthétique que tu sembles chercher, ça n'a aucune incidence).

Je n'utilise pas Cups, ça ne doit pas être lui. En fait je ne cherche pas que le côté esthétique d'un chargement propre sans erreur, je cherche surtout à comprendre exactement qui lance quoi et surtout comment sur ma machine.

FoolEcho a écrit :Ça ne crée pas de failles. C'est sur ta propre session dbus, donc hors root, personne d'autre ne peut y accèder... pareil pour polkit.

Oui bien sûr, heureusement qu'on ne peut pas espionner le dbus d'un autre utilisateur. On peut très bien imaginer le scénario où un attaquant récupère un accès sur une machine (il a le mot de passe SSH de l'utilisateur, ou il utilise une faille quelconque dans un logiciel de l'utilisateur) et espionne le dbus de l'utilisateur pour récupérer d'autres mots de passe qu'il n'a pas, en clair. C'est un peu comme laisser son mot de passe root dans son .bash_history après une fausse manip'

Là où avant il fallait modifier (sur le disque ou en mémoire) un processus pour pouvoir espionner le clipboard, il suffit maintenant de regarder ce qui passe par dbus (sous KDE4, aucune idée si c'est pareil sous Gnome). C'était possible avant, c'est facilité avec dbus. Enfin bref c'est un détail

Quant à polkit, il ne créé pas de faille actuellement, mais entre utiliser su/sudo pour faire des tâches d'administration, et su/sudo ET polkit, on augmente logiquement la surface d'attaque dans le second cas. Et comme su/sudo n'est pas près de disparaitre, autant ne rien ajouter de plus, surtout si ça ne sert pas (ce qui ne semble malheureusement pas être le cas).

FoolEcho a écrit :Pour voir ce que trafique tel ou tel, tu as par exemple: journalctl /usr/bin/dbus-daemon

Ouaip c'est justement en lisant le journal que je me suis interrogé sur le chargement de avahi, upower, udisk et polkit par dbus.

Tout ça n'a plus rien à voir avec systemd ... Il serait peut être meilleur d'avoir d'autres topics, non ? Au minimum pour avoir plus de visibilité au lieu de mélanger la configuration de tous les softs.

Tout ce que tu décris, tu l'avais aussi avant. Utiliser kde implique utiliser dbus, donc la recherche d'Avahi existait avant, upower et polkit aussi de même que tout ce qui transitait par dbus.
Du coup, je ne comprends pas bien, tu avais enlevé tout ça avant ?

Pour la question de sécurité, en plus de ce qu'a dit FoolEcho, tu sais que n'importe quel programme ayant accès à X peut avoir ce que tu tapes sur le clavier, y compris ce que tu tapes dans les fenêtres demandant des mot de passe ? Et ça, ce n'est ni dbus, ni systemd, encore moins polkit, c'est inhérent à X !

neves a écrit :Quant à polkit, il ne créé pas de faille actuellement, mais entre utiliser su/sudo pour faire des tâches d'administration, et su/sudo ET polkit, on augmente logiquement la surface d'attaque dans le second cas. Et comme su/sudo n'est pas près de disparaitre, autant ne rien ajouter de plus, surtout si ça ne sert pas (ce qui ne semble malheureusement pas être le cas).

Ils n'ont pas du tout le même but, mais comme dit avant, d'autres topic seraient bienvenus.

tuxce a écrit :Tout ça n'a plus rien à voir avec systemd ... Il serait peut être meilleur d'avoir d'autres topics, non ? Au minimum pour avoir plus de visibilité au lieu de mélanger la configuration de tous les softs.

Tout à fait.

Enfin il reste toujours une question concernant systemd (enfin je crois) : qui voulait lancer le service dbus avahi ?

tuxce a écrit :Tout ce que tu décris, tu l'avais aussi avant. Utiliser kde implique utiliser dbus, donc la recherche d'Avahi existait avant, upower et polkit aussi de même que tout ce qui transitait par dbus.
Du coup, je ne comprends pas bien, tu avais enlevé tout ça avant ?

Je n'ai pas dis le contraire

C'est juste que le passage à systemd m'a fait m’intéresser à dbus. Mais en effet ça ne devrait plus être sous ce même topic. Pour KDE j'avais réussis à désactiver avahi, akonadi et nepomuk, mais j'étais déçu d'avoir laissé polkit par exemple.

tuxce a écrit :Pour la question de sécurité, en plus de ce qu'a dit FoolEcho, tu sais que n'importe quel programme ayant accès à X peut avoir ce que tu tapes sur le clavier, y compris ce que tu tapes dans les fenêtres demandant des mot de passe ? Et ça, ce n'est ni dbus, ni systemd, encore moins polkit, c'est inhérent à X !

Je n'ai pas dis le contraire non plus. Mais on ne justifie pas un problème en disant qu'il existe ailleurs. Et la différence ici c'est qu'avec dbus il suffit de taper dbus-monitor, c'est quand même simple.

neves a écrit :Enfin il reste toujours une question concernant systemd (enfin je crois) : qui voulait lancer le service dbus avahi ?

Encore une fois (oui je sais, c'est pas forcément clair

), ce n'est pas systemd et pour essayer d'expliquer:
Il existe une session dbus (pour ce qui nous intéresse, la session system), n'importe quel soft peut se connecter à cette session, voir tout ce qui y est exposé et essayer d'y faire appel. En l'occurrence, un soft voit qu'Avahi y est et essaie d'y faire appel, ce à quoi dbus qui voit que le programme n'est pas démarré, tente de le faire, ce qui passe par systemd, et là, vu que tu ne l'as pas activé, systemd répond par la négative et avahi n'est pas démarré.

Maintenant, quel soft y fait appel, il y en a tellement qui le peuvent ... Déjà, quand est ce que le message apparaît, suite à quoi etc.

neves a écrit :Je n'ai pas dis le contraire non plus. Mais on ne justifie pas un problème en disant qu'il existe ailleurs. Et la différence ici c'est qu'avec dbus il suffit de taper dbus-monitor, c'est quand même simple.

C'est pas une question de justification, mais plutôt de hiérarchie. X, tu peux pas t'en passer (si t'utilises une interface graphique), et en l'occurrence, j'appelle vraiment ça une faille.
Pour le copie coller, il est censé être clair pour qui veut accéder à ce qui a été copié, je vois pas pourquoi tu bloquerais un de tes processus d'accéder au copie coller. D'ailleurs, par défaut, un dbus-monitor par ssh ne regarde que sa session, pas celle sur X.

tuxce a écrit :Encore une fois (oui je sais, c'est pas forcément clair ), ce n'est pas systemd et pour essayer d'expliquer:
Il existe une session dbus (pour ce qui nous intéresse, la session system), n'importe quel soft peut se connecter à cette session, voir tout ce qui y est exposé et essayer d'y faire appel. En l'occurrence, un soft voit qu'Avahi y est et essaie d'y faire appel, ce à quoi dbus qui voit que le programme n'est pas démarré, tente de le faire, ce qui passe par systemd, et là, vu que tu ne l'as pas activé, systemd répond par la négative et avahi n'est pas démarré.

Maintenant, quel soft y fait appel, il y en a tellement qui le peuvent ... Déjà, quand est ce que le message apparaît, suite à quoi etc.

Hum, ok. Comme tu le précises toi-même, c'est pas forcément clair

On en revient à dbus donc, je ne sais pas aujourd'hui comment voir ce qu'il expose, ou qui essaye d'utiliser des services qu'il expose.

tuxce a écrit :D'ailleurs, par défaut, un dbus-monitor par ssh ne regarde que sa session, pas celle sur X.

Mouais, par défaut oui, mais bon "DISPLAY=:0 dbus-monitor | grep -A 4 klipper" et c'est contourné, ça reste simple. Enfin bref c'était une anecdote, pas le but de mes questions dbus

Ce qu'il expose, tu le vois dans /usr/share/dbus-1/system-services/. Les softs qui sont susceptibles de faire appel à un de ces services sont tous ceux qui dépendent (même de manière optionnelle) des paquets fournissant ces services.

Archlinux.fr [Forums]

[systemd] réseau, /var/tmp, avahi, consolekit, dbus

[systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau aléatoirement fonctionnel

Re: [systemd] réseau aléatoirement fonctionnel

Re: [systemd] réseau aléatoirement fonctionnel

Re: [systemd] réseau aléatoirement fonctionnel

Re: [systemd] réseau aléatoirement fonctionnel

Re: [systemd] réseau, /var/tmp, avahi, consolekit

Re: [systemd] réseau, /var/tmp, avahi, consolekit

Re: [systemd] réseau, /var/tmp, avahi, consolekit

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus

Re: [systemd] réseau, /var/tmp, avahi, consolekit, dbus