web-dev-qa-db-fra.com

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.

16.04amazon-ec2init.d
33
Waqas Tariq

Pour commencer, il y a toute une histoire et une difficulté à surmonter pour passer de SysVInità SystemDname__. 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 fonctionnalités héritées sont restées intactes (telles que init.d dans une certaine mesure). 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, éventuellement, les anciennes méthodes SysVInitseront 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

Il s'agit de la nouvelle approche SystemDpour la gestion des services. À l'avenir, les applications sur Linux sont conçues pour utiliser la méthode systemd, pas une autre.

  1. 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 recherche de la commande ne dépend pas de la variable d'environnement $PATH du Shell, elle répertorie explicitement la commande en incluant le chemin d'accès à la commande.

  1. Sudo /etc/init.d/Apache2 status

Il s'agit de la méthode SysVInitd'origine permettant 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 encore utilisée par beaucoup, serviceest la commande qui a remplacé cette méthode d’appel sur les services dans SysVInitname__. Il existe certaines fonctionnalités héritées pour cela sur les systèmes plus récents avec SystemDname__, 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.

  1. Sudo service Apache2 status

Il s’agissait du principal outil utilisé sur les systèmes SysVInitpour les services. Dans certains cas, il est simplement lié aux scripts /etc/init.d/, mais dans d'autres cas, il est utilisé dans 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 une startname__, stopou restartname__, vous pouvez utiliser la sous-commande statuspour voir comment cela se passe. Vous avez mentionné qu'une commande statusétait incorrecte sur un ancien script d'initialisation. C'est un bug que les développeurs d'applications devraient examiner. Cependant, 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. Le systemctl status devrait toujours fonctionner correctement, sinon un bogue devrait être enregistré avec les développeurs de l'application.

50
TopHat