Bonjour !
J'ai installé hier une Debian 12 en remplacement d'une Debian plus
ancienne. C'est une installation à partir de zéro, pas une mise à  jour.
Mon gestionnaire de fenêtres est fvwm.
Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis
quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment.
Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
okular, etc.).
Quand j'appelle "strace pavucontrol", les messages cessent de défiler
en arrivant à la dernière des lignes copiées-collées ci-dessous :
[...]
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)Â Â = 11
futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
(Resource temporarily unavailable)
futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
write(10, "\1\0\0\0\0\0\0\0", 8)Â Â Â Â Â Â Â = 8
futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=11, events=POLLIN}], 1, 25000
Sitôt le délai (25000) passé, pavucontrol s'ouvre.
Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ?
Merci pour vos conseils !
Seb.
Le 09/11/2023 à 11:34, Seb a écrit :
poll([{fd=11, events=POLLIN}], 1, 25000Là il attend un évènement sur le file descripteur 11, il faudrait
Sitôt le délai (25000) passé, pavucontrol s'ouvre.
Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins
d'une direction dans laquelle chercher ?
repérer au dessus un appel open (ou nom approchant) que retourne 11
pour voir à quelle ressource ça correspond
Bonjour,
poll([{fd=11, events=POLLIN}], 1, 25000Là il attend un évènement sur le file descripteur 11, il faudrait
repérer au dessus un appel open (ou nom approchant) que retourne 11
pour voir à quelle ressource ça correspond
J'ai redirigé la sortie de strace vers un fichier "trace".
Ensuite:
~/temp> egrep 'poll.*fd=11|^open.*= 11' trace | cat -n
    1   poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    2   poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    3   poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    4   poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    5   poll([{fd=11, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
    6   openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache",
O_RDONLY) = 11
    7   openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
    8   openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so",
O_RDONLY|O_CLOEXEC) = 11
    9   openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so", O_RDONLY|O_CLOEXEC)
= 11
    [...]
C'est le "poll" de la ligne 5 qui bloque.
Je ne vois donc pas d'openat renvoyant 11 dans les lignes qui le
précèdent.
ls -l /proc/$(pidof pavucontrol)/fd
Cela donne, pendant le chargement de pavucontrol :
ls -l /proc/$(pidof pavucontrol)/fdtotal 0
lrwx------ 1 seb seb 64 Nov 9 16:07 0 -> /dev/pts/11
lrwx------ 1 seb seb 64 Nov 9 16:07 1 -> /dev/pts/11
lrwx------ 1 seb seb 64 Nov 9 16:07 10 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov 9 16:07 11 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov 9 16:07 2 -> /dev/pts/11
lrwx------ 1 seb seb 64 Nov 9 16:06 3 -> 'socket:[443606]'
lrwx------ 1 seb seb 64 Nov 9 16:07 4 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov 9 16:07 5 -> 'socket:[444861]'
lrwx------ 1 seb seb 64 Nov 9 16:07 6 -> 'socket:[440203]'
lrwx------ 1 seb seb 64 Nov 9 16:07 7 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov 9 16:07 8 -> 'anon_inode:[eventfd]'
lrwx------ 1 seb seb 64 Nov 9 16:07 9 -> 'socket:[444862]'
man proc a quelques infos sur "anon_inode:[eventfd]", mais ça ne m'avance pas beaucoup :
             For file descriptors that have no corresponding inodeÂ
(e.g.,
             file   descriptors  produced  by  bpf(2),
epoll_create(2),
             eventfd(2), inotify_init(2), perf_event_open(2),
signalfd(2),
             timerfd_create(2), and userfaultfd(2)), the entry will
be a sym-
             bolic link with contents of the form
                 anon_inode:file-type
             In many cases (but not all), the file-type is
surrounded by
             square brackets.
             For example, an epoll file descriptor will have a
symbolic link
             whose content is the string anon_inode:[eventpoll].
man 2 eventfd parle d'un mécanisme d'attente :
      eventfd() creates an "eventfd object" that can be used as
an event
      wait/notify mechanism by user-space applications, and by the kernel to
      notify user-space applications of events.
Cela ne m'avance guère.
Quelqu'un sait-il donner du sens à tout cela ?
poll([{fd=11, events=POLLIN}], 1, 25000Là il attend un évènement sur le file descripteur 11, il faudrait
repérer au dessus un appel open (ou nom approchant) que retourne 11
pour voir à quelle ressource ça correspond
ls -l /proc/$(pidof pavucontrol)/fd
ls -l /proc/$(pidof pavucontrol)/fdtotal 0
Bonjour !
J'ai installé hier une Debian 12 en remplacement d'une Debian plus
ancienne. C'est une installation à partir de zéro, pas une mise
à  jour.
Mon gestionnaire de fenêtres est fvwm.
Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis
quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment.
Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
okular, etc.).
Quand j'appelle "strace pavucontrol", les messages cessent de défiler
en arrivant à la dernière des lignes copiées-collées ci-dessous :
[...]
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11
futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
(Resource temporarily unavailable)
futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
write(10, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=11, events=POLLIN}], 1, 25000
Sitôt le délai (25000) passé, pavucontrol s'ouvre.
Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ?
Sinon, un rapport de bogue sur https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait
être utile.
Pour ma part, je cherche des contributeurs pour le moteur d'inférences http://refpersys.org/
Si tu as la flemme de débugger, j'imagine que tu as actuellement
pulseaudio d'installé. Tu pourrais le retirer au profit de
pipewire-pulse et voir si ça fonctionne mieux.
En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un
ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
socket/autre il poll.
ls -l /proc/$(pidof pavucontrol)/fd/11lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]'
Salut,
Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.
Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que
je venais de mettre à jour.
Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et Xdaliclock.
Le problème est croissant et menace de devenir handicapant en Debian 13.
Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.
Quelque chose qui rend mon installation peu courante, c'est que
pendant l'install je décoche toutes les cases liées à des
gestionnaires de fenêtres, et une fois l'install terminée j'installe
le minimum (fvwm et ses dépendances). D'habitude, quand on décoche
toutes ces cases, c'est pour un serveur (qui ne lancera jamais
xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).
De la sorte, il est probable que je n'installe pas un package qui est standard chez les autres utilisateurs et qui s'avère utile pour
certains logiciels graphiques (quoique pas indispensable puisque ces logiciels finissent par se lancer).
Sinon, un rapport de bogue sur
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues
pourrait être utile.
C'est vrai qu'un rapport de bug pourrait servir.
Peut-être plus avec reportbug toutefois, si c'est bien un package qui
me manque ; il n'y aurait alors qu'une simple dépendance à ajouter.
Pour ma part, je cherche des contributeurs pour le moteur
d'inférences http://refpersys.org/
Ça a l'air intéressant ; bonne chance !
Si tu as la flemme de débugger, j'imagine que tu as actuellement
pulseaudio d'installé. Tu pourrais le retirer au profit de
pipewire-pulse et voir si ça fonctionne mieux.
À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication
des endroits où le délai se manifeste qui m'inquiète.
En tout état de cause, vu que tu as le fd et 25 secondes pour agir,
un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
socket/autre il poll.
Ben ça donne ça:
ls -l /proc/$(pidof pavucontrol)/fd/11lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]'
Seb.
Question que je ne pense pas avoir lu jusque là, quelle carte graphique utilises-tu ?
J'ai une carte NVIDIA et j'ai eu ce genre de souci quand j'avais voulu tester ce que ça donnerait avec le pilote nouveau.
Et installer le paquet du pilote propriétaire correspondant à ma carte avait résolu le souci.
C'est probablement pas la solution vu que j'y vais un peu au hasard, mais sait-on jamais si ça peut être utile.
Patrick
Le 10/11/2023 à 08:43, Seb a écrit :
Salut,
Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.
Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que je
venais de mettre à jour.
Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et
Xdaliclock.
Le problème est croissant et menace de devenir handicapant en Debian 13.
Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.
Quelque chose qui rend mon installation peu courante, c'est que pendant
l'install je décoche toutes les cases liées à des gestionnaires de
fenêtres, et une fois l'install terminée j'installe le minimum (fvwm et ses >> dépendances). D'habitude, quand on décoche toutes ces cases, c'est pour un >> serveur (qui ne lancera jamais xdaliclock, donc on ne verra pas apparaître >> ce délai de 25 secondes).
De la sorte, il est probable que je n'installe pas un package qui est
standard chez les autres utilisateurs et qui s'avère utile pour certains
logiciels graphiques (quoique pas indispensable puisque ces logiciels
finissent par se lancer).
Sinon, un rapport de bogue sur
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait
être utile.
C'est vrai qu'un rapport de bug pourrait servir.
Peut-être plus avec reportbug toutefois, si c'est bien un package qui me
manque ; il n'y aurait alors qu'une simple dépendance à ajouter.
Pour ma part, je cherche des contributeurs pour le moteur d'inférences
http://refpersys.org/
Ça a l'air intéressant ; bonne chance !
Si tu as la flemme de débugger, j'imagine que tu as actuellement
pulseaudio d'installé. Tu pourrais le retirer au profit de
pipewire-pulse et voir si ça fonctionne mieux.
À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication des
endroits où le délai se manifeste qui m'inquiète.
En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un ls >>> -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle socket/autre >>> il poll.
Ben ça donne ça:
ls -l /proc/$(pidof pavucontrol)/fd/11lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 ->
'anon_inode:[eventfd]'
Seb.
--
Patrick ZAJDA
Bonjour !
J'ai installé hier une Debian 12 en remplacement d'une Debian plus
ancienne. C'est une installation à partir de zéro, pas une mise à  jour.
Mon gestionnaire de fenêtres est fvwm.
Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis
quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment.
Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
okular, etc.).
Quand j'appelle "strace pavucontrol", les messages cessent de défiler
en arrivant à la dernière des lignes copiées-collées ci-dessous :
[...]
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)Â Â = 11
futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
(Resource temporarily unavailable)
futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
write(10, "\1\0\0\0\0\0\0\0", 8)Â Â Â Â Â Â Â = 8
futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=11, events=POLLIN}], 1, 25000
Sitôt le délai (25000) passé, pavucontrol s'ouvre.
Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ?
Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.
Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que
je venais de mettre à jour.
Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et Xdaliclock.
Le problème est croissant et menace de devenir handicapant en Debian 13.
Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.
Quelque chose qui rend mon installation peu courante, c'est que
pendant l'install je décoche toutes les cases liées à des
gestionnaires de fenêtres, et une fois l'install terminée j'installe
le minimum (fvwm et ses dépendances). D'habitude, quand on décoche
toutes ces cases, c'est pour un serveur (qui ne lancera jamais
xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).
De la sorte, il est probable que je n'installe pas un package qui est standard chez les autres utilisateurs et qui s'avère utile pour
certains logiciels graphiques (quoique pas indispensable puisque ces logiciels finissent par se lancer).
Sinon, un rapport de bogue sur
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues
pourrait être utile.
C'est vrai qu'un rapport de bug pourrait servir.
Peut-être plus avec reportbug toutefois, si c'est bien un package qui
me manque ; il n'y aurait alors qu'une simple dépendance à ajouter.
Si tu as la flemme de débugger, j'imagine que tu as actuellement
pulseaudio d'installé. Tu pourrais le retirer au profit de
pipewire-pulse et voir si ça fonctionne mieux.
À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication
des endroits où le délai se manifeste qui m'inquiète.
En tout état de cause, vu que tu as le fd et 25 secondes pour agir,
un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
socket/autre il poll.
Ben ça donne ça:
ls -l /proc/$(pidof pavucontrol)/fd/11lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]'
Le 10/11/2023 à 08:43, Seb a écrit :
Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.
Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que
je venais de mettre à jour.
Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol
et Xdaliclock.
Le problème est croissant et menace de devenir handicapant en Debian 13.
Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.
Quelque chose qui rend mon installation peu courante, c'est que
pendant l'install je décoche toutes les cases liées à des
gestionnaires de fenêtres, et une fois l'install terminée j'installe
le minimum (fvwm et ses dépendances). D'habitude, quand on décoche
toutes ces cases, c'est pour un serveur (qui ne lancera jamais
xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).
De la sorte, il est probable que je n'installe pas un package qui est
standard chez les autres utilisateurs et qui s'avère utile pour
certains logiciels graphiques (quoique pas indispensable puisque ces
logiciels finissent par se lancer).
Sinon, un rapport de bogue sur
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues
pourrait être utile.
C'est vrai qu'un rapport de bug pourrait servir.
Peut-être plus avec reportbug toutefois, si c'est bien un package qui
me manque ; il n'y aurait alors qu'une simple dépendance à ajouter.
Si tu as la flemme de débugger, j'imagine que tu as actuellement
pulseaudio d'installé. Tu pourrais le retirer au profit de
pipewire-pulse et voir si ça fonctionne mieux.
À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication
des endroits où le délai se manifeste qui m'inquiète.
En tout état de cause, vu que tu as le fd et 25 secondes pour agir,
un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
socket/autre il poll.
Ben ça donne ça:
ls -l /proc/$(pidof pavucontrol)/fd/11lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 ->
'anon_inode:[eventfd]'
Bonsoir,
Je n'avais pas le lien jusqu'à présent, mais j'ai le même type de
soucis sur ma debian 12.
Pour moi, cela se manifeste lors du lancement de Firefox et lorsque je
retire certaines clés USB. Je m'en accommodais.
Sur Debian 11, cela se manifestait uniquement lors du lancement de
Firefox.
Peux-tu me rappeler la commande pour voir le délai de 25 s. Je l'ai vu passé dans les mails précédents, mais je n'avais pas percuter que
c'était valable pour moi également.
Peux-tu me rappeler la commande pour voir le délai de 25 s. Je l'aihttps://lists.debian.org/debian-user-french/
vu passé dans les mails précédents, mais je n'avais pas percuter que
c'était valable pour moi également.
poll([{fd=11, events=POLLIN}], 1, 25000
Sitôt le délai (25000) passé, pavucontrol s'ouvre.
j'ai vu un comportement proche sous ArchLinux il y a quelques mois, la
piste **dbus** est à explorer: https://bbs.archlinux.org/viewtopic.php?id=275523
À son origine, DBus servait, il me semble, à la communication des
processus dans KDE ou dans Gnome, et comme je n'utilise ni l'un, ni
l'autre, ça ne me manquait pas. DBus a pris maintenant un rôle plus important, et son absence commence à se faire sentir même sous Fvwm.
Je ne peux pas juste appeler à la main /etc/X11/Xsession au début de
mon ~/.xinitrc car /etc/X11/Xsession se termine par un "exec $STARTUP".
Bonjour,
poll([{fd=11, events=POLLIN}], 1, 25000
Sitôt le délai (25000) passé, pavucontrol s'ouvre.
j'ai vu un comportement proche sous ArchLinux il y a quelques mois,
la piste **dbus** est à explorer:
https://bbs.archlinux.org/viewtopic.php?id=275523
YOUHOU! C'est pile le bon pointeur.
Je peux donc maintenant raconter l'histoire.
Il ne me manquait pas de package.
Par contre, je démarre X avec "startx" et depuis presque 30 ans
j'utilise un fichier $HOME/.xinitrc pour dire ce qu'il faut faire :
lancer fvwm2, puis faire un xmodmap, un xrdb, lancer xdaliclock,
ouvrir un terminal, bref faire en sorte que l'environnement graphique
soit confortable dès qu'il s'ouvre.
Quand l'utilisateur n'a pas de fichier ~/.xinitrc, le système utilise
le fichier par défaut : /etc/X11/xinit/xinitrc. Celui-ci redirige vers /etc/X11/Xsession.
À une date que je ne connais pas, quelqu'un s'est dit que
/etc/X11/Xsession était un super endroit pour lancer des services
(liste dans /etc/X11/Xsession.d), entre autres DBus.
Sauf que /etc/X11/Xsession n'est pas appelé si on a son propre fichier ~/.xinitrc.
À son origine, DBus servait, il me semble, à la communication des
processus dans KDE ou dans Gnome, et comme je n'utilise ni l'un, ni
l'autre, ça ne me manquait pas. DBus a pris maintenant un rôle plus important, et son absence commence à se faire sentir même sous Fvwm.
Son timeout est d'exactement 25Â secondes.
La solution simple dans mon cas est donc de renommer ~/.xinitrc en trucs-a-lancer-au-demarrage.sh afin que les fichiers par défaut dans /etc/X11 soient utilisés.
Du coup, j'ai une question connexe : quel est aujourd'hui
l'emplacement recommandé pour les p'tites commandes (xmodmap, xrdb,
etc.) qui devraient se lancer automatiquement sitôt fvwm2 démarré ?
Je ne peux pas juste appeler à la main /etc/X11/Xsession au début de
mon ~/.xinitrc car /etc/X11/Xsession se termine par un "exec $STARTUP".
Seb.
J'avais pris un raccourci, je voulais dire que le dernier fichier appelé dans
/etc/X11/Xsession, /etc/X11/Xsession.d/99x11-common_start, contient "exec $STARTUP".
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 151:57:12 |
| Calls: | 9,699 |
| Calls today: | 9 |
| Files: | 13,732 |
| Messages: | 6,179,113 |
| Posted today: | 1 |