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

• # journal

  Posté par wismerhill le 20 septembre 2014 à 12:27. Évalué à 6.

  

  journalctl -b -u systemd-udev-settle

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

• # udevadm settle

  Posté par mrr le 20 septembre 2014 à 15:02. É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 Nim le 20 septembre 2014 à 20:07. Évalué à 3. Dernière modification le 20 septembre 2014 à 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 claudex le 21 septembre 2014 à 11:37. É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 Nim le 22 septembre 2014 à 11:45. É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 Tonton Benoit le 22 septembre 2014 à 01:09. É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 Nim le 22 septembre 2014 à 11:22. Évalué à 1.

    

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

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

  Posté par freem le 23 septembre 2014 à 16:58. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.