Comment déterminer exactement pourquoi Systemd passe en mode d'urgence

Mon ordinateur de bureau exécutant Debian Jessie a commencé à tomber dans un shell en mode d'urgence à chaque démarrage. L'écran indique à utiliser journalctl -xbpour trouver la raison et à utiliser systemctl defaultpour continuer le démarrage. Lorsque j'exécute systemctl default, le système continue de démarrer, et après quelques semaines d'utilisation du système, il n'y a apparemment rien de mal.

En regardant à travers journalctl -xb, rien ne ressort comme étant la raison de la chute dans un obus d'urgence. Existe-t-il un moyen facile de déterminer exactement la raison pour laquelle il a décidé de passer en mode d'urgence? Existe-t-il d'autres indicateurs ou options de démarrage qui indiqueront clairement où se situe le problème?

debian systemd systemd-journald

— jordanm
source

Il devrait être visible dans le journal mais avec les informations limitées que vous fournissez, il n'y a aucun moyen de vous guider. Avez-vous une copie du journalctl -xb moment où cela s'est produit?

— Julie Pelletier

Démarrez en mode de journalisation détaillée systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1Mpour les détails de niveau médico-légal ...

— jasonwryan

Les journaux existants devraient déjà vous donner la raison. Il y a tellement de raisons qu'il est très difficile de deviner.

— Giacomo Catenazzi

J'ai le même problème sur une instance d'Ubuntu 16.04. J'ai installé, utilisé et réparé de nombreux systèmes Linux au cours des 20 dernières années. Rien de spécial à l'écran et cette fois, rien ne ressort dans les journaux. L'écran indique Ctrl-D pour continuer le démarrage, mais cela ne ramène à la même invite qu'au bout d'un moment. Sans indice. Frustrant, non?

— Stéphane Gourichon

Avez-vous essayé toutes les étapes de la section «Diagnostic des problèmes de démarrage» dans Débogage de systemd ?

— Siosm

Réponses:

L'échec aurait dû afficher un rouge [ FAIL ]sur la console (au lieu de [ OK ]), avec la description de l'unité à côté. Généralement, les premiers échecs sont les plus importants. Utilisez shift + pageup sur la console pour faire défiler vers le haut et afficher les derniers écrans de sortie. Cela pourrait ne pas fonctionner s'il y a trop de sortie.

Cela fonctionne même si vous ne voyez pas normalement les [ OK ]messages, par exemple à cause de quietla ligne de commande du noyau telle qu'utilisée par Debian. Lors du premier échec, systemd passe en mode détaillé.

Sinon, vous pouvez utiliser systemctl. Sans aucune option, il affiche une liste massive d'unités connues avec des échecs surlignés en rouge. Pour afficher uniquement les échecs, utilisez systemctl --state=failedou systemctl --failed.

Si vous recherchez dans les fichiers d'unité, il n'y a que très peu de façons pour que le démarrage revienne emergency.target. C'est généralement quand une .mountunité pour un système de fichiers local tombe en panne, provoquant l' local-fs.targetéchec. Ou lorsque vos initramfs ne parviennent pas à monter le système de fichiers racine, si vos initramfs utilisent systemd.

local-fs.targeta OnFailure=emergency.target. Et il échoue car les unités des systèmes de fichiers locaux sont automatiquement ajoutées à la liste Requiert de local-fs.target (sauf si elles l'ont DefaultDependencies=no).

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

— sourcejedi
source

De temps en temps, je rencontre une invite de "mode de maintenance", et je dois également faire défiler le journal pour les erreurs. Puisque journalctl utilise moins comme pageur, vous devriez pouvoir appliquer moins de raccourcis à votre recherche.

En général, je me fie à la fonction de recherche (/) et je recherche tout ce qui équivaut à "erreur", "avertissement" ou "échec". Et assurez-vous de -i pour forcer la recherche insensible à la casse.

Donc, mes frappes auraient tendance à ressembler à:

-i (case insensitive)
g (move to start)
/error
nnnn (skip through results)
g (move to start)
/fail
nnnn (skip through results)
g (move to start)
/warn
nnnn (skip through results)

Ce n'est techniquement pas une recherche exhaustive ou exacte du problème précis, mais je n'ai jamais manqué un problème de démarrage de cette façon.

Quelques raccourcis clavier associés moins ci-dessous:

http://www.thegeekstuff.com/2010/02/unix-less-command-10-tips-for-effective-navigation/

— madumlao
source

Je pense qu'il devrait également être possible de feuilleter rapidement et de rechercher les messages rouges (LOG_ERR et supérieur). systemdenregistrera les messages rouges en cas d'échec de démarrage d'une unité de service ou, plus important encore, d'échec de montage d'un système de fichiers.

— sourcejedi