E agora, o sistema responde.
Você está usando, de acordo com a tag da sua pergunta, o Red Hat Enterprise Linux. Desde a versão 7, isso usou o systemd. Nenhuma das outras respostas está correta para o mundo do systemd; nem são algumas das suposições da sua pergunta.
- Esqueça os níveis de execução ; eles existem, mas apenas como calços de compatibilidade. A documentação do systemd afirma que o conceito é "obsoleto". Se você está começando a aprender essas coisas em um sistema operacional systemd, não comece por aí.
- Esqueça a página de manual que marcelm citou; não é do conjunto de ferramentas certo e é uma descrição do comando de outro conjunto de ferramentas, incorreto para o systemd. É o
haltcomando dos initutilitários "System 5" da van Smoorenburg .
- Ignore as declarações às quais
/sbin/halté um link simbólico /sbin/reboot; isso não é verdade com o systemd. Não há nenhum rebootprograma separado .
- Ignore as instruções que
haltou rebootinvocam um shutdownprograma com argumentos de linha de comando; eles também não são verdadeiros com o systemd. Não há nenhum shutdownprograma separado .
Todo conjunto de ferramentas de gerenciamento do sistema tem sua versão desses utilitários. systemd, arrivista, nosh , van Smoorenburg inite BSD inittodos têm a sua própria halt, poweroffe assim por diante. Em cada uma delas, sua mecânica é um pouco diferente. O mesmo acontece com as páginas de manual.
No conjunto de ferramentas systemd halt, poweroff,reboot , telinit, e shutdownsão todos os links simbólicos para /bin/systemctl. Eles são todos os calços compatibilidade com versões anteriores, que são simplesmente atalhos para invocar interface de linha de comando primário de systemd: systemctl. Todos eles mapeiam (e de fato são) o mesmo programa único . (Por convenção, o shell diz a que nome foi chamado.)
destinos, não níveis de execução
A maioria desses comandos são atalhos para dizer ao systemd, usando systemctl, para isolar um destino específico . O isolamento é explicado na systemctlpágina de manual (qv), mas, para os fins desta resposta, pode ser considerado como iniciar um alvo e parar qualquer outro. Os destinos padrão usados no systemd estão listados na systemd.specialpágina de manual (8).
Os diagramas na bootuppágina de manual (7) no conjunto de ferramentas systemd, em particular o último, mostram que existem três destinos "finais" relevantes aqui:
halt.target- Depois que o sistema atingir o estado de isolar completamente esse destino, ele terá chamado a reboot(RB_HALT_SYSTEM)chamada de sistema. O kernel terá tentado entrar em um programa de monitoramento de ROM ou simplesmente interrompido a CPU (usando qualquer mecanismo apropriado para isso).reboot.target- Depois que o sistema atingir o estado de isolar completamente esse destino, ele terá chamado a reboot(RB_AUTOBOOT)chamada de sistema (ou o equivalente à linha de comando mágica). O kernel terá tentado acionar uma reinicialização.poweroff.target- Depois que o sistema atingir o estado de isolar completamente esse destino, ele terá chamado a reboot(RB_POWER_OFF)chamada de sistema. O kernel terá tentado remover a energia do sistema, se possível.
Essas são as coisas em que você deve pensar como o sistema final declara, não executar níveis. Observe no diagrama que o próprio sistema systemd de destino codifica coisas que são, em outros sistemas, implícitas e não explícitas: como a noção de que cada um desses destinos finais abrange o shutdown.targetdestino, de modo que se descreve serviços que devem ser interrompidos antes do desligamento por tê-los em conflito com o shutdown.targetalvo.
systemctltenta enviar solicitações para systemd-logindquando o usuário que chama não é o superusuário. Ele também passa os desligamentos atrasados para systemd-shutdownd. E algumas atalhos acionam wallnotificações. Essas complexidades à parte, que tornariam essa resposta várias vezes mais longa, supondo que você seja o superusuário no momento e não solicite uma ação agendada:
systemctl isolate halt.target tem as taquigrafia:
shutdown -H nowsystemctl halt- simples sem adornos
halt
systemctl isolate reboot.target tem as taquigrafia:
shutdown -r nowtelinit 6systemctl reboot- simples sem adornos
reboot
systemctl isolate poweroff.target tem as taquigrafia:
shutdown -P nowtelinit 0shutdown nowsystemctl poweroff- simples sem adornos
poweroff
systemctl isolate rescue.target tem as taquigrafia:
telinit 1 systemctl rescue
systemctl isolate multi-user.target tem as taquigrafia:
telinit 2telinit 3telinit 4
systemctl isolate graphical.target tem a abreviação:
Após analisar as várias sintaxes diferentes da linha de comando, todas elas acabam nos mesmos caminhos de código dentro do systemctlprograma.
Notas:
- O comportamento tradicional do sem opção
shutdown nowtem sido mudar para o modo de usuário único . Este não é o caso do systemd. rescue.target- o modo de usuário único sendo renomeado para modo de recuperação no systemd - não pode ser acessado com o shutdowncomando
telinit realmente não totalmente ignorar todos aqueles e links simbólicos no sistema de arquivos que as páginas do manual descrever. Os mapeamentos citados anteriormente são conectados ao programa em uma tabela.runlevelN.targetdefault.targetsystemctl- systemd não tem noção de um nível de execução atual . A operação desses comandos não depende de nenhum "se você estiver no nível de execução N ".
- A
--forceopção para o halt, reboote poweroffcomandos é o mesmo que dizer --force --forceaos systemctl halt, systemctl reboote systemctl poweroffcomandos. Isso faz com que systemctltente ligar reboot()diretamente. Normalmente, apenas tenta isolar alvos.
telinitnão é o mesmo que init. São programas diferentes no mundo sistêmico, sendo este último outro nome para o systemdprograma, não para o systemctlprograma. O systemdprograma não é necessariamente compilado com nenhuma compatibilidade de van Smoorenburg e, em alguns sistemas operacionais do sistema, reclama de ter sido chamado incorretamente se alguém tentar .init N
Leitura adicional