Différence entre les commandes systemctl et service

En service est un wrapper script qui permet aux administrateurs système de démarrer, d'arrêter et de vérifier l'état des services sans trop se préoccuper du système d'initialisation utilisé. Avant l'introduction de systemd, il s'agissait d'un wrapper pour /etc/init.d scripts et le programme Upstart de initctl et maintenant il s'agit d'une enveloppe pour ces deux commandes y systemctl également.

Utilise la source, Luke !

Il vérifie la présence d'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 en cas d'échec, on en 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 l'entrée en vigueur de la service est une enveloppe assez simple, elle ne prend en charge qu'un sous-ensemble limité d'actions par rapport à ce que le système d'initialisation réel pourrait fournir.

Pour assurer la portabilité des différentes versions d'Ubuntu, les utilisateurs peuvent utiliser de manière fiable le fichier service pour démarrer, arrêter, redémarrer ou examiner l'état d'un service. Pour des tâches plus complexes, cependant, la commande utilisée, qu'elle soit initctl o systemctl o el /etc/init.d Il se peut qu'il faille utiliser directement script.

En outre, comme il s'agit d'une enveloppe, le service Dans certains cas, script fait plus que ce que la commande équivalente directe pourrait faire. Par exemple :

• Il exécute toujours /etc/init.d scripts dans un environnement propre. (Notez que les long env dans l'invocation de la commande run_via_sysvinit ci-dessus).
• Il cartographie restart sur les systèmes Upstart à une combinaison de stop / start puisqu'un initctl restart se heurtera à une erreur 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 qui ont des sockets associées :

  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 des services (ou désactivés par des surcharges), et les scripts du système V ont été activés ou désactivés à l'aide de l'option update-rc.d (qui gère les liens symboliques dans le /etc/rc* ), de sorte que l'option service n'a jamais été impliquée dans l'activation ou la désactivation des services au démarrage.