Merci Norbert,
ils sont tous à «powersave», le les mets donc à «performance»? J’ignore ce qu’implique performance et schedutil (et …)
Est-ce que /sys/ est un répertoire persistant (après extinction et redémarrage)?
Toutes les explications ici (par exemple) :
https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html
Mode performance : fréquence CPU maximale, donc performances maxi, mais évidemment au détriment de la batterie sur un portable.
Par contre il me semble que ça n’est pas persistent, et qu’il faut relancer la commande à chaque reboot (sans certitude, ça fait longtemps que je n’utilise plus ces commandes)
j’ai zappé :
vim /etc/default/cpufrequtils
Ensuite un redémarrage du pc ou simplement de l’unit systemd cpufrequtils pour que ça soit pris lors du démarrage du système donc avant le login.
Mais attention si ce n’est que le démarrage qui est long regarde plutôt si tu n’aurait pas un point de montage long à répondre ou autre chose avec :
systemd-analyze blame
Merci Clochette,
ce fichier n’existe pas sur mon installation, dois-je le créer?
ce n’est pas le cas
Oui du coup 
Ce ne devait pas être le problème, car il se passe encore 30s entre le lancement du login graphique et l’affichage du bureau Mate.
Mon observation et mon hypothèse était fausse. Sans doute parce que cette lenteur disparaît si je passe par l’étape «changer d’utilisateur», mais sans changer d’utilisateur ni si je me «déconnecte».
Autrement dit, cette lenteur n’apparaît que lors de la 1ere connexion pour chaque utilisateur.
Dans ce cas corrige le titre et essai d’analyser ce ralentissement :
systemd-analyze --user blame
$ sudo systemd-analyze --user blame
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)J’ai pas mis de sudo dans ma commande …
systemd-analyze --user blame
Bonjour, je pense comme vous, Norbert29, ce système de fichiers est de type « sysfs ». Donc il disparaît à l’extinction de la machine
Privilégier le fichier /etc/cpupower-services.conf
Cordialement
Bonjour, désolé pour ce retard, mais j’ai été plusieurs fois dérangé, et pas vu votre dernière remarque.
$cat /media/eric/INTENSO/systemd-analyse--user_blame.txt
887ms pulseaudio.service
282ms xdg-desktop-portal.service
72ms gvfs-udisks2-volume-monitor.service
67ms obex.service
55ms gvfs-daemon.service
55ms xdg-desktop-portal-gtk.service
51ms dconf.service
40ms gvfs-metadata.service
39ms xdg-permission-store.service
22ms xdg-document-portal.service
18ms gvfs-gphoto2-volume-monitor.service
17ms gvfs-mtp-volume-monitor.service
16ms gpg-agent.socket
15ms dbus.socket
15ms ssh-agent.socket
15ms gcr-ssh-agent.socket
12ms gvfs-afc-volume-monitor.service
11ms gpg-agent-ssh.socket
11ms gvfs-goa-volume-monitor.service
10ms at-spi-dbus-bus.service
9ms dbus.service
on est loin des 25-30 sec.
Pas de message d’erreur lors du démarrage ?
Sinon, rien de bizarre n’apparait sur un dmesg ?
Désolé, j’ai omis de préciser que cette question faisait suite à celle-ci
à propos de messages d’erreurs concernant le BIOS (mais j’ai également des messages analogues (les 1eres lignes de dmesg) sur un autre ordi (Clevo) qui ne pose pas ce problème (au moins concrètement, dans la pratique).
Étant de plus en plus mal à l’aise avec la technique informatique, j’avoue ne pas très bien maîtriser ce qui justifie d’ouvrir ou non une autre discussion sur ce forum.
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
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.
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
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
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
Bonjour,
$grep ':100.:' /etc/passwd
eric:x:1000:1000:Eric Xxx,,,:/home/eric:/bin/bash
harmonie:x:1001:1001:harmonie,,,:/home/harmonie:/bin/bashPour 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