O systemd ainda tem o conceito de níveis de execução? Por exemplo, é inútil usar telinit <number>?

Nível baixo de execução do SystemD

No SystemD (aemon), os níveis de execução são expostos como "Destinos". O conceito ainda está lá, mas o fluxo de trabalho para produzir o resultado desejado para seus requisitos é diferente.

O anexo deve esclarecer esta questão.

Como altero o nível de execução atual?

$ systemctl isolate runlevelX.target

Como altero o nível de execução padrão para a próxima inicialização?

# Create a symlink
$ ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

• ln -sf TARGET DESTINATION
• -s cria um link simbólico
• -f remove o arquivo de destino existente

OU (como @centimane sugeriu) simplesmente use o systemdcomando "abençoado" :

systemctl set-default [target name].target

Como identifico o nível de execução atual?

$ systemctl list-units --type=target

Não. Como as pessoas do sistema escreveram duas vezes, uma vez no telinitmanual e outra no runlevelmanual, os níveis de execução são "obsoletos". Você pode esquecer os níveis de execução.

Essas coisas realmente não existem no systemd, com alguns shims de compatibilidade.

• Existem alguns links simbólicos para nomes de destinos, mas esses destinos nunca são realmente usados ​​pelo sistema adequado.
  • Em vez disso, o processo de autoinicialização emprega um default.target(e daí um ou ambos de a graphical.targete a multi-user.target), a rescue.targetou um emergency.target. E o processo de desligamento envolve a shutdown.target, a reboot.target, a halt.targetou a poweroff.target. Nenhum destino em nível de execução está envolvido na inicialização ou no desligamento.
  • O telinitcomando, que se pode pensar que usa os links simbólicos de compatibilidade para mapear seus argumentos de linha de comando, também não o faz. Há uma mesa com fio no código fonte do telinitprograma, e os números 2, 3, 4, e 5como argumentos para o comando são conectados para mapear multi-user.targete graphical.target.
  • systemd-update-utmp também possui uma tabela interna com fio.
• Não existe uma "tabela de inicialização" de itens de nível de execução. O systemd é compatível apenas com van Smoorenburg rc, não com van Smoorenburg init.
• Não há valor de "nível de execução atual" mantido pelo próprio systemd. Pelo contrário, o quase totalmente indocumentados systemd-update-utmpcomando opera internamente em termos de activação estados de rescue.target, multi-user.targete graphical.target.
• systemd-sysv-generator, o gerador da unidade de serviço de compatibilidade com versões anteriores do systemd, mescla os /etc/rc[234].ddiretórios em apenas um Wanted-Byrelacionamento multi-user.targetnas unidades de serviço geradas. Não há referência real para executar níveis nas unidades de serviço geradas. (Havia alguns anos atrás, mas as pessoas do sistema descobriram que isso deu errado, porque não estavam sendo referenciadas em nenhum outro lugar.)

Se alguém é usuário de um sistema que constrói systemd como o Arch Linux para o interlocutor em " Por que o init 0` resulta em" Excesso de Argumentos "na instalação do Arch? ", Nem sequer obtém os shims de compatibilidade e comanda tais como init 0resultado no comportamento "nativo" do systemd, que consiste em reclamar que o comando foi invocado incorretamente.

Leitura adicional

• Lennart Poettering et al runlevel. páginas de manual do systemd. Freedesktop.org.
• Lennart Poettering et al telinit. páginas de manual do systemd. Freedesktop.org.
• Lennart Poettering et al bootup. páginas de manual do systemd. Freedesktop.org.
• Lennart Poettering (08-02-2015). em qualquer lugar: remova a configurabilidade do nível de execução sysv para mapear o destino . systemd. github.
• /unix//a/196014/5132
• /unix//a/196197/5132
• /unix//a/233581/5132
• /unix//a/211927/5132
• /unix//a/392612/5132
• Jonathan de Boyne Pollard (2015). /etc/inittabé uma coisa do passado. . Respostas dadas com freqüência.

Muito obrigado. Então, se eu entendi corretamente:

Por exemplo:

ls -ll /usr/lib/systemd/system/runlevel*.target

Resultado:

/usr/lib/systemd/system/runlevel0.target -> poweroff.target
/usr/lib/systemd/system/runlevel1.target -> rescue.target
/usr/lib/systemd/system/runlevel2.target -> multi-user.target
/usr/lib/systemd/system/runlevel3.target -> multi-user.target
/usr/lib/systemd/system/runlevel4.target -> multi-user.target
/usr/lib/systemd/system/runlevel5.target -> graphical.target
/usr/lib/systemd/system/runlevel6.target -> reboot.target

Então, como você pode ver, o conceito de níveis de execução existe, mas é bastante obsoleto devido ao fato de os arquivos runlevel.target não serem realmente arquivos "reais", mas vincular softwares ao novo, moderno e melhor nomeado esquema de arquivos que O systemd gosta de chamá-los de "alvos".

Então, se você gostaria de fazer algo assim telinit 5, seria assim: o systemctl isolate runlevel5.target que é idêntico a: systemctl isolate graphical.target(recomendado na minha opinião).

Apenas no caso de você estar interessado em conhecer todos os alvos possíveis:

ls /usr/lib/systemd/system/*.target

O systemd introduziu os destinos como uma contrapartida dos níveis de execução no sistema sysV init. Os desenvolvedores do sytemd tornaram quase compatível com a maioria dos scripts sysV. O mesmo acontece para telinit <runlevel>. Isso é traduzido em equivalente ao systemd.

Por exemplo, telinit 0desliga a máquina. O systemd possui poweroff.target para fazer o mesmo que o nível de execução 0 . Então, telinit 0é traduzido pelo systemd para ativar o poweroff.target .

Mas existem alguns problemas de compatibilidade nos sistemas sytemd e sysV init-> https://www.freedesktop.org/wiki/Software/systemd/Incompatibilidades .