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?