Question Différence entre Systemctl et Service


systemd nous donne le systemctl commande principalement utilisée pour permettre aux services de démarrer au démarrage. Nous pouvons également démarrer, arrêter, recharger, redémarrer et vérifier l’état des services à l’aide de systemctl.

Nous pouvons faire sudo systemctl enable service_name, et le service démarrera automatiquement au démarrage. Nous pouvons également désactiver les services pour ne pas démarrer au démarrage.

Est la seule différence entre le service et systemctl commandes que systemctl peut lancer des services à l'exécution? Pouvons-nous utiliser systemctl sur n'importe quel service? Quelles sont les autres différences significatives?


79
2018-04-10 21:35


origine


Je pense que vous avez choisi la mauvaise réponse, moi-même. - Evan Carroll


Réponses:


le service command est un script d'encapsulation qui permet aux administrateurs système de démarrer, d'arrêter et de vérifier l'état des services sans trop se soucier du système d'initialisation utilisé. Avant l'introduction de systemd, c'était un emballage pour /etc/init.d scripts et Upstart's initctl commande, et maintenant c'est un wrapper pour ces deux et  systemctl ainsi que.

Utilisez la source, Luke!

Il vérifie pour Upstart:

# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \
   && initctl version 2>/dev/null | grep -q upstart \
   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
   # Upstart configuration exists for this job and we're running on upstart

Si cela ne fonctionne pas, il recherche systemd:

if [ -d /run/systemd/system ]; then
   is_systemd=1
fi

...

# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then

Et si cela échoue aussi, il revient au système V /etc/init.d scripts:

run_via_sysvinit() {
   # Otherwise, use the traditional sysvinit
   if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
      exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
   else
      echo "${SERVICE}: unrecognized service" >&2
      exit 1
   fi
}

...
run_via_sysvinit

Depuis le service command est un wrapper assez simple, il ne supporte qu'un sous-ensemble limité d'actions par rapport à ce que le système init pourrait fournir.

Pour la portabilité sur diverses versions d'Ubuntu, les utilisateurs peuvent utiliser de manière fiable le service commande pour démarrer, arrêter, redémarrer ou examiner le statut d'un service. Pour des tâches plus complexes, cependant, la commande en cours d'utilisation, que ce soit initctl ou systemctl ou la /etc/init.d le script devra peut-être être utilisé directement.

En outre, étant un emballage, le service Dans certains cas, le script fait plus que ce que la commande équivalente directe peut faire. Par exemple:

  • Il exécute toujours /etc/init.d scripts dans un environnement propre. (Noter la longue  env invocation de commande dans le run_via_sysvinit fonction ci-dessus.)
  • Il cartographie restart sur des systèmes Upstart à une combinaison de stop/start, depuis une plaine initctl restart sera erreur si le service ne fonctionne pas déjà.
  • Il arrête les sockets lors de l'arrêt des services systemd auxquels sont associés des sockets:

    case "${ACTION}" in
      restart|status)
         exec systemctl $sctl_args ${ACTION} ${UNIT}
      ;;
      start|stop)
         # Follow the principle of least surprise for SysV people:
         # When running "service foo stop" and foo happens to be a service that
         # has one or more .socket files, we also stop the .socket units.
         # Users who need more control will use systemctl directly.
    

Les services upstart étaient activés directement dans le fichier de configuration du service (ou désactivés via des remplacements), et les scripts System V étaient activés ou désactivés avec le update-rc.d commande (qui gère les liens symboliques dans le /etc/rc* répertoires), donc le service command n'a jamais été impliqué dans l'activation ou la désactivation des services au démarrage.


72
2018-04-11 03:03



superbe explication, merci. - Willa O Ng'wana


  • systemd est rétrocompatible avec SysV.
  • charge les services parallèles au démarrage
  • il fournit l'activation à la demande d'un service
  • c'est la dépendance basée
  • et beaucoup plus je suppose ...

Il y a beaucoup plus que ce que vous avez mentionné systemctl est capable de.

systemd fonctionne avec les unités, il existe différents types d'unités: les cibles, les services, les sockets, etc. Les cibles sont les mêmes concepts que les niveaux d'exécution, elles forment un ensemble d'unités.

Vous pouvez utiliser systemctlpour définir ou obtenir la cible système par défaut.

systemctl get-default

Vous pouvez entrer dans d'autres cibles:

systemctl isolate multiuser.target

Les autres cibles sont les suivantes: multi-utilisateur, graphique, récupération, urgence, redémarrage, mise sous tension.

Comme vous l'avez dit, vous pouvez utiliser systemctl Pour gérer les services, certaines des autres commandes liées à la gestion des services dont je suis au courant sont:

# Restarts a service only if it is running.
systemctl try-restart name.service

# Reloads configuration if it's possible.
systemctl reload name.service

# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service

Vous pouvez l'utiliser pour connaître l'état d'un service:

systemctl status name.service

systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load

Vous pouvez masquer ou démasquer un service:

systemctl mask name.service
systemctl unmask name.service

Si vous masquez un service, il sera lié à /dev/null, donc manuellement ou automatiquement, d'autres services ne peuvent pas l'activer / l'activer. (vous devriez le démasquer en premier).

Un autre usage de systemctl consiste à lister les unités:

systemctl list-units

Quelle liste tous les types d'unités, chargées et actives.

Liste des unités de service:

systemctl list-units --type=service

Ou pour répertorier toutes les unités disponibles non seulement chargées et activées:

systemctl list-unit-files

Vous pouvez créer des alias ou même contrôler des machines distantes

systemctl --host ravexina@192.168.56.4 list-units

D'autre part service fait ce qu'il doit faire, gérer les services et ne rien avoir avec les affaires des autres;)


21
2018-04-10 21:53



c'était une réponse parfaite, y a-t-il quelque chose qui service peut faire mais pas systemctl ? - luv.preet
Rien que je sache à ce sujet, je pense avoir un regard sur page de manuel du service serait utile. - Ravexina
Il y a quelques différences évidentes. La syntaxe est un. Une autre est que les scripts systemv ne traitaient jamais les sockets, pour autant que je sache. Le fait que systemd essaie de gérer le type de réseau est un autre, et c'est un point de critique fréquent. Surtout, systemd essaie de faire plus que de simplement démarrer des services - Sergiy Kolodyazhnyy
Je voudrais faire une réclamation ici à propos de systemd masquant les messages de journal de l'échec service start tentatives. Pré-système, service start me laisser voir tout de suite pourquoi mon service ne commencerait pas. Après le système, je dois examiner quatre ou cinq journaux différents avant de pouvoir le trouver. Cela dit, mon commentaire est sans aucun doute hors sujet et sera probablement supprimé. - Ross Presser
AFAICS Cette réponse ne semble rien dire du service commande, cela ne faisait-il pas partie de la question? - ilkkachu