systemd-logind.service falha ao iniciar (ao tentar retornar de rescue.target para graphical.target). Como faço para corrigir isso?

Question

Estou usando o Debian 8 ("jessie"). Eu preciso executar alguns serviços no modo de manutenção, então mudou de gráfico para modo de recuperação usando,

systemctl isolate rescue.target

Mas quando tentei voltar ao modo padrão usando

systemctl isolate graphical.target

falha ao voltar com os seguintes erros.

Syslog:

Sep 20 05:24:22 test systemd[1]: Starting Login Service...
Sep 20 05:24:22 test systemd[1]: systemd-logind.service: Start operation timed out. Terminating.
Sep 20 05:24:22 test systemd[1]: Failed to start Login Service.
Sep 20 05:24:22 test systemd[1]: systemd-logind.service: Unit entered failed state.
Sep 20 05:24:22 test systemd[1]: systemd-logind.service: Failed with result 'timeout'.
Sep 20 05:24:22 test systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart.
Sep 20 05:24:22 test systemd[1]: Stopped Login Service.
Sep 20 05:24:22 test systemd[1]: Starting Login Service...

Faz um loop infinitamente. Estou trabalhando errado? por favor, alguém me orientar sobre isso para prosseguir.

    

Answer 1

Você já tentou "init 5"? Eu acho que isso seria o mesmo que "systemctl" embora. Ou "runlevel 5" e reinicie ...

Em RedHat há um arquivo de configuração que você pode definir o nível de execução padrão, se você puder encontrar este arquivo e editá-lo. "/ etc / inittab" Eu acredito, é onde você pode definir o nível de execução padrão.

Você pode consultar a página de manual "systemctl" e pesquisar "isolar" para ver se há algo útil.

Não tenho certeza se algum deles ajuda, mas isso seria o que eu faria para resolver esse problema.

// NOTA: Esta não é uma resposta adequada para a pergunta, supostamente para ser postada como um comentário, mas devido à falta de Reputação, eu não poderia fazê-lo. Minhas desculpas.

    

Answer 2

Acabei na mesma situação depois de reiniciar o daemon D-Bus no Ubuntu 16.04.

Acho que percorrer o alvo de resgate causa basicamente o mesmo problema, um novo daemon D-Bus está em execução, mas em algum lugar do sistema há uma referência à antiga.

Eu me recuperei do loop de reinicialização do gerenciador de login por "restarting" systemd

# systemctl daemon-reexec

(Nota: O servidor D-Bus oficialmente reinicializado não é suportado, porque todos os serviços D-Bus em execução também precisam ser reiniciados, para fazê-los se registrar com o daemon D-Bus atualizado. Isso precisa ser feito manualmente. busctl mostra todos os serviços registrados do D-Bus, por isso, se você executá-lo, você terá uma lista de serviços que você precisa reiniciar.