Re: Délai de 25 secondes
Le 14 novembre 2023 Seb a écrit : > 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". /etc/X11/Xsession.d/50x11-common_determine-startup positionne $STARTUP à un script qui est soit $HOME/.xsession soit $HOME/.Xsession $HOME/.xsessionrc est sourcé, ici je préfère lancer un script donc j'ai tout mis en $HOME/.xsession qui est donc lancé via /etc/X11/Xsession
RE: Délai de 25 secondes
Bonjour, Tu peux mettre tes commandes dans ~/.xsessionrc . Ça marche, merci ! Je lis en ligne que ce fichier de config semble spécifique à Debian (et dérivés). 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". Ici (Bookworm) je n'ai pas cette ligne. 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". Seb.
RE: Délai de 25 secondes
Salut, Tu peux mettre tes commandes dans ~/.xsessionrc . Cdlt, Fred.
Re: Délai de 25 secondes
Bonjour, Le 2023-11-14 10:26, Seb a écrit : À 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. C'est devenu un élément assez central en effet. Il est même utilisé par systemd. 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". Ici (Bookworm) je n'ai pas cette ligne. Perso je me suis créé un dossier dans lequel j'ai mis mes propres scripts de démarrage de tout ce que je veux (y compris des trucs graphiques) que je lance via une boucle : ``` for script in $(ls ~/.xsession.d/startup.d/); do [ -f ~/.xsession.d/startup.d/$script ] || continue command ~/.xsession.d/startup.d/$script & done ``` Sinon tu peux faire un truc du genre (pas testé) : ``` for f in /etc/X11/Xsession.d/*; do source $f; done ``` À adapter selon ton shell. Autre piste, j'ai ça dans mon `.xinitrc` (qui ne doit pas me servir puisque je suis passé à Wayland) : ``` export XDG_DATA_DIRS=$XDG_DATA_DIRS:$HOME/.local/share/applications if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then eval `dbus-launch --sh-syntax --exit-with-session` fi ``` Sébastien
Re: Délai de 25 secondes
On 11/14/23 10:26, Seb wrote:
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é ?
La page de man suggère:
During initialization, fvwm searches for a configuration file
which describes key and button bindings, and many other things. The
format of these files is
described later. Fvwm first searches for configuration files
using the command
Read config
This looks for file config in $FVWM_USERDIR and $FVWM_DATADIR
directories, as described in Read. If this fails more files are
queried for backward
compatibility. Here is the complete list of all file locations
queried in the default installation (only the first found file is used):
$HOME/.fvwm/config
/usr/local/share/fvwm/config
$HOME/.fvwm/.fvwm2rc
$HOME/.fvwm2rc
/usr/local/share/fvwm/.fvwm2rc
/usr/local/share/fvwm/system.fvwm2rc
/etc/system.fvwm2rc
Please note, the last 5 locations are not guaranteed to be
supported in the future.
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.
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Re: Délai de 25 secondes
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.
Re: Délai de 25 secondes
Le 11/11/2023 à 12:20, NoSpam a écrit : 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. https://lists.debian.org/debian-user-french/ Merci.
Re: Délai de 25 secondes
Bonjour Le 10/11/2023 à 22:19, Jose CHARTERS a écrit : 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/11 lrwx-- 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. https://lists.debian.org/debian-user-french/
Re: Délai de 25 secondes
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/11 lrwx-- 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. José
Re: Délai de 25 secondes
Bonsoir, Seb, on 2023-11-10: > 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). J'ai rencontré un problème similaire dans un contexte d'absence d'environnement de bureau, et appliqué une méthode « massue » à base de purge de paquets de la famille xdg-desktop-portal. J'ai ensuite oublié le problème. Peut-être qu'il existe une méthode correcte, mais je n'ai pas creusé davantage. Ce qui m'a fait mettre le doigt sur ce paquet a été une erreur bizarre à la sortie de df. Après lancement d'une application affectée par la lenteur, df se mettait à planter avec le message d'erreur décrit dans #991378[1], mais il est très probable que ce symptôme particulier n'existe plus sur des Debian 11 et 12 à jour. Je ne me souviens plus des détails, mais je crois que mount retournait un type fuse portal pour le point de montage, ce qui m'a éventuellement mis sur la piste du paquet mentioné. [1]: https://bugs.debian.org/991378 Après peut-être que je fais complètement fausse route, mais les symptômes ressemblent tout de même très fortement. Bonne soirée, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: D'Virgilio, Morse & Jennings - Julia (Alternat… signature.asc Description: PGP signature
Re: Délai de 25 secondes
On 09/11/2023 10:34, Seb wrote:
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 ?
Bonjour,
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
Ludovic
Re: Délai de 25 secondes
Bonsoir, Question que je ne pense pas avoir lu jusque là, quelle carte graphique utilises-tu ? Une vieille NVidia. 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. J'utilisais effectivement le pilote nouveau. Et installer le paquet du pilote propriétaire correspondant à ma carte avait résolu le souci. J'ai installé le pilote Nvidia et... ça n'a rien changé. Merci quand même ! Seb. 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/11 lrwx-- 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]' Seb. -- Patrick ZAJDA
Re: Délai de 25 secondes
Hello, 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/11 lrwx-- 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]' Seb. -- Patrick ZAJDA
Re: Délai de 25 secondes
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/11 lrwx-- 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]' Seb.
Re: Délai de 25 secondes
Seb wrote on 09/11/2023 at 11:34:11+0100:
> 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 ?
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.
--
PEB
signature.asc
Description: PGP signature
Re: Délai de 25 secondes
On 11/9/23 15:12, Seb wrote:
Bonjour,
poll([{fd=11, events=POLLIN}], 1, 25000
Là 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.
Je devine qu'un processus (j'ignore lequel) a appellé eventfd, qui est
très utile mais spécifique à Linux:
https://man7.org/linux/man-pages/man2/eventfd.2.html
Peut-être qu'il serait utile de télécharger le code source de
pavucontrol https://freedesktop.org/software/pulseaudio/pavucontrol/ et
d'y chercher les appels à eventfd.
Sinon, un rapport de bogue sur
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait
être utile.
ls -l /proc/$(pidof pavucontrol)/fd
Cela donne, pendant le chargement de pavucontrol :
~> ls -l /proc/$(pidof pavucontrol)/fd
total 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 ?
Pour ma part, je cherche des contributeurs pour le moteur d'inférences
http://refpersys.org/ (avec code en
https://github.com/RefPerSys/RefPerSys/ )
Dans quelque temps (j'espère quelques mois) RefPerSys pourrait aider à
chasser ce genre de bogue.
Librement
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Re: Délai de 25 secondes
Bonjour,
poll([{fd=11, events=POLLIN}], 1, 25000
Là 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)/fd
total 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.,
filedescriptors 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 ?
Ou pense à une piste complètement différente pour donner sens à ces
25 secondes d'attente ?
Merci !
Seb.
Re: Délai de 25 secondes
Bonjour,
Le 2023-11-09 12:59, Erwan David a écrit :
Le 09/11/2023 à 11:34, Seb a écrit :
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 ?
Là 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
On doit pouvoir le trouver aussi en lançant cette commande :
ls -l /proc/$(pidof pavucontrol)/fd
À condition qu'il n'y ait qu'un seul pavucontrol en fonctionnement.
Sébastien
Re: Délai de 25 secondes
Le 09/11/2023 à 11:34, Seb a écrit :
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.
Là 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
Délai de 25 secondes
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.
