Lenteur au premier login graphique pour chaque utilisateur

Support Debian
#23

Un problème posé de manière foireuse sans analyse préalable des causes, a vocation à tourner en rond.

Combien y a-t-il d’utilisateurs sur ce PC ? un seul je présume.
A quoi ça sert d’installer un applet qui ne servirait qu’au premier login. A rien.

Supposons que la lenteur du premier login soit causée par un service bloqué en attente d’un autre service manquant avec un timeout de 30 secondes.
Même avec CPU 100 fois plus puissant, 30 secondes seront toujours 30 secondes.

Alors quel mystère se cache derrière ce problème fantôme ?
La réponse est probablement dans un message qui a été supprimé:

$ systemd-analyze --user blame

 211ms tracker-miner-fs-3.service
 182ms evolution-source-registry.service
 110ms xdg-desktop-portal.service

tracker-miner-fs: base de données pour méta-données, indexeur et outil de recherche
↳ Depends: localsearch

Si nautilus et/ou tracker-miner-fs et/ou localsearch sont installés, l’initialisation du premier profil utilisateur nécessitera d’indexer tous les fichiers de l’utilisateur. Il faudra un certain temps (30 secondes per exemple) pour lire et indexer 1 million de fichiers.

Désinstaller nautilus et le remplacer par Thunar par exemple retirera la dépendance d’installation de ‹ localsearch › qui pourra être désinstallé.

La commande find sachant parfaitement trouver un fichier sans aucune indexation, l’indexation de millions de fichiers pour trouver un fichier est à mon avis inutile en usage courant. Si les services ne peuvent pas être désinstallés, il peuvent être désactivés:

sudo systemctl --global mask tracker-miner-fs-3.service
sudo systemctl --global mask localsearch-3.service

Info: Tracker-Miner service causing high CPU usage - Fedora Discussion

Le mystère ne peut donc être relatif qu’à un problème de première indexation de fichiers.

1 J'aime
#24

Merci Verner pour cette leçon,

2 utilisateurs.

J’ignorais qu’on pouvait faire autrement, (l’installeur ne propose pas cette option)
Mais celà sert à entrer un mot de passe et à choisir éventuellement un autre gestionnaire de bureau.

Encore peu de fichier sur cet ordi après réinstallation de Trixie

aucun de ces 3 paquets, mais plocate est installé et fréquemment utilisé
un message qui a été supprimé:

Message supprimé car ayant été lancé sur un autre PC (Clevo)!

Voici le résultat sur le pc concerné (HP)
$ systemd-analyze --user blame
976ms pulseaudio.service
373ms xdg-desktop-portal.service
125ms xdg-desktop-portal-gtk.service
105ms obex.service
76ms gvfs-udisks2-volume-monitor.service
71ms xdg-permission-store.service
56ms gvfs-metadata.service
54ms dconf.service
36ms gvfs-daemon.service
28ms xdg-document-portal.service
18ms gvfs-gphoto2-volume-monitor.service
17ms gvfs-mtp-volume-monitor.service
16ms gpg-agent.socket
16ms dbus.socket
15ms gcr-ssh-agent.socket
14ms ssh-agent.socket
14ms gpg-agent-ssh.socket
13ms gvfs-afc-volume-monitor.service
11ms at-spi-dbus-bus.service
10ms gvfs-goa-volume-monitor.service
9ms dbus.service

soit à peine plus de 2 s.

#25

Sujet ouvert le 13 Juillet, soit une semaine.

La suppression mystère d’un message sans explication correspondait donc à un changement de PC, en cours d’analyse du 1er.
Ça aurait été plus qu’utile de prevénir car ce n’est plus le même sujet.

Concernant le PC N°1, je confirme que le paquet tracker-miner-fs est/était installé, car si systemd-analyze trouve le service ‹ tracker-miner-fs-3.service ›, il n’a pas pu l’inventer.
tracker-miner-fs n’a pas de rétro-dépendance.
Si ce n’est pas toi qui l’a installé, demande à l’autre utilisateur de ce PC si ce n’est pas lui.
Je confirme à 95%: ‹ Le mystère ne peut donc être relatif qu’à un problème de première indexation de fichiers. ›
L’analyse du 1er PC est close pour moi.

Concernant le PC N°2, il ne s’agit donc pas de la même installation puisque tracker-miner-fs ne serait donc pas installé.
Par contre, si plocate est installé, il s’agit à 99% du même problème d’indexation initiale de fichiers. La différence est que le service est différent du 1er PC: plocate-updatedb.service, l’exécutable correspondant étant /usr/sbin/updatedb.plocate

Mais si ce PC n’est pas ‹ fraichement installé › comme le premier, et que le phénomène est exclusivement observé lors du premier login, je ne comprends pas quelle est la demande pour ce 2ième PC.
Il est probablement préférable d’ouvrir un autre sujet pour clarifier et éviter la mayonnaise.

Pour information, que dit ceci sur les 2 PCs ?
grep ':100.:' /etc/passwd

#26

Pour clarifier la mayonnaise:
Un seul PC (HP) est concerné.
Le Clevo n’est impliqué que dans un message rapidement annulé, (malheureusement pas effacé. Il ne présente pas de délai sensible au login)

Donc la seule mayonnaise ne vient que du message effacé.

Par ailleurs, le 1er login de chaque utilisateur présente la même lenteur, ce qui me semble (mais je peux évidemment me tromper) disculper updatedb (plocate), d’autant plus que les durées d’action de updatedb sont très variables, alors que le délai de 1er login est constamment proche de 30s.

Avant le message 12 il a été question de régler le problème du CPU lent, qui me laissait croire que la lenteur de login était liée.
Une fois la question du CPU réglée
le problème de lenteur du login a persisté.

La question de la cause reste un mystère pour moi. La gène est mineure, mais j’essaie d’être un peu exigeant malgré mon incompétence. (c’est pire le soir, je vais me coucher)

Merci pour votre aide

#27

Je n’ai donc pas les capacités cognitives suffisantes pour suivre les méandres de ce sujet sur une semaine.

Pour information, que dit ceci sur ‹ le › PC à analyser ? (au lieu des 2 PCs).
grep ':100.:' /etc/passwd

#28

Bonjour,

$grep ':100.:' /etc/passwd
eric:x:1000:1000:Eric Xxx,,,:/home/eric:/bin/bash
harmonie:x:1001:1001:harmonie,,,:/home/harmonie:/bin/bash
#29

Pour reproduire et analyser les 30s du premier login, il faut donc ajouter un 3ieme utilisateur de test, et refaire une analyse des systemd-analyze exclusivement lors du premier login.
Après c’est trop tartd.

1 J'aime