Os mais óbvios - isso é o que o systemctl substitui:
-
service -
chkconfigno redhat eupdate-rc.dno debian, se uma unidade systemd tiver sido escrita para o serviço. -
reboot,poweroff,halt,telinit. (Excetoreboot -fetc, que não tem nenhuma substituição documentada. Atualmente não está documentado, por exemplo, sesystemctl reboot --force --force[sic] deve funcionar após a inicialização cominit=/bin/bash) -
pm-suspende amigos aparentemente foram embora. Como um esforço de distribuição cruzada, é o tipo de coisa quesystemdpretende realizar; é apenas interessante, considerando os ganchos e peculiaridades que opm-utilssuportava, e não estou ciente de nenhuma falha do systemd em substituí-lo.
Além disso, systemd-analyze fornece uma função semelhante ao bootchart.
Como apontado por outros, provavelmente faz mais sentido enumerar os arquivos fornecidos pelo systemd, ou a documentação. Ao fazer isso, notei mais um comando obscuro, runlevel .
O systemd emula apenas os níveis de execução, portanto runlevel é outro dos comandos legados. Procurando por um comando equivalente transformado em systemctl list-units --type target (nota list-units mostra apenas unidades ativas, a menos que seja instruído de outra forma). A saída não é tão óbvia, porque os destinos tendem a depender de outros destinos e você pode ter vários destinos ativos ao mesmo tempo, independentes ou sobrepostos.
No entanto, por enquanto, não consigo pensar exatamente quando você usaria o comando runlevel . Tenho a impressão de que seria usado interativamente como um resumo do estado do sistema init. Nesse caso, a melhor alternativa seria systemctl status .