La négotiation ne prend pas de temps, on envoie et reçoit (le buffer par défaut de strace ne permet pas logguer l'ensemble des messages, on ne voit pas donc pas quelle "ressource" est demandée [ord.freedesktop...]
La "ressource" demandée n'est pas disponible/ne répond pas:
On essaie une foie encore [flag EAGAIN] et on "poll" avec un timeout de 25000ms. Comme rien ne se passe, on ouvre /etc/passwd une fois ces 25s passées:
# DBUSquer le problème
Posté par ecid . En réponse au message Commande su très très lente. Évalué à 2.
Bonjour,
Voici mon analyse, pour ce qu'elle vaut:
Connexion à /var/run/dbus/system_bus_socket
La négotiation ne prend pas de temps, on envoie et reçoit (le buffer par défaut de strace ne permet pas logguer l'ensemble des messages, on ne voit pas donc pas quelle "ressource" est demandée [ord.freedesktop...]
La "ressource" demandée n'est pas disponible/ne répond pas:
On essaie une foie encore [flag EAGAIN] et on "poll" avec un timeout de 25000ms. Comme rien ne se passe, on ouvre /etc/passwd une fois ces 25s passées:
Voilà pour les 25s de perdues. Reste encore les 4 à 5 secondes restantes:
Après avoir fermé /etc/passwd, on clone le process:
Un peu plus loin, on attend que ce process fils se termine en utilisant wait4(). Cela prend 4.4s
Reste à savoir quelle ressource est demandée via dbus et ce que fait le process fils pour qu'il faille attendre encore 4.4s
Encore du strace en perspective.