Forum Linux.debian/ubuntu Systemd : problème au démarrage.

Posté par (page perso) . Licence CC by-sa
Tags : aucun
3
3
mai
2014

Bonjour, depuis quelques jours je rencontre ce problème sur une Debian Sid accompagnée de Kde.

Au démarrage de la machine, aprés quelques messages seulement, ce type de message défile (presque indéfiniment) :
[xx.xxxx] systemd[1] Jobs dbus.socket/start deleted to break ordering cycle starting with sockets.target/start

Les xx.xxxx représentent des chiffres qui s'incrémentent.
Je dis “presque” indéfiniment, parce que au bout d'un long moment la machine se bloque, et donc pas de boot possible. Il ne reste plus qu'à l'éteindre électriquement.

Ce qui est étrange, c'est que si je fait le choix dans Grub de démarrer en mode “de secours”, que j'attende d'avoir le choix de rentrer le mot de passe root ou Ctrl-D pour continuer, ce que je fais (Ctrl-D), le boot continue et la machine fonctionne normalement.

Il y a une discussion ici et en suivant les conseils de ce post j'obtiens :

$ systemctl status dbus.service
Failed to get D-Bus connection: No connection to service manager.

$ journalctl -b -p err
No journal files were found.

$ systemd-analyze blame
Failed to issue method call: No such method 'ListUnits'

J'avoue mon largage.

  • # Boucle

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

    Il me semble que ça arrive quand on créé une boucle de dépendance, par exemple un service qui voudrait démarrer avant Dbus et après Dbus. Quand systemd se rend compte de ça, il essaye de casser la boucle de dépendance comme il peut, sans garantir que ça marche. Le fait que ça marche en mode rescue est sans doute parce que le service qui cause le problème de boucle n'est pas démarré en mode rescue et quand tu continue le démarrage, il n'y a plus de problème de boucle, Dbus étant déjà démarré. Tu n'aurais pas d'autres infos au démarrage qui pourrait permettre d'identifier le service en question ?

    « 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: Boucle

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

      Quel genre d'infos et comment les obtenir ?

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Boucle

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

        Quand tu dis

        Au démarrage de la machine, aprés quelques messages seulement, ce type de message défile (presque indéfiniment) :
        [xx.xxxx] systemd[1] Jobs dbus.socket/start deleted to break ordering cycle starting with sockets.target/start

        Il n'y a pas d'autres lignes avec des informations différentes (les numéros sont juste le nombre de secondes (jusqu'à la dix-millième décimale) depuis le démarrage).

        « 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: Boucle

          Posté par (page perso) . Évalué à 2. Dernière modification le 03/05/14 à 20:56.

          Non, rien d'autre que ces lignes qui défilent.

          À vrai dire il faudrait que je film le démarrage pour rendre compte des différents messages.

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

    • [^] # Re: Boucle

      Posté par . Évalué à 4. Dernière modification le 04/05/14 à 02:21.

      Il me semble que ça arrive quand on créé une boucle de dépendance, par exemple un service qui voudrait démarrer avant Dbus et après Dbus.

      Oui, ça ressemble à une boucle entre dbus.socket et sockets.target.

      Tu peux essayer ceci :

      1. Démarre ton système en utilisant le mode « de secours » dans Grub.
      2. Une fois ton système démarré, lance les 2 unités en question :
        systemctl start dbus.socket
        systemctl start sockets.target

      3. Tape les trois commandes précédentes.

      4. Pour voir les liens entre ces deux unités, tu peux taper :
        systemctl show dbus.socket | grep sockets.target
        systemctl show sockets.target | grep dbus.socket

      Donne-nous le retour de ces différentes commandes.

      • [^] # Re: Boucle

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

        Merci.
        Dès la première commande ça part mal

        $ systemctl start dbus.socket
        Failed to get D-Bus connection: No connection to service manager.
        $ systemctl start sockets.target
        Failed to get D-Bus connection: No connection to service manager.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

        • [^] # Systemd lancé ?

          Posté par . Évalué à 3.

          Dès la première commande ça part mal.

          Hum … J'ai le pré-sentiment que, lorsque tu démarres en choisissant le mode « de secours » de Grub, ce n'est pas systemd qui est lancé (c'est certainement SysVinit qui est lancé).

          Regarde le fichier de configuration de Grub, et compare les options du mode « normal » et du mode « de secours ».

          • [^] # Re: Systemd lancé ?

            Posté par (page perso) . Évalué à 1. Dernière modification le 04/05/14 à 20:33.

            Effectivement, dans /boot/grub/grub.cfg :

            menuentry 'Debian GNU/Linux, avec Linux 3.14-1-686-pae' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.14-1-686-pae-advanced-022ad01a-3705-4a88-bec6-a3a942549fe6' {
                            load_video
                            gfxmode $linux_gfx_mode
                            insmod gzio
                            insmod part_msdos
                            insmod ext2
                            set root='hd0,msdos4'
                            if [ x$feature_platform_search_hint = xy ]; then
                              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos4 --hint-efi=hd0,msdos4 --hint-baremetal=ahci0,msdos4 --hint='hd0,msdos4'  022ad01a-3705-4a88-bec6-a3a942549fe6
                            else
                              search --no-floppy --fs-uuid --set=root 022ad01a-3705-4a88-bec6-a3a942549fe6
                            fi
                            echo    'Chargement de Linux 3.14-1-686-pae…'
                            linux   /boot/vmlinuz-3.14-1-686-pae root=UUID=022ad01a-3705-4a88-bec6-a3a942549fe6 ro  quiet init=/lib/systemd/systemd
                            echo    'Chargement du disque mémoire initial…'
                            initrd  /boot/initrd.img-3.14-1-686-pae
                    }
            
            menuentry 'Debian GNU/Linux, with Linux 3.14-1-686-pae (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.14-1-686-pae-recovery-022ad01a-3705-4a88-bec6-a3a942549fe6' {
                            load_video
                            gfxmode $linux_gfx_mode
                            insmod gzio
                            insmod part_msdos
                            insmod ext2
                            set root='hd0,msdos4'
                            if [ x$feature_platform_search_hint = xy ]; then
                              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos4 --hint-efi=hd0,msdos4 --hint-baremetal=ahci0,msdos4 --hint='hd0,msdos4'  022ad01a-3705-4a88-bec6-a3a942549fe6
                            else
                              search --no-floppy --fs-uuid --set=root 022ad01a-3705-4a88-bec6-a3a942549fe6
                            fi
                            echo    'Chargement de Linux 3.14-1-686-pae…'
                            linux   /boot/vmlinuz-3.14-1-686-pae root=UUID=022ad01a-3705-4a88-bec6-a3a942549fe6 ro single
                            echo    'Chargement du disque mémoire initial…'
                            initrd  /boot/initrd.img-3.14-1-686-pae
                    }

            Systemd n'est pas lancé en mode recovery
            Je vais donc éditer à la volée Grub au démarrage, en ajoutant init=/lib/systemd/systemd à la ligne recovery mode et vous tiens au courant.

            « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

            • [^] # Re: Systemd lancé ?

              Posté par (page perso) . Évalué à 2. Dernière modification le 04/05/14 à 18:23.

              Bon, très mauvaise idée !
              Kernel panic
              Photo

              J'en viens à me demander si je ne dois pas me débarrasser de systemd !

              « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

              • [^] # Re: Systemd lancé ?

                Posté par . Évalué à 3.

                si tu n'as pas enlevé single ca doit faire conflit

                • [^] # Re: Systemd lancé ?

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

                  Résultat identique sans le single.

                  « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

              • [^] # rescue.target

                Posté par . Évalué à 3.

                Bon, très mauvaise idée !

                Ah mince.

                On peut essayer autre chose : le paramètre single est interprété par systemd pour lancer la cible rescue.target (plutôt que la cible default.target). Donc : édite à la volée Grub au démarrage, mais cette fois-ci dans le mode « normal » (pas le mode « recovery »). Enlève le quiet et ajoute single après le init=/lib/systemd/systemd

                Sans le quiet, tu auras plus de messages au boot.

                • [^] # Re: rescue.target

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

                  Bon, ben, pas mieux. La seule différence, due à la suppression du quiet, c'est l'affichage de plusieurs lignes

                  [ skip ] Ordering cycle found, skipping D-Bus System Message Bus Socket

                  entre les

                  [ xx.xxxx ] Jobs dbus.socket/start deleted to break ordering cycle starting withe sockets.target/start

                  « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

                  • [^] # Grand ménage

                    Posté par . Évalué à 1. Dernière modification le 05/05/14 à 12:13.

                    Bon, ben, pas mieux

                    Argh !

                    Tant pis, on bourrine : démarre ton système en utilisant le mode recovery de Grub (systemd ne sera pas lancé). Une fois l'ordinateur démarré, fais une copie de sauvegarde du répertoire /etc/systemd/system/, puis recherche et efface dans ce répertoire (et ses sous-répertoires) tout ce qui a trait a dbus.socket et sockets.target. Tu peux même essayer d'effacer tout le contenu de /etc/systemd/system/

                    Une fois ce ménage réalisé, essaie de démarrer ta machine, avec systemd cette fois-ci. Dans un premier temps, essaie avec le paramètre single (en éditant Grub à la volée).

                    • [^] # Re: Grand ménage

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

                      Résultat du grand ménage :

                      1. Après avoir fait une copie de /etc/systemd/system/ et effacé le dossier sockets.target.wants/ (je n'ai rien trouvé concernant dbus.socket), puis démarrage normal en ajoutant single : J'ai le même message d'erreur.
                      2. J'efface donc tout le répertoire /etc/systemd/system et redémarre en mode normal + single : Le démarrage se fait en mode rescue (?), je tape Ctrl-D et le démarrage se poursuit jusqu'au bureau (ouf).

                      Je m'attendais à ce que le répertoire /etc/systemd/system soit recréé, mais non.

                      Jusque là tout va bien, sauf que, ça n'a certainement rien à voir, Network Manager a perdu ma connection Wifi ! Je suis donc en mode rescue pour écrire ce message.

                      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

                      • [^] # Re: Grand ménage

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

                        Pour Network Manager :
                        Il a fallut sudo /etc/init.d/network-manager restart

                        Donc je suis bien cette fois-ci en mode normal avec systemd lancé.

                        Pourrions-nous faire quelques tests ?

                        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

                      • [^] # Re: Grand ménage

                        Posté par . Évalué à 3.

                        Bon, il y a du mieux :-)

                        redémarre en mode normal + single : Le démarrage se fait en mode rescue (?)

                        C'est normal.
                        Lorsque l'on démarre son ordinateur avec systemd, single est un raccourci de systemd.unit=rescue.target. Cela démarre le strict minimum, ainsi qu'un shell de secours. Voir ici : lien1, lien2, lien3.

                        Maintenant que ça fonctionne : tu devrais avoir un démarrage normal en n'utilisant pas single.


                        Je m'attendais à ce que le répertoire /etc/systemd/system/ soit recréé, mais non.

                        Hum … Je pense que tu devrais le recréer manuellement, même en le laissant vide pour l'instant.


                        Il a fallut sudo /etc/init.d/network-manager restart

                        Ça, c'est la méthode SysVinit pour démarrer des services. Si tu utilises systemd, il convient d'utiliser la méthode systemd :

                        1. Dans le répertoire /lib/systemd/system/ cherche le fichier .service de Network Manager (ça devrait être « NetworkManager.service »). Il s'agit d'un fichier texte, tu peux le consulter par curiosité.
                        2. Pour lancer Network Manager : sudo systemctl start NetworkManager.service
                        3. Pour automatiser le lancement de Network Manager au démarrage : sudo systemctl enable NetworkManager.service

                        Cette dernière commande modifiera le contenu du répertoire /etc/systemd/system/. Les modifications apparues signifient que Network Manager est une dépendance du niveau d'exécution « multi-user.target ».

                        Cette méthode est valable pour tous les services que tu souhaites lancer au démarrage.


                        Il est probable que tu n'aies qu'un seul terminal virtuel, accessible par Ctrl+Alt+F1, et que Ctrl+Alt+F2, Ctrl+Alt+F3, … ne donnent rien. Pour avoir plusieurs terminaux virtuels, voir cette page.

                        • [^] # Re: Grand ménage

                          Posté par (page perso) . Évalué à 1. Dernière modification le 05/05/14 à 21:22.

                          Merci, ça roule.
                          Et merci pour les liens que je vais m'empresser de fouiller.

                          J'ai donc recréer le répertoire /etc/systemd/system, puis lancé la commande sudo systemctl enable NetworkManager.service, ce qui m'a permis de voir que des liens symboliques ont été créés dans /etc/systemd/system. Par contre quid des autres liens, donc services que j'ai supprimés avant ? Ayant sauvegardé le dossier /etc/systemd/system, en voici la liste :

                           $ ls /old.systemd/system/
                          bluetooth.target.wants/
                          cups.socket.d/
                          dbus-fi.epitest.hostap.WPASupplicant.service@ 
                          dbus-org.bluez.service@
                          dbus-org.freedesktop.Avahi.service@
                          dbus-org.freedesktop.Hal.service@
                          dbus-org.freedesktop.NetworkManager.service@
                          dbus-org.freedesktop.nm-dispatcher.service@
                          getty.target.wants/
                          graphical.target.wants/
                          local-fs.target.wants/
                          multi-user.target.wants/
                          network.target.wants/
                          printer.target.wants/
                          sockets.target.wants/
                          sshd.service@
                          syslog.service@
                          vsftpd.service

                          Ne va-t-il pas manquer quelques pattes à systemd ?

                          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

                          • [^] # Re: Grand ménage

                            Posté par . Évalué à 1.

                            Ne va-t-il pas manquer quelques pattes à systemd ?

                            À systemd lui-même, je pense que non.
                            Les fichiers de systemd « brut de décoffrage » sont dans /lib/systemd/. Et les modifications réalisées par l'administrateur sont écrites dans /etc/systemd/. Bien évidemment, lorsque le système fonctionne, /etc/systemd/ est prioritaire sur /lib/systemd/.

                            Pour savoir s'il te manque des trucs dans /etc/systemd/, il faudrait comparer avec une installation fraîche de Debian Sid.


                            Pour rechercher les éventuels messages d'erreur, tu peux consulter le journal avec la commande :

                            sudo journalctl

                            Pour n'avoir que les messages depuis le dernier boot, c'est l'option -b. Et pour filtrer les messages importants, c'est l'option -p.

                            À titre personnel, j'utilise :

                            sudo journalctl -b -p notice

                            • [^] # Re: Grand ménage

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

                              Ok, merci, je vais regarder tout ça.

                              « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

                              • [^] # Re: Grand ménage

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

                                Ouch, merci.
                                La commande sudo journalctl -b -p notice me renvoie pleins de failed to execute '/lib/udev/socket:@/org/freedesktop/hal, il y a d'autres problèmes à régler.

                                « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

                    • [^] # Re: Grand ménage

                      Posté par . Évalué à 0.

                      OOOOh, c'est beau systemd. C'est simple, ça marche, et quand il y a un problème c'est facile à résoudre.

                      • [^] # Re: Grand ménage

                        Posté par . Évalué à 1.

                        Et je te parle pas de SysV…

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Grand ménage

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

                        Ce commentaire n'a rien à faire dans les forum. Ce n'est vraiment pas le genre de message constructif qui aidera l'utilisateur.

                        « 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

                      • [^] # Une grosse migration

                        Posté par . Évalué à 4.

                        OOOOh, c'est beau systemd. C'est simple, ça marche, et quand il y a un problème c'est facile à résoudre.

                        Le problème qui nous intéressait ici était causé par un changement de système d'init. C'est une opération grave, il ne s'agit pas d'une mise-à-jour de gedit : un élément prépondérant du système est migré d'une technologie à une autre. Cette migration technologique n'a pas, à ma connaissance, d'équivalent (on pourrait peut-être comparer cela aux migrations Gnome 2 → Gnome 3, ou KDE 3 → KDE 4). Vu l'envergure de ce bouleversement, il n'est guère étonnant qu'il y ait des problèmes (surtout que le système d'exploitation utilisé ici est une version unstable).

                        Puisque nous ne sommes pas habitués à la nouvelle technologie, les problèmes rencontrés nous semblent complexes. Nous perdons l'aisance que nous avions avec la vieille technologie. Faites comme les jeunes : plongez-vous dans les pages de manuel !

  • # Autre point du vue

    Posté par . Évalué à 2.

    J'avais une debian sid/KDE depuis plusieurs années qui commençait à tousser un peu, avec des messages cryptiques de systemd régulièrement au boot.

    J'ai passé beaucoup de temps à tenter de tout régler, et puis j'ai réalisé que j'en perdrais moins à faire une réinstallation complète. Je n'ai pas regretté ce choix : avec les mêmes services démarrés j'ai gagné 10 secondes au boot, et systemd ne se plaint plus.

    Ca peut être aussi l'occasion de repartir sur un dossier .kde frais, ce qui est incroyablement bénéfique si tu te le trimballes depuis un bon nombre de versions.

    • [^] # Re: Autre point du vue

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

      Je suis bien conscient que le dossier .kde peut devenir un vrai foutoir, mais je ne vois pas le rapport avec systemd.
      Je me suis déjà posé la question d'une réinstall, pour repartir sur une base saine, mais j'ai toujours eu la flemme.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Autre point du vue

        Posté par . Évalué à 3.

        L'expression "Ca peut être aussi l'occasion de […]" signifie qu'il n'y a pas de rapport direct avec le sujet.

        Sinon relativise ta flemme, avec un

        aptitude install $(cat listofpackages.txt)

        Tu aurais réglé en 2 heures le problème qui te gêne depuis 3 jours.

        • [^] # Re: Autre point du vue

          Posté par . Évalué à 2. Dernière modification le 06/05/14 à 15:28.

          aptitude install $(cat listofpackages.txt)

          Tu aurais réglé en 2 heures le problème qui te gêne depuis 3 jours.

          voire mieux et prevu pour

          sur l'ancienne install :

          user#host:~ $ sudo dpkg --get-selections "*" >myselections.txt

          "*" pour inclure les paquets à purger

          sur la nouvelle :

          user#host:~ $ sudo  apt-get update
          user#host:~ $ sudo  dpkg --set-selections <myselections.txt
          user#host:~ $ sudo apt-get -u dselect-upgrade
          • [^] # Re: Autre point du vue

            Posté par (page perso) . Évalué à 1. Dernière modification le 06/05/14 à 14:36.

            Merci, je m'en vais utiliser cette procédure.

            « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # c'est la faute de Cups...

    Posté par . Évalué à 1.

    salut,

    ça fait drôle de voir mon topic sur le forum de siduction cité ici :)

    J'ai résolu le problème à l'aide de ce lien :
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741528

    Pour désactiver cups au démarrage j'ai chrooté le système cassé et j'ai fait un :

    #systemctl disable cups

    dis moi si ça marche chez toi ?

Suivre le flux des commentaires

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