Différence entre systemctl init.d et service

Je suis nouveau sur Linux et je me teste en utilisant une instance Amazon Lightsail (Ubuntu 16.04 LTS).

En parcourant les nombreux guides que j'ai rencontrés, je vois des personnes utiliser différentes commandes pour démarrer / arrêter / redémarrer / recharger / vérifier l'état d'un service. Plus précisément ceux-ci;

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

Toutes les commandes ci-dessus fonctionnent.

1. Devrais-je préférer une commande à une autre?
2. Si oui, alors pourquoi?
3. Dois-je connaître d'autres commandes?

L'utilisation de init.d dans Monit a posé des problèmes lorsque je voulais utiliser l'option de statut (le statut sera que le service est hors ligne alors qu'il était en ligne - redémarré par Monit). Modifiez le code dans Monit de inid.d à / bin / systemctl, corrigez-le.

Il semble que l'utilisation de init.d fournisse plus d'informations sur ce qui s'est passé que les autres. Si je devais utiliser l'une des autres commandes, est-il possible de les afficher davantage d'informations sur ce qui a été fait?

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

Je voudrais remercier d'avance tous ceux qui ont pris le temps de lire et de répondre à cette question.

Pour commencer, il y a toute une histoire et de la lutte entre aller de SysVInitla SystemD. Plutôt que d'essayer de tout décomposer en une seule réponse, je vous renvoie à une page de Google pour plus de détails sur l'historique, ainsi qu'à un article sur le sujet:

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

En résumé, la transition a été lente et pénible. Certaines caractéristiques héritées sont restées intactes (dans init.dune certaine mesure, par exemple). Si vous avez la possibilité d'utiliser systemctlpour votre contrôle de service, je vous recommande de l'utiliser. C'est l'avenir prévisible pour Linux et les SysVInitméthodes les plus anciennes seront finalement considérées comme totalement obsolètes et supprimées.

Pour couvrir chacun de ceux que vous avez énumérés spécifiquement:

1. sudo systemctl status apache2.service

C'est la nouvelle SystemDapproche de la gestion des services. À l'avenir, les applications sur Linux sont conçues pour utiliser la méthode systemd, pas une autre.

2. sudo /bin/systemctl status apache2.service

C'est la même chose que la commande précédente. La seule différence dans ce cas est que la $PATHrecherche de la commande ne dépend pas de la variable d'environnement du shell , elle répertorie explicitement la commande en incluant le chemin d'accès à la commande.

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

C'est la SysVInitméthode originale d'appeler un service. Les scripts d'initialisation seraient écrits pour un service et placés dans ce répertoire. Alors que cette méthode est toujours utilisée par beaucoup, serviceétait la commande qui a remplacé cette méthode d’appel aux services dans SysVInit. Il existe certaines fonctionnalités héritées pour cela sur les systèmes SystemDplus récents, mais la plupart des programmes plus récents n'incluent pas cela, et tous les anciens scripts d'initiation d'application ne fonctionnent pas avec.

4. sudo service apache2 status

C'était le principal outil utilisé sur les SysVInitsystèmes de services. Dans certains cas, il s'agissait uniquement de liens avec les /etc/init.d/scripts, mais dans d'autres cas, il s'agissait d'un script init stocké ailleurs. Il visait à faciliter la transition vers la gestion de la dépendance de service.

Enfin, vous mentionnez vouloir savoir comment obtenir plus d'informations à partir des commandes, car certaines fournissent plus d'informations que d'autres. Ceci est presque toujours déterminé par l’application et par la manière dont elle a conçu son fichier de service ou init. En règle générale cependant, s’il s’achève silencieusement, il réussit. Cependant, pour vérifier un start, stopou restart, vous pouvez utiliser la statussous-commande pour voir comment cela se passe. Vous avez mentionné qu'une statuscommande était incorrecte sur un ancien script d'initialisation. C'est un bug que les développeurs d'applications devraient examiner. Toutefois, les scripts init devenant la méthode de gestion des services déconseillée, ils peuvent simplement ignorer le bogue jusqu'à ce qu'ils suppriment entièrement l'option de script init. lesystemctl status devrait toujours fonctionner correctement, sinon un bogue devrait être enregistré avec les développeurs de l'application.