Problèmes et questions concernant l'édition XFCE.
Répondre

Thunar lent au démarrage... mais pas toujours.

#1Messageil y a 7 ans

Le contexte est l’utilisation de thunar conjointement à des partages samba.
Aléatoirement, au doigt mouillé je dirais dans 30% des cas, mon thunar est lent, très lent au démarrage, près de 20 secondes avec comme corollaire une incapacité pour lui à parcourir le réseau.
Je mettais ça sur le compte de mon /etc/samba/smb.conf assez usine à gaz il est vrai... qui fonctionnait quand même dans les autres 70% des cas. :siffle

Hors je viens de changer ma stratégie de partages en utilisant thunar-shares-plugin-manjaro, très bon paquet qui ajoute à l'original un script d'installation facilitant la configuration, fournissant un smb.conf tout prêt, démarrant les services, inscrivant les utilisateurs au groupe ad-hoc, etc...
Il suffit juste avant d'installer le paquet de penser à créer le groupe sambashare, pas prévu par le script.

J'étais persuadé avoir réglé par ce biais mes démarrages parfois lents, et non ça continue :desole:

Je suspecte le daemon de thunar de démarrer avant gvfs... donc avant de laisser à gvfs-smb le temps de faire les montages.

Existe-t-il un moyen de contrôler l'ordre de démarrage des services.

Thunar lent au démarrage... mais pas toujours.

#2Messageil y a 7 ans

'LLo,

Si tu désactives/actives ton gestionnaire de session via systemctl tu auras le chemin du "coeur du poulailler" systemd & dans la section [unit] & sur les lignes idoines (Before ou After) des services en cause tu peux modifier mais penses à garder les originaux... :siffle

Thunar lent au démarrage... mais pas toujours.

#3Messageil y a 7 ans

Reçu fassil, je vais explorer cette piste.

Edit : pas vu d'entrée choquante dans les sections [unit] l'ordre ou conditions semblent logiques
Dernière modification par JacoTuxil y a 7 ans, modifié au total 1 fois.

Thunar lent au démarrage... mais pas toujours.

#4Messageil y a 7 ans

Bon déjà je pense que probablement l'ordre au boot est celui du temps de chargement, systemd me renseigne avec analyse blame.
On y voit que le réseau y est dont les services smbd et nmdb entres autres, it's fine :sourire: .

[jacotux@Textorm-CH ~]$ systemd-analyze blame
          1.379s plymouth-start.service
          1.087s lightdm-plymouth.service
          1.074s plymouth-quit-wait.service
           340ms ModemManager.service
           308ms dev-sda5.device
           296ms systemd-journald.service
           206ms org.cups.cupsd.service
           167ms upower.service
           122ms tlp.service
           121ms nmbd.service
           110ms polkit.service
           110ms NetworkManager.service
           107ms bluetooth.service
            98ms systemd-logind.service
            88ms systemd-udevd.service
            76ms systemd-fsck@dev-disk-by\x2duuid-572f8db0\x2d29c8\x2d4cbc\x2d87
            67ms smbd.service
            60ms udisks2.service
            55ms systemd-rfkill.service
            52ms systemd-vconsole-setup.service
            52ms systemd-modules-load.service
            43ms systemd-journal-flush.service
            41ms systemd-udev-trigger.service
            35ms systemd-tmpfiles-setup-dev.service
            35ms user@1000.service
            26ms accounts-daemon.service
            25ms colord.service
            23ms rtkit-daemon.service
            23ms avahi-daemon.service
            20ms systemd-binfmt.service
            18ms dev-mqueue.mount
            13ms systemd-backlight@backlight:acpi_video0.service
            13ms systemd-tmpfiles-setup.service
            12ms plymouth-read-write.service
            11ms wpa_supplicant.service
            10ms systemd-sysctl.service
            10ms dev-hugepages.mount
            10ms systemd-random-seed.service
            10ms kmod-static-nodes.service
            10ms ntpd.service
             9ms systemd-remount-fs.service
             9ms home.mount
             9ms sys-kernel-debug.mount
             7ms alsa-restore.service
             5ms proc-sys-fs-binfmt_misc.mount
             5ms systemd-update-utmp.service
             4ms systemd-user-sessions.service
             3ms sys-fs-fuse-connections.mount
             2ms tmp.mount
             2ms sys-kernel-config.mount

Ceci dit il y a tout ce qui se lance ensuite en entrant en session dont Xfsettingsd
Image

Tout ça ne me renseigne pas beaucoup pour l'implication entre gvfs et thunar

Par contre entre temps j'ai vu ça sur le wiki Arch > Trash/network icons disappear randomly
Effectivement quand le démarrage est lent je n'ai plus l'icône de réseau.
Je suppose qu'après avoir mis ce script Thunar dans /usr/local/bin/ il faille le lancer dans les applis de démarrage.
A essayer du moins... réponse plus tard.

Thunar lent au démarrage... mais pas toujours.

#5Messageil y a 7 ans

Retour de l'essai du script /usr/local/bin/Thunar

Après 20 relances du PC, au passage on apprécie le SSD et son boot au 1/4 de tour, je n'ai pas un sans faute, 15% d’échecs, certes mieux que ma stat au "doigt mouillé", elle était peut-être pessimiste.
Trois démarrages ont aboutis à un lancement de thunar lent mais aussi à une découverte du réseau non aboutie (par gvfs :saispas: ? )

J'en conclus que le pb est à chercher du coté de gvfs.

Thunar lent au démarrage... mais pas toujours.

#6Messageil y a 7 ans

Salut,

Ton souci doit être au niveau de gvfs-smb, parce que je me connecte de temps en temps en ssh à partir de Thunar et je n'ai aucun problème.
Répondre