Ca tombe bien que tu demandes. J'ai une debian, et lors d'une migration j'ai eu un systemd qui c'est installé.
Lors du premier redémarrage avec, je n'ai pas eu trop de problème (sauf un problème d'intégration et de migration : certains services ne prenaient pas en compte les valeur définies dans /etc/default et forcément ça ne marchait pas ... C'était pourtant les valeurs par défaut de la distrib (valeurs pas modifiées donc ) . Ca c'est un pb de debian et pas forcément de systemd).
Bref je vivotais avec systemd en essayant d'avoir un avis sans préjugé.
J'ai vu des trucs très sympa, comme le fait de pouvoir rajouter des respawn sur n'importe quel service, de changer les limites (nofile, ...), et le fait de pouvoir changer un script d'init (enfin un "unit file") juste en rajoutant un fichier et en mettant que les valeurs "kivonbien" (donc ne pas modifier le script initial).
la liste de systemctl avec indication des failed itou est aussi sympa .
Bon par contre la documentation est vraiment pas clair et on perd énormément de temps à chercher ce qu'il nous faut
Bref jusqu'à hier, ce n'était pas parfait mais ça marchait plutôt bien.
Et hier, je fais une maj normal, je ne change rien de critique dans mes paquets ni rien (style maj de blender etc...) et je redémarre.
Deja au démarrage il me sort "start a job for /dev/... (25 s / 1 m 30s)" ...
(et oui ça a bien duré 1 m 30 sec. Aucune explication de ce qu'est ce truc qui ressemble plus à un timer qu'à autre chose).
il continue après à afficher des OK , et quelques failed (qui sont sans importance vu que c'est des programmes acessoires).
Après une bonne quinzaine de "ok" , il me sort "oups j'ai rencontré un problème. Je passe en Emergency, tape journalctl -xn , puis systemctl reboot pour rebooter, ou systemctl default pour continuer)
Bon il faut donner le mot de passe root pour corriger ok allons y.
tapons les commandes qu'il nous a fournis.
ET là on arrive dans le niveau 0 de l'utilité.
J'ai les 10 dernières lignes ... qui concernent des erreurs udev sur le fichier 85_logi_mouse.conf et c'est tout.
(une bonne 15-aine de service minimum sont passé après le démarrage de udev)
bon on recherche un peu avec un journalctl --help, journalctl -x --no-tail . On a tous les logs de démarrage ...
Mais toujours aucune indication de pourquoi il plante.
Bon ressortons du mode emergency et faisons un ctrl+d (essayer de continuer sans passer en root)
... il freeze sur le exit de la console d'emergency.
Reboot avec les sysmagickey, re attente de 1 m 30, et cette fois ci ctrl+d avant de se connecter.
Il freeze pendant 1 ou 2 min, puis il me raffiche le même message comme quoi il faut que je me logge. Pas de nouveau message qui pourrait m'aider à cibler ce qui ne vas pas.
Reloggons nous, constatons a quel point la gestion du terminal de cette console est pitoyable (backspace supprime le caractère en l'affichant à nouveau, on ne parle pas de complétion ou autre...)
essayons de lancer un zsh, ah ça plante. Il doit pas avoir monté les partoches. C'est balot ...
mount -a, ca bloque pendant 30 seconde ou une minute, en mettant une floppée de warning,mais ca marche au final.
Quelques tests pour essayer de trouver, et puis je sais plus trop ce que je fais , à nouveau freeze complet de l'interface. sysmagickey à la rescousse.
Bon essayons avec un init=/bin/sh.
AH déjà le terminal marche mieux.mount -o remount,rw /, /Etc/init.d/udev ... ouip tout marche \o/
bon le lvm ne marche plus, obligé de faire un vgchange -a y, puis de monter directement les dm-? , car udev n'arrive pas à lister les lv (pourtant lvs les affiche bien).
Après quelques tests, je veux accéder au réseau : ifup eth0, ca marche
/etc/init.d/bind9 ... "tentative de démarrage du service avec systemctl... Echec, impossible de trouver une session dbus".
Ah c'est sur que si il n'y a pas de fallback à systemctl on est dans la merde.
Après encore deux trois reboot et tatonnement j'ai fait un test dans lequel j'ai réussi à faire marcher le tout
console emergency -> login as root -> mount -a -> init 5
et ca passe (surtout pas systemctl default après le mount -a, ca freeze irrémédiablement)
Et je ne sais toujours pas pourquoi il plante.
Systemctl redémarre plus rapidement ?
Non -> un timer d'1m30s dans un boot, c'est plus long que tout mon précédent boot, avec une floppée de service
Non -> devoir passer 1h30 à 2h00 pour avoir le droit de démarrer sa machine, et sans indication claire de quel étape plante, c'est affligeant pour un système censé aider l'admin sys.
[^] # Re: Est-ce vraiment un programme de "production" ?
Posté par briaeros007 . En réponse à la dépêche systemd version 216. Évalué à 8.
Ca tombe bien que tu demandes. J'ai une debian, et lors d'une migration j'ai eu un systemd qui c'est installé.
Lors du premier redémarrage avec, je n'ai pas eu trop de problème (sauf un problème d'intégration et de migration : certains services ne prenaient pas en compte les valeur définies dans /etc/default et forcément ça ne marchait pas ... C'était pourtant les valeurs par défaut de la distrib (valeurs pas modifiées donc ) . Ca c'est un pb de debian et pas forcément de systemd).
Bref je vivotais avec systemd en essayant d'avoir un avis sans préjugé.
J'ai vu des trucs très sympa, comme le fait de pouvoir rajouter des respawn sur n'importe quel service, de changer les limites (nofile, ...), et le fait de pouvoir changer un script d'init (enfin un "unit file") juste en rajoutant un fichier et en mettant que les valeurs "kivonbien" (donc ne pas modifier le script initial).
la liste de systemctl avec indication des failed itou est aussi sympa .
Bon par contre la documentation est vraiment pas clair et on perd énormément de temps à chercher ce qu'il nous faut
Bref jusqu'à hier, ce n'était pas parfait mais ça marchait plutôt bien.
Et hier, je fais une maj normal, je ne change rien de critique dans mes paquets ni rien (style maj de blender etc...) et je redémarre.
Deja au démarrage il me sort "start a job for /dev/... (25 s / 1 m 30s)" ...
(et oui ça a bien duré 1 m 30 sec. Aucune explication de ce qu'est ce truc qui ressemble plus à un timer qu'à autre chose).
il continue après à afficher des OK , et quelques failed (qui sont sans importance vu que c'est des programmes acessoires).
Après une bonne quinzaine de "ok" , il me sort "oups j'ai rencontré un problème. Je passe en Emergency, tape journalctl -xn , puis systemctl reboot pour rebooter, ou systemctl default pour continuer)
Bon il faut donner le mot de passe root pour corriger ok allons y.
tapons les commandes qu'il nous a fournis.
ET là on arrive dans le niveau 0 de l'utilité.
J'ai les 10 dernières lignes ... qui concernent des erreurs udev sur le fichier 85_logi_mouse.conf et c'est tout.
(une bonne 15-aine de service minimum sont passé après le démarrage de udev)
bon on recherche un peu avec un journalctl --help, journalctl -x --no-tail . On a tous les logs de démarrage ...
Mais toujours aucune indication de pourquoi il plante.
Bon ressortons du mode emergency et faisons un ctrl+d (essayer de continuer sans passer en root)
... il freeze sur le exit de la console d'emergency.
Reboot avec les sysmagickey, re attente de 1 m 30, et cette fois ci ctrl+d avant de se connecter.
Il freeze pendant 1 ou 2 min, puis il me raffiche le même message comme quoi il faut que je me logge. Pas de nouveau message qui pourrait m'aider à cibler ce qui ne vas pas.
Reloggons nous, constatons a quel point la gestion du terminal de cette console est pitoyable (backspace supprime le caractère en l'affichant à nouveau, on ne parle pas de complétion ou autre...)
essayons de lancer un zsh, ah ça plante. Il doit pas avoir monté les partoches. C'est balot ...
mount -a, ca bloque pendant 30 seconde ou une minute, en mettant une floppée de warning,mais ca marche au final.
Quelques tests pour essayer de trouver, et puis je sais plus trop ce que je fais , à nouveau freeze complet de l'interface. sysmagickey à la rescousse.
Bon essayons avec un init=/bin/sh.
AH déjà le terminal marche mieux.mount -o remount,rw /, /Etc/init.d/udev ... ouip tout marche \o/
bon le lvm ne marche plus, obligé de faire un vgchange -a y, puis de monter directement les dm-? , car udev n'arrive pas à lister les lv (pourtant lvs les affiche bien).
Après quelques tests, je veux accéder au réseau : ifup eth0, ca marche
/etc/init.d/bind9 ... "tentative de démarrage du service avec systemctl... Echec, impossible de trouver une session dbus".
Ah c'est sur que si il n'y a pas de fallback à systemctl on est dans la merde.
Après encore deux trois reboot et tatonnement j'ai fait un test dans lequel j'ai réussi à faire marcher le tout
console emergency -> login as root -> mount -a -> init 5
et ca passe (surtout pas systemctl default après le mount -a, ca freeze irrémédiablement)
Et je ne sais toujours pas pourquoi il plante.
Systemctl redémarre plus rapidement ?
Non -> un timer d'1m30s dans un boot, c'est plus long que tout mon précédent boot, avec une floppée de service
Non -> devoir passer 1h30 à 2h00 pour avoir le droit de démarrer sa machine, et sans indication claire de quel étape plante, c'est affligeant pour un système censé aider l'admin sys.