Différence entre les commandes systemctl et de service

systemdnous donne la systemctlsuite de commandes 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_nameet service_namedé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 serviceet peut-elle être utilisée pour permettre le démarrage de services au moment de l'exécution? Pouvons-nous utiliser n'importe quel service? Quelles sont les autres différences significatives?systemctlsystemctlsystemctl

La servicecommande est un script de wrapper qui permet aux administrateurs système de démarrer, d’arrêter et de vérifier le statut des services sans trop s’inquiéter du système init utilisé. Avant l'introduction de systemd, c'était un wrapper pour les /etc/init.dscripts et la initctlcommande d'Upstart , et maintenant c'est un wrapper pour ces deux-là et systemctl aussi.

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 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, les /etc/init.dscripts System V sont utilisés:

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

Comme la servicecommande est un wrapper assez 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 la servicecommande de manière fiable pour démarrer, arrêter, redémarrer ou examiner le statut d'un service. Pour des tâches plus complexes, cependant, la commande utilisée, que ce initctlsoit systemctlou ou le /etc/init.dscript doive être utilisé directement.

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

• Il exécute toujours des /etc/init.dscripts dans un environnement propre. (Notez l' invocation de commande longue env dans la run_via_sysvinitfonction ci-dessus.)
• Il mappe restartsur les systèmes Upstart une combinaison de stop/ start, puisqu'un message d' initctl restarterreur se produira 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 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 update-rc.dcommande (qui gérait les liens symboliques dans les /etc/rc*répertoires). Elle servicen'a donc jamais été impliquée dans l'activation ou la désactivation de services au démarrage. .

• 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é qui systemctlest capable de.

systemd fonctionne avec des unités, il existe différents types d’unités: cibles, services, sockets, etc. Les cibles correspondent au même concept que les niveaux de fonctionnement, c’est 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 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 systemctlpour gérer des 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 auquel il sera lié /dev/null, il ne peut donc pas l'activer / l'activer manuellement ou automatiquement. (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

D'autre part servicefait ce qu'il doit faire, la gestion des services et n'a rien à voir avec les affaires des autres peuples;)