Como determinar exatamente porque o Systemd entra no modo de emergência

Question

Meu computador desktop rodando Debian Jessie começou a cair em um shell de modo de emergência a cada inicialização. A tela diz para usar journalctl -xb para encontrar o motivo e usar systemctl default para continuar a inicialização. Quando executo systemctl default , o sistema continua a inicializar e, após algumas semanas de uso do sistema, não há nada aparentemente errado.

Olhando através de journalctl -xb , nada se destaca como sendo a razão para cair em uma casca de emergência. Existe uma maneira fácil de determinar exatamente a razão pela qual ele decidiu entrar no modo de emergência? Existem outros sinalizadores ou opções de inicialização que tornarão óbvio onde está o problema?

    

Answer 1

A falha deve ter mostrado um [ FAIL ] vermelho no console (em vez de [ OK ] ), com a descrição da unidade próxima a ele. Normalmente, as primeiras falhas são mais importantes. Use shift + pageup no console para rolar para cima e visualizar as poucas telas cheias de saída. Isso pode não funcionar se houver muita saída.

Isso funciona mesmo que você não veja normalmente [ OK ] messages, por exemplo, devido a quiet na linha de comando do kernel, como usado pelo Debian. Na primeira falha, o systemd alterna para o modo detalhado.

Caso contrário, você pode usar systemctl . Sem opções, mostra uma lista enorme de unidades conhecidas com falhas destacadas em vermelho. Para mostrar apenas os que falharam, use systemctl --state=failed ou systemctl --failed .

Se você pesquisar nos arquivos da unidade, existem poucas maneiras de a inicialização cair para emergency.target . Geralmente é quando uma unidade .mount para um sistema de arquivos local falha, fazendo com que local-fs.target falhe. Ou quando o initramfs não conseguir montar o sistema de arquivos raiz, se o seu initramfs usar o systemd.

local-fs.target tem OnFailure=emergency.target . E ele falha porque as unidades dos sistemas de arquivos locais são automaticamente adicionadas à lista de pedidos de local-fs.target (a menos que tenham DefaultDependencies=no ).

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

    

Answer 2

De vez em quando eu me deparo com um prompt de "modo de manutenção", e eu tenho que rolar pelo journald para erros também. Como o journalctl usa menos como o pager, você deve ser capaz de aplicar menos atalhos à sua pesquisa.

Normalmente, eu confiaria na função de pesquisa (/) e procuraria por algo equivalente a "error", "warning" ou "fail". E certifique-se de -i forçar uma busca insensível a maiúsculas e minúsculas.

Então, minhas teclas tendem a parecer:

-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)

Tecnicamente, não é uma pesquisa exaustiva ou exata para o problema exato, mas eu nunca perdi um problema de inicialização dessa maneira.

Alguns atalhos de teclado menos relacionados abaixo:

link