O serviço Getty não inicia

1

Eu tive problemas com a inicialização de multi-user.target em um dos meus servidores Centos 7. No começo, notei que executar o comando runlevel retorna um nível "desconhecido".

# runlevel
unknown

Eu suspeitava que isso poderia ser causado pelo multi-user.target inativo, que é o destino padrão.

# systemctl status multi-user.target
multi-user.target - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/multi-user.target; enabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd.special(7)

# systemctl get-default
multi-user.target

Quando tentei iniciá-lo manualmente, o comando acabou de desligar e nada aconteceu. Percebi que o getty.target , multi-user.target depende, também está inativo e há um trabalho start pendente.

# systemctl -t target
UNIT                  LOAD   ACTIVE   SUB    JOB   DESCRIPTION
basic.target          loaded active   active       Basic System
cryptsetup.target     loaded active   active       Encrypted Volumes
getty.target          loaded inactive dead   start Login Prompts
local-fs-pre.target   loaded active   active       Local File Systems (Pre)
local-fs.target       loaded active   active       Local File Systems
multi-user.target     loaded inactive dead   start Multi-User System
network-online.target loaded active   active       Network is Online
network-pre.target    loaded active   active       Network (Pre)
network.target        loaded active   active       Network
paths.target          loaded active   active       Paths
remote-fs-pre.target  loaded active   active       Remote File Systems (Pre)
remote-fs.target      loaded active   active       Remote File Systems
slices.target         loaded active   active       Slices
sockets.target        loaded active   active       Sockets
spice-vdagentd.target loaded active   active       Agent daemon for Spice guests
swap.target           loaded active   active       Swap
sysinit.target        loaded active   active       System Initialization
timers.target         loaded active   active       Timers

A partir de getty.target / [email protected] teve o mesmo efeito - o comando acabou de ser desativado. Infelizmente, não encontrei nenhum motivo para esse comportamento usando o journalctl .

Assim que escrevi o último parágrafo, pensei em interromper o trabalho de inicialização pendente em getty.target e iniciá-lo novamente. Isso realmente resolveu meu problema principal, pois parar o trabalho pendente permitia que multi-user.target ativasse .

systemctl --job-mode=replace stop getty.target

Isso ainda não explica por que o getty.target se recusa a iniciar. Algum de vocês tem uma idéia de por que isso pode estar acontecendo ou há algum outro log que eu possa investigar?

    
por Tomas Kralik 07.11.2017 / 18:15

1 resposta

1

Um colega de trabalho teve um problema com alvos do getty / multi-user systemd que não foram iniciados. Quando ele se conectou ao console, houve um aviso de que ele tinha que reconhecer / responder uma pergunta para que as coisas pudessem prosseguir, o que permitia que o getty / multiusuário fosse iniciado.

Esta é uma captura de tela no prompt:

Esseproblematambémémencionadoaqui: “Licença não aceita” quando o CentOS 7 inicia . O EULA com o qual você precisa concordar pode ser automaticamente aceito via kickstart, conforme descrito aqui - kickstart com eula - configuração final .

    
por 05.01.2018 / 19:22