Differenza tra systemctl init.d e servizio

Sono nuovo di Linux e mi sto testando usando un'istanza di Amazon Lightsail (Ubuntu 16.04 LTS).

Scorrendo le numerose guide che ho incontrato, vedo persone che usano comandi diversi per avviare / arrestare / riavviare / ricaricare / controllare lo stato di un servizio. In particolare questi;

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

Tutti i comandi sopra funzionano.

1. Dovrei preferire un comando all'altro?
2. Se sì, allora perché?
3. Ci sono altri comandi di cui devo essere consapevole?

L'uso di init.d in Monit ha causato problemi quando volevo usare l'opzione di stato (lo stato sarà che il servizio è offline quando era effettivamente online - riavviato da Monit). Cambia il codice in Monit da inid.d a / bin / systemctl risolto.

Sembra che l'uso di init.d fornisca maggiori informazioni su ciò che è accaduto agli altri. Se dovessi utilizzare uno degli altri comandi, è possibile che visualizzino più informazioni su ciò che è stato fatto?

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:~$

Vorrei ringraziare in anticipo tutti coloro che hanno avuto il tempo di leggere e rispondere a questa domanda.

Per iniziare, c'è un'intera storia e una lotta tra il passare da SysVInita SystemD. Invece di provare a scomporre tutto in una sola risposta, ti rimanderò ad alcuni google che si avventurano per maggiori dettagli sulla storia e un articolo particolare sull'argomento:

http://www.tecmint.com/systemd-replaces-init-in-linux/

In sintesi, però, è stata una transizione lenta e ardua. Alcune funzionalità legacy sono state mantenute intatte (come init.din una certa misura). Se hai l'opzione da utilizzare systemctlper il controllo del servizio, ti consiglio di utilizzarlo. È il futuro prevedibile per Linux e alla fine i SysVInitmetodi più vecchi saranno considerati completamente deprecati e rimossi.

Per coprire ognuno di quelli elencati in modo specifico:

1. sudo systemctl status apache2.service

Questo è il nuovo SystemDapproccio alla gestione dei servizi. Andando avanti, le applicazioni su Linux sono progettate per utilizzare il metodo systemd, non un altro.

2. sudo /bin/systemctl status apache2.service

Questa è la stessa cosa del comando precedente. L'unica differenza in questo caso è che non dipende dalla $PATHvariabile d'ambiente della shell per trovare il comando, ma sta elencando il comando esplicitamente includendo il percorso del comando.

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

Questo è il SysVInitmetodo originale per chiamare un servizio. Gli script Init verrebbero scritti per un servizio e inseriti in questa directory. Mentre questo metodo è ancora usato da molti, è servicestato il comando che ha sostituito questo metodo di chiamata ai servizi SysVInit. Ci sono alcune funzionalità legacy per questo sui sistemi più recenti con SystemD, ma la maggior parte dei programmi più recenti non lo include e non tutti gli script di inizializzazione delle applicazioni precedenti funzionano con esso.

4. sudo service apache2 status

Questo era lo strumento principale utilizzato sui SysVInitsistemi per i servizi. In alcuni casi si è appena collegato agli /etc/init.d/script, ma in altri casi è andato a uno script init memorizzato altrove. Era destinato a fornire una transizione più fluida nella gestione delle dipendenze del servizio.

Infine, dici che vuoi sapere come ottenere più informazioni dai comandi, poiché alcuni forniscono più informazioni di altri. Questo è quasi sempre determinato dall'applicazione e da come hanno progettato il loro file init o di servizio. Come regola generale, tuttavia, se è stato completato in silenzio, ha avuto successo. Tuttavia, per verificare un start, stopo restart, è possibile utilizzare il statuscomando secondario per vedere come sta andando. Hai menzionato un statuscomando errato su un vecchio script init. Questo è un bug che gli sviluppatori dell'applicazione dovrebbero guardare. Tuttavia, poiché gli script init stanno diventando il metodo obsoleto di gestione dei servizi, possono semplicemente ignorare il bug fino a quando non rimuovono completamente l'opzione di script init. Ilsystemctl status dovrebbe sempre funzionare correttamente altrimenti un bug dovrebbe essere registrato con gli sviluppatori dell'applicazione.