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

Posté par deuzene (site web personnel) le 03 mai 2014 à 18:45. Licence CC By‑SA.

Étiquettes :

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 claudex le 03 mai 2014 à 19:22. É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 deuzene (site web personnel) le 03 mai 2014 à 19:41. É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 claudex le 03 mai 2014 à 19:44. É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 deuzene (site web personnel) le 03 mai 2014 à 20:54. Évalué à 2. Dernière modification le 03 mai 2014 à 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 Sylvain Blandel le 04 mai 2014 à 02:20. Évalué à 4. Dernière modification le 04 mai 2014 à 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 deuzene (site web personnel) le 04 mai 2014 à 12:28. É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 Sylvain Blandel le 04 mai 2014 à 14:32. É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 deuzene (site web personnel) le 04 mai 2014 à 17:47. Évalué à 1. Dernière modification le 04 mai 2014 à 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 deuzene (site web personnel) le 04 mai 2014 à 18:21. Évalué à 2. Dernière modification le 04 mai 2014 à 18:23.
        
        Bon, très mauvaise idée !
        
        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 NeoX le 04 mai 2014 à 20:50. Évalué à 3.
        
        si tu n'as pas enlevé single ca doit faire conflit
        
        [^] # Re: Systemd lancé ?
        
        Posté par deuzene (site web personnel) le 04 mai 2014 à 21:00. É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 Sylvain Blandel le 04 mai 2014 à 21:29. É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 deuzene (site web personnel) le 04 mai 2014 à 22:53. É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 Sylvain Blandel le 05 mai 2014 à 12:11. Évalué à 1. Dernière modification le 05 mai 2014 à 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 deuzene (site web personnel) le 05 mai 2014 à 13:13. Évalué à 2.
        
        Résultat du grand ménage :
        
        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.
        
        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 deuzene (site web personnel) le 05 mai 2014 à 13:41. É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 Sylvain Blandel le 05 mai 2014 à 15:31. É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 :
        
        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é.
        
        Pour lancer Network Manager : sudo systemctl start NetworkManager.service
        
        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 deuzene (site web personnel) le 05 mai 2014 à 18:46. Évalué à 1. Dernière modification le 05 mai 2014 à 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 Sylvain Blandel le 05 mai 2014 à 20:11. É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 deuzene (site web personnel) le 05 mai 2014 à 21:27. É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 deuzene (site web personnel) le 05 mai 2014 à 21:34. É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 totof2000 le 07 mai 2014 à 22:30. É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 xcomcmdr le 07 mai 2014 à 22:56. É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 claudex le 07 mai 2014 à 22:59. É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
        
        [^] # Re: Grand ménage
        
        Posté par totof2000 le 08 mai 2014 à 11:06. Évalué à 1.
        
        Désolé, je n'ai pas pu m'empêcher … C'était trop tentant.
        
        [^] # Une grosse migration
        
        Posté par Sylvain Blandel le 08 mai 2014 à 14:21. É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 kursus_hc le 05 mai 2014 à 20:43. É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 deuzene (site web personnel) le 05 mai 2014 à 21:29. É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 kursus_hc le 06 mai 2014 à 04:59. É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 NeoX le 06 mai 2014 à 08:10. Évalué à 2. Dernière modification le 06 mai 2014 à 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 deuzene (site web personnel) le 06 mai 2014 à 14:33. Évalué à 1. Dernière modification le 06 mai 2014 à 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 louispolaire le 12 juin 2014 à 20:24. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.