le problème, mineur mais bon: le 1er lancement de FF et Thb est très lent, environ 8s. Ensuite ce problème disparaît et les lancements sont très rapides
The problem turned out to be the line exec dbus-launch --exit-with-session blackbox. Using the dbus-update-activation-environment command with just exec blackbox did the trick. Now there is no delay.
Il faudrait donc que j'ajoute la ligne exec xfwm4 à l'aide de la commande dbus-update-activation-environment , soit:
Bonjour, je te déconseille de toucher à la configuration de dbus si tu ne comprends pas l'action de ta modif.
dbus est un élément essentiel du gestionnaire de bureau, utilisé par qausiment tous les logiciels.
Fait des traces pour avoir une idée plus précise du problème au lancement de firefox.
piratebab a écrit : 20 juin 2025, 08:02
Bonjour, je te déconseille de toucher à la configuration de dbus si tu ne comprends pas l'action de ta modif.
dbus est un élément essentiel du gestionnaire de bureau, utilisé par qausiment tous les logiciels.
c'est bien noté, je ne vais donc faire aucun essai de la méthode proposée.
Quant à strace ça m'a tout l'air d'être une commande pour les connaisseurs, donc je vais me contenter de tester
qui me fournira un horodatage permettant de voir si l'exécution se fige ou pas à un endroit précis.... enfin j'espère. Le problème c'est que pour faire un autre essai il faut redémarrer le système, le délai à l'ouverture de FF ne se produisant qu'une seule fois après le démarrage. Mais je vais tester si le changement d'utilisateur suffit à provoquer le phénomène. À voir.
strace est sans danger, ce qui est complexe c'est d'interpréter sa sortie.
Si tu vois un truc du genre FUTEX_WAIT, c'est qu'un programme à posé un verrou sur une ressource dont firefox à besoi,. Il faut attendre la levée de ce verrou. La difficulté est de savoir qui a posé le verrou, et sur quelle ressource.
effectivement, toutes ces lignes ne me disent rien. Une fois enregistrées et triées ça donne 38 lignes qui comportent FUTEX_WAIT, quasiment toutes avec un code retour = -1. J'ai vu, sur stackoverflow.com, que trouver les points de blocage à partir de leur adresse n'était pas une mince affaire. Vu que ce petit problème n'est guère gênant, je laisse la chose en l'état.
bon, ben voilà, problème résolu de matin... par une mise à jour du fameux dbus. C'était donc bien, au moins très probablement, le coupable, et les ceusses de stackexchange.com avaient vu juste. Une hard-freeze n'étant pas encore une stable je suis coupable d'impatience caractérisée.
Je suis quand même étonné que dans une "hard-freeze" il puisse encore y avoir autant de paquets mis à jour.
PS1: j'ai 2 trixie= une sur un ssd autonome et l'autre sur mon ancien portable LDLC. Les mises à jour ne sont pas identiques sur le ssd/trixie et sur le LDLC/trixie .Le défaut a été corrigé sur le LDLC/trixie, avec une mise à jour de dbus, mais il est toujours présent sur l'installation ssd/trixie où dbus n'a pas été mis à jour, du moins ce matin. Le problème c'est que ces mises à jours ne sont pas synchrones, avec des écarts de 1 à 3 jours, pas plus.
PS2: je viens de vérifier: Les versions 1.16.2-2 de dbus sont les mêmes, donc dbus ne doit pas être le seul responsable, son environnement doit intervenir. Y aurait-il une interaction entre dbus et je ne sais quoi dans les composants matériels ou logiciels de "ssd autonome" et de "portable LDLC" qui sont différents? c'est probable, non?
Mieux vaut attendre la version stable, Debian 13, pour comparer. C'est au moins la leçon à tirer de tout ça.
dbus est un bus virtuel lié aux applications de bureau. Il est très loin du matériel.
Tu peux utiliser la commande dbus-monitor pour regarder ce qui se passe sur les bus systeme et session. Comme tu en as un qui fonctionne et pas l'autre, tu pourras comparer.
