Eu tenho um servidor Amazon EC2 executando xenial 16.04.3. Recentemente eu gravei um /etc/fstab e quando reiniciei o sistema ele foi para o "Modo de Emergência" do systemd, onde ele estava esperando por alguém presente fisicamente para pressionar Ctrl + D, o que é impossível no EC2. Eu resolvi esse problema desligando a máquina e montando sua unidade de outra máquina para consertar a configuração quebrada. Isso levou provavelmente 10 minutos, a maioria dos quais foi gasta aguardando o AWS Console fazer as coisas.
Em casos anteriores em que a causa subjacente não era aparente, tentar diagnosticar e corrigir problemas que caíram no modo de recuperação variou de frustrante a fútil, especialmente se você se esqueceu de desligar em journald armazenamento persistente .
Existe uma maneira de configurar o systemd para iniciar um sshd quando ele fica preso no modo de recuperação, para que eu tenha opções de diagnóstico / reparo que não envolvam a montagem novamente da unidade?
A maioria das referências que posso encontrar sobre problemas semelhantes no Ubuntu dependem da mudança para o systemd e consequentemente não são relevantes. A coisa mais próxima que eu encontrei para uma resposta até agora é esse bug da Red Hat que sugere a existência de uma possível solução envolvendo a mudança da configuração de sshd.service , de modo que ela não dependa indiretamente de local-fs.target , mas então se torne uma disputa inútil antes que qualquer solução definitiva apareça.