Différence entre Systemctl et Service

73

systemd nous donne la commande 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 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.

La seule différence entre les commandes service et systemctl est-elle que systemctl peut démarrer des services au moment de l'exécution? Peut-on utiliser systemctl sur n'importe quel service? Quelles sont les autres différences significatives?

    
posée luv.preet 10.04.2017 - 23:35
la source

2 réponses

66

La commande service 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 wrapper pour les scripts /etc/init.d et la commande initctl de Upstart, et maintenant c'est aussi un wrapper pour ces deux et systemctl .

Utiliser la source, Luke!

Il vérifie 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 également, il revient 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

Comme la commande service 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 peut fournir.

Pour la portabilité sur différentes versions d'Ubuntu, les utilisateurs peuvent utiliser de manière fiable la commande service pour démarrer, arrêter, redémarrer ou examiner le statut d'un service. Pour les tâches plus complexes, cependant, la commande utilisée étant que initctl ou systemctl ou le script /etc/init.d peut devoir être utilisé directement.

En outre, étant un wrapper, le script service dans certains cas fait aussi plus que la commande équivalente directe pourrait faire. Par exemple:

  • Il exécute toujours les scripts /etc/init.d dans un environnement propre. (Notez l'invocation de la commande long env dans la fonction run_via_sysvinit ci-dessus.)
  • Il mappe restart sur les systèmes Upstart avec une combinaison de stop / start , car un simple initctl restart sera renvoyé 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 substitutions), et les scripts System V étaient activés ou désactivés avec la commande update-rc.d (qui gérait les liens symboliques dans les répertoires /etc/rc* ). % command n'a jamais été impliqué dans l'activation ou la désactivation des services au démarrage.

    
réponse donnée muru 11.04.2017 - 05:03
la source
20
  • systemd est rétrocompatible avec SysV.
  • charge les services parallèles au démarrage
  • il fournit l'activation à la demande d'un service
  • il est basé sur les dépendances
  • et beaucoup plus je suppose ...

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

systemd travaille avec les unités, il existe différents types d'unités: les cibles, les services, les sockets, etc.

Vous pouvez utiliser systemctl pour 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 conscient:

# 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 pourront pas l'activer / l'activer. (vous devriez le démasquer en premier).

Une autre utilisation de systemctl consiste à lister les unités:

systemctl list-units

Quelle liste de toutes les 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 [email protected] list-units

D'autre part, service fait ce qu'il doit faire, en gérant les services et en n'ayant rien à voir avec les affaires des autres;)

    
réponse donnée Ravexina 10.04.2017 - 23:53
la source

Lire d'autres questions sur les étiquettes