Forum Linux.général Boot très lent avec systemd

Posté par . Licence CC by-sa
Tags :
6
20
sept.
2014

Bonjour,

Ça y est, j'ai fait le pas systemd. Enfin… ma mise à jour vers Debian Jessie l'a fait pour moi. Content d'avoir un nouveau truc à apprendre (on verra pragmatiquement ensuite si je suis content de cette transition ou pas) mais pour l'instant, on ne peut pas dire que cela se passe idéalement :

sudo systemd-analyze
Startup finished in 16.594s (kernel) + 1min 10.560s (userspace) = 1min 27.155s

Pour être plus précis :

sudo systemd-analyze blame
     1min 9.746s systemd-udev-settle.service
           515ms NetworkManager.service
           417ms exim4.service
           306ms tlp.service
           232ms ModemManager.service
           182ms accounts-daemon.service
           148ms avahi-daemon.service
           145ms systemd-logind.service
           142ms lightdm.service
           133ms acpi-support.service
           116ms virtualbox.service
            87ms systemd-fsck-root.service
            82ms rsyslog.service
            79ms ntp.service
(...)

Pour paraphraser, on voit clairement qui est à blâmer.

J'ai demandé gentiment à startpage et si je retrouve des personnes qui ont le même genre de problème, ce n'est pas dans la même mesure (une quinzaine de secondes) et les diverses solutions proposées (notamment remplacer les chemins /dev/ par des UUID dans le fstab, purger tout ce qui concerne nfs et lvm, retirer ce service si l'on n'utilise pas nfs ou lvm) ne s'appliquent pas ou n'ont rien changé.

J'ai un conteneur chiffré LUKS et des volumes lvm.

Pour info, mon fstab :

#/dev/mapper/debian-slash
UUID=22da1fcd-2c17-4a32-82c5-fc4b4194071d /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda5 during installation
UUID=f47cd70e-e38a-4d72-ba4f-789492bd5119 /boot           ext4    defaults        0       2
# /dev/mapper/debian-home
UUID=0e59c063-5a48-43c6-9ebb-b72037039d6d /home           ext4    defaults        0       2
# /dev/mapper/debian-swap
UUID=f537202a-ba45-4f54-afbc-64a29d010b2a none            swap    sw              0       0

Avez-vous une piste qui permettrait d'améliorer la situation ?

Par avance merci !

  • # journal

    Posté par . Évalué à 6.

    journalctl -b -u systemd-udev-settle

    te donnera peut-être des informations sur ce qui bloque.

  • # udevadm settle

    Posté par . Évalué à 4.

    Salut,

    Apparemment, l'unité systemd-udev-settle.service lance la commande udevadm settle:

    > systemctl show systemd-udev-settle.service | grep ExecStart
    ExecStart={ path=/bin/udevadm ; argv[]=/bin/udevadm settle ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ;  code=(null) ; status=0/0 }
    

    Voilà ce que dit la page de manuel udevadm(8) sur la sous-commande settle:

    udevadm settle [options]
        Watches the udev event queue, and exits if all current events are handled.
    
        --timeout=seconds
            Maximum number of seconds to wait for the event queue to become empty. The default value is 120 seconds. A value of 0 will check if the queue is empty
            and always return immediately.
    [...]
    

    Donc apparemment, tu pourrais utiliser cette option --timeout pour éviter que ça attende trop longtemps :-/

    Théoriquement, ça devrait marcher, mais il vaut probablement mieux essayer de trouver pourquoi la commande udevadm settle prends autant de temps.

    • Peut être que tu devrais essayer de voir quelles unités sont bloqués par systemd-udev-settle.service (avec systemd-analyze critical-chain, peut être ?).
    • Sur mon système, cette unité est désactivée, et ça marche quand même → qu'est ce que ça fait si tu la désactives ?
    • Est-ce que tu as bien la dernière version de udev, udisks et systemd ? Avec un peut de chance, le bug aura été résolu dans la dernière version.

    Envoyé depuis ma Debian avec Firefox

    • [^] # Re: udevadm settle

      Posté par . Évalué à 3. Dernière modification le 20/09/14 à 20:08.

      Merci pour vos réponses.

      journalctl -b -u systemd-udev-settle
      

      Ne raconte pas grand chose :

      sept. 20 19:25:31 oberon systemd[1]: Starting udev Wait for Complete Device Initialization...
      sept. 20 19:26:40 oberon systemd[1]: Started udev Wait for Complete Device Initialization.
      

      Pour ce qui est des unités bloquées :

      systemd-analyze critical-chain
      
      graphical.target @1min 10.555s
      └─multi-user.target @1min 10.555s
        └─NetworkManager.service @1min 10.039s +515ms
          └─basic.target @1min 10.019s
            └─paths.target @1min 10.018s
              └─cups.path @1min 10.018s
                └─sysinit.target @1min 10.015s
                  └─rpcbind.service @1min 9.996s +19ms
                    └─network-online.target @1min 9.995s
                      └─network.target @1min 9.995s
                        └─networking.service @1min 9.941s +54ms
                          └─local-fs.target @1min 9.940s
                            └─lvm2-monitor.service @1min 9.927s +12ms
                              └─lvm2-lvmetad.socket @121ms
                                └─-.mount @102ms
                                  └─system.slice @132ms
                                    └─-.slice @131ms
      

      J'ai noté le rpcbind qui est inutile dans ma configuration actuelle. Mais une fois enlevé pas d'amélioration.

      J'ai par ailleurs lu cela (http://freedesktop.org/wiki/Software/systemd/Optimizations/) :

      Make sure not to use any fake block device storage technology such as LVM (as installed by default by various distributions, including Fedora) they result in the systemd-udev-settle.service unit to be pulled in. Settling device enumeration is slow, racy and mostly obsolete. Since LVM (still) hasn't been updated to handle Linux' event based design properly, settling device enumeration is still required for it, but it will slow down boot substantially. On Fedora, use "systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service" to get rid of all those storage technologies. Of course, don't try this if you actually installed your system with LVM. (The only fake block device storage technology that currently handles this all properly and doesn't require settling device enumerations is LUKS disk encryption.)

      Cela ne m'encourage pas trop à désactiver ce service avec mes volumes LVM.

      Pour ce qui est des versions de udev, udisks et systemd, il s'agit des version de Debian Jessie (l'actuelle testing pour les non Debianeux qui me liraient) et donc j'aimerai identifier clairement le problème sur les versions actuellement utilisées pour pouvoir le cas échéant remonter un bug chez Debian.

      Toujours est-il que dans un premier temps par manque de temps pour creuser, je vais probablement mettre un timeout.

      • [^] # Re: udevadm settle

        Posté par (page perso) . Évalué à 5.

        Chez moi (avec Jessie aussi), le service met 1.75 secondes à démarrer et j'ai plusieurs disques avec du LVM. Soit tu as un problème de config, soit tu es dans un cas particulier.

        (Je ne dis pas pour te critiquer, juste pour que tu ne t'impatiente pas trop pour la résolution du bug, il y a aura sans doute moins de gens motivés pour s'en occuper.)

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: udevadm settle

          Posté par . Évalué à 1.

          Merci pour l'information. Il y a, de fait, moins de probabilité qu'une mise à jour magique corrige cela dans les jours à venir. Il faudra que je regarde cela plus en détail de moi même (même si pour l'instant je suis plutôt à sec).

  • # Hardware ?

    Posté par . Évalué à 3.

    Un disque dur en veille peut être très long à se réveiller, t'a pas de disque USB/eSata connecté au PC ?

    • [^] # Re: Hardware ?

      Posté par . Évalué à 1.

      Non pas de disque de ce type connecté au démarrage.

  • # modif à tester dans ... hum des scripts systèmes?

    Posté par . Évalué à 3.

    Je suis récemment tombé sur ceci (enfin, c'est tombé dans ma boîte mail pour être exact, provenance directe de la mailing list internationale de debian):

    Le 17.09.2014 09:13, Jörg-Volker Peetz a écrit :
    Take a look at bug #754987. If I remember correctly, Michael Biebl also
    suggested on this list to replace the line

    do_everything > /dev/null 2> /dev/null &

    in file /lib/udev/net.agent

    by

    ( do_everything ) > /dev/null 2> /dev/null &

    Regards,
    Jörg-Volker.

    Pas sûr que ça aide, mais dans mon cas j'avais udev qui freezait pendant 30s au boot, et cette manip à résolut le problème. Bon, il faut préciser que ma situation est différente: je n'utilise pas systemd avec ma jessie (j'ai upgrade, et n'ai pas fait l'effort de passer à systemd, c'est même le contraire, je fait ce que je peux pour éviter) et il semblerait que certaines MaJ liées à systemd aient inséré des bugs dans ce qui marchait auparavant très bien.
    Mais on est pas vendredi :)

    Toujours est-il que pour ce genre de chose la ml est très intéressante à suivre, bien qu'il y ait beaucoup trop de bruit/parasitage autour de systemd en ce moment. À mon goût du moins.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.