web-dev-qa-db-fra.com

Différence entre les commandes systemctl et de service

systemd nous donne la suite de commandes systemctl qui est 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, par exemple, Sudo systemctl enable service_name, et service_name démarrera automatiquement au démarrage. Nous pouvons également désactiver les services pour ne pas démarrer au démarrage.

La seule différence entre les commandes service et systemctl est-elle que systemctl peut être utilisé pour activer le démarrage des services au moment de l'exécution? Pouvons-nous utiliser systemctl sur n’importe quel service? Quelles sont les autres différences significatives?

command-lineservicessystemd
129
luv.preet

La commande serviceest un script d'encapsulation qui permet aux administrateurs système de démarrer, d'arrêter et de vérifier le statut des services sans trop se préoccuper du système init utilisé. Avant l’introduction de systemd, c’était un wrapper pour les scripts /etc/init.d et la commande initctlde Upstart. À présent, c’est un wrapper pour ces deux et systemctlname__.

tilisez 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 cherche 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 également, il retourne aux scripts System V /etc/init.d:

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

Étant donné que la commande serviceest un encapsuleur relativement simple, elle ne prend en charge qu'un sous-ensemble limité d'actions par rapport à ce que le système init réel pourrait fournir.

Pour la portabilité sur différentes versions d'Ubuntu, les utilisateurs peuvent utiliser de manière fiable la commande servicepour démarrer, arrêter, redémarrer ou examiner le statut d'un service. Pour les tâches plus complexes, toutefois, la commande utilisée, que initctlou systemctlou le script /etc/init.d soit éventuellement utilisée directement.

De plus, en tant que wrapper, le script servicefait parfois plus que ne le ferait une commande directe équivalente. Par exemple:

  • Il exécute toujours les scripts /etc/init.d dans un environnement propre. (Notez le long invocation de commande envdans la fonction run_via_sysvinit ci-dessus.)
  • Il mappe restartsur les systèmes Upstart à une combinaison de stopname __/startname__, puisqu'un initctl restart brut se produira si le service n'est pas déjà en cours d'exécution.

  • 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 ont été activés directement dans le fichier de configuration du service (ou désactivés via des substitutions), et les scripts System V ont été activés ou désactivés avec la commande update-rc.d (qui gérait les liens symboliques dans les répertoires /etc/rc*). La commande servicen'a donc jamais été impliquée dans l'activation ou la désactivation. services au démarrage.

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

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

systemd fonctionne avec des unités, il existe différents types d'unités: cibles, services, sockets, etc. Les cibles sont identiques au même concept que les niveaux d'exécution, elles constituent un ensemble d'unités.

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

systemctl get-default

Vous pouvez aller dans d'autres cibles:

systemctl isolate multiuser.target

Les autres cibles sont: multi-utilisateur, graphique, recue, urgence, redémarrage, extinction.

Comme vous l'avez dit, vous pouvez utiliser systemctl pour gérer les services. Certaines des commandes associées à la gestion des services dont je suis au courant sont les suivantes:

# 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

Lorsque vous masquez un service, celui-ci sera lié à /dev/null. Par conséquent, manuellement ou automatiquement, les autres services ne peuvent pas l'activer/l'activer. (vous devriez d'abord le démasquer).

Une autre utilisation de systemctl est de lister les unités:

systemctl list-units

Quelle liste toutes sortes d'unités, chargées et actives.

Liste des unités de service:

systemctl list-units --type=service

Ou pour lister toutes les unités disponibles, pas seulement celles 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 [email protected] list-units

De même, service fait ce qu’il a à faire, gérer les services et n’avoir rien à voir avec les affaires des autres peuples;)

31
Ravexina