Diferença entre systemctl init.d e service

Question

Eu sou novo no Linux e tenho me testado usando uma instância do Amazon Lightsail (Ubuntu 16.04 LTS).

Passando pelos muitos guias que encontrei, vejo pessoas usando comandos diferentes para iniciar / parar / reiniciar / recarregar / status-verificar um serviço. Especificamente, estes;

sudo systemctl status apache2.service
sudo /bin/systemctl status apache2.service
sudo /etc/init.d/apache2 status
sudo service apache2 status

Todos os comandos acima funcionam.

1. Eu deveria preferir um comando sobre o outro?
2. Se sim, então por quê?
3. Há algum outro comando que precise estar ciente?

O uso do init.d no Monit causou problemas quando eu queria usar a opção status (o status seria que o serviço estivesse offline quando estivesse realmente online - reiniciado pelo Monit). Altere o código em Monit de inid.d para / bin / systemctl corrigido.

Parece que o uso do init.d fornece mais informações sobre o que aconteceu com os outros. Se eu deveria estar usando um dos outros comandos, é possível que eles exibam mais informações sobre o que foi feito?

ubuntu@ip-172-26-12-245:~$ sudo systemctl restart pure-ftpd.service
ubuntu@ip-172-26-12-245:~$ sudo /bin/systemctl restart pure-ftpd.service
ubuntu@ip-172-26-12-245:~$ sudo /etc/init.d/pure-ftpd restart
[ ok ] Restarting pure-ftpd (via systemctl): pure-ftpd.service.
ubuntu@ip-172-26-12-245:~$ sudo service pure-ftpd restart
ubuntu@ip-172-26-12-245:~$

Gostaria de agradecer antecipadamente a todos que dedicaram tempo para ler e responder a esta pergunta.

    

Answer 1

Para começar, há todo um histórico e a luta entre ir de SysVInit a SystemD . Ao invés de tentar quebrar tudo isso em uma resposta, eu vou encaminhá-lo para algum google se aventurando por mais detalhes sobre a história, bem como um artigo específico sobre o tema:

link

Em resumo, tem sido uma transição lenta e árdua. Alguns recursos legados foram mantidos intactos (como init.d até certo ponto). Se você tem a opção de usar systemctl para o seu controle de serviço, eu recomendo usar esse. É o futuro previsível para o Linux e, eventualmente, os métodos SysVInit mais antigos serão considerados completamente obsoletos e removidos.

Para cobrir cada um que você listou especificamente:

1. sudo systemctl status apache2.service

Esta é a nova abordagem SystemD para o tratamento de serviços. Avançando, os aplicativos no Linux são projetados para usar o método systemd, e não qualquer outro.

2. sudo /bin/systemctl status apache2.service

É a mesma coisa que o comando anterior. A única diferença neste caso é que não depende da variável de ambiente $PATH do shell para encontrar o comando, ele está listando o comando explicitamente incluindo o caminho para o comando.

3. sudo /etc/init.d/apache2 status

Este é o método original SysVInit de chamar um serviço. Os scripts de inicialização seriam gravados para um serviço e colocados nesse diretório. Embora esse método ainda seja usado por muitos, service foi o comando que substituiu esse método de chamar serviços em SysVInit . Há alguma funcionalidade legada para isso em sistemas mais novos com SystemD , mas a maioria dos programas mais recentes não inclui isso, e nem todos os scripts init de aplicativos mais antigos funcionam com ele.

4. sudo service apache2 status

Esta foi a principal ferramenta usada em SysVInit systems for services. Em alguns casos, ele apenas se vinculou aos scripts /etc/init.d/ , mas em outros casos, ele foi para um script de inicialização armazenado em outro lugar. O objetivo era fornecer uma transição mais suave para o tratamento de dependência de serviço.

Por último, você menciona querer saber como obter mais informações dos comandos, pois alguns fornecem mais informações do que outros. Isso é quase sempre determinado pelo aplicativo e como eles criaram seu arquivo de inicialização ou de serviço. Como regra geral, porém, se completou silenciosamente, foi bem sucedido. No entanto, para verificar um start , stop ou restart , você pode usar o subcomando status para ver como está indo. Você mencionou um comando status incorreto em um script de inicialização antigo. Esse é um bug que os desenvolvedores de aplicativos teriam que examinar. No entanto, como os scripts de init estão se tornando o método obsoleto de manipulação de serviços, eles podem simplesmente ignorar o bug até remover completamente a opção de script de inicialização. O systemctl status deve sempre funcionar corretamente, caso contrário, um bug deve ser registrado com os desenvolvedores de aplicativos.