Unterschied zwischen systemctl- und service-Befehlen


143

systemdgibt uns die systemctlBefehlssuite, die hauptsächlich verwendet wird, um den Start von Diensten zum Startzeitpunkt zu ermöglichen. Wir können mit Hilfe von auch Dienste starten, stoppen, neu laden, neu starten und deren Status überprüfen systemctl.

Dies können wir zum Beispiel tun sudo systemctl enable service_nameund service_namewerden beim Booten automatisch starten. Wir können auch Dienste deaktivieren, die nicht zum Startzeitpunkt gestartet werden.

Ist der einzige Unterschied zwischen den Befehlen serviceund systemctl, systemctlder zum Aktivieren des Starts von Diensten zur Laufzeit verwendet werden kann? Können wir systemctlfür jeden Dienst verwenden? Welche weiteren signifikanten Unterschiede gibt es?


Ich glaube, Sie haben selbst die falsche Antwort gewählt.
Evan Carroll

Antworten:


144

Der serviceBefehl ist ein Wrapper-Skript, mit dem Systemadministratoren den Status von Diensten starten, stoppen und überprüfen können, ohne sich über das tatsächlich verwendete Init-System Gedanken machen zu müssen. Vor systemd der Einführung war es ein Wrapper für /etc/init.dSkripte und die Upstart - initctlBefehl, und jetzt ist es ein Wrapper für diese beiden und systemctl auch.

Benutze die Quelle, Luke!

Es wird nach Upstart gesucht:

# 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

Wenn das nicht funktioniert, sucht es nach 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

Wenn dies ebenfalls fehlschlägt, wird auf System V- /etc/init.dSkripte zurückgegriffen:

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

Da der serviceBefehl ein relativ einfacher Wrapper ist, unterstützt er nur eine begrenzte Teilmenge von Aktionen im Vergleich zu dem, was das eigentliche Init-System möglicherweise bietet.

Für die Portabilität über verschiedene Versionen von Ubuntu können Benutzer den serviceBefehl zuverlässig zum Starten, Stoppen, Neustarten oder Überprüfen des Status eines Dienstes verwenden. Bei komplexeren Aufgaben muss der tatsächlich verwendete Befehl entweder initctloder systemctloder das /etc/init.dSkript direkt verwendet werden.

Da das serviceSkript ein Wrapper ist, kann es in einigen Fällen auch mehr als der direkte äquivalente Befehl. Zum Beispiel:

  • /etc/init.dSkripte werden immer in einer sauberen Umgebung ausgeführt. (Beachten Sie den langen env Befehlsaufruf in der run_via_sysvinitobigen Funktion.)
  • Es ordnet restartauf Upstart-Systemen eine Kombination aus stop/ zu start, da eine einfache initctl restartFehlermeldung ausgegeben wird, wenn der Dienst nicht bereits ausgeführt wird.
  • Es stoppt Sockets, wenn systemd-Dienste gestoppt werden, denen Sockets zugeordnet sind:

    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.

Upstart-Dienste wurden direkt in der Dienstkonfigurationsdatei aktiviert (oder über Überschreibungen deaktiviert), und System V-Skripts wurden mit dem update-rc.dBefehl (der Symlinks in den /etc/rc*Verzeichnissen verwaltete) serviceaktiviert oder deaktiviert , sodass der Befehl nie zum Aktivieren oder Deaktivieren von Diensten beim Start verwendet wurde .


34
  • systemd ist abwärtskompatibel mit SysV.
  • Lädt Dienste beim Start parallel
  • Es ermöglicht die On-Demand-Aktivierung eines Dienstes
  • Es basiert auf Abhängigkeiten
  • und vieles mehr, denke ich ...

Es gibt viel mehr als das, was Sie erwähnt haben systemctl.

systemd arbeitet mit Einheiten, es gibt verschiedene Arten von Einheiten: Ziele, Dienste, Sockets usw. Ziele sind dasselbe Konzept wie Runlevel, sie sind eine Menge von Einheiten zusammen.

Mit können Sie systemctldas Standardsystemziel festlegen oder abrufen.

systemctl get-default

Sie können in andere Ziele gehen:

systemctl isolate multiuser.target

Andere Ziele sind: Mehrbenutzer, Grafik, Empfang, Notfall, Neustart, Ausschalten.

Wie Sie sagten, können Sie systemctlDienste verwalten. Einige andere Befehle im Zusammenhang mit der Dienstverwaltung, die mir bekannt sind, sind:

# 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

Sie können es verwenden, um einen Servicestatus zu ermitteln:

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

Sie können einen Dienst maskieren oder demaskieren:

systemctl mask name.service
systemctl unmask name.service

Wenn Sie einen Dienst maskieren, mit dem er verknüpft ist /dev/null, können andere Dienste ihn manuell oder automatisch nicht aktivieren. (Sie sollten es zuerst demaskieren).

Eine andere Verwendung von systemctl ist das Auflisten von Einheiten:

systemctl list-units

Welche Liste aller Arten von Einheiten, geladen und aktiv.

Serviceeinheiten auflisten:

systemctl list-units --type=service

Oder um alle verfügbaren Einheiten aufzulisten, die nicht nur geladen und aktiviert sind:

systemctl list-unit-files

Sie können Aliase erstellen oder sogar entfernte Maschinen steuern

systemctl --host ravexina@192.168.56.4 list-units

Auf der anderen Seite serviceerledigt es, was es zu tun hat, verwaltet Dienste und hat nichts mit dem Geschäft anderer Leute zu tun;)


1
Das war eine perfekte Antwort. Gibt es etwas, was serviceman tun kann, aber nicht systemctl?
luv.preet

Nichts, was mir bewusst ist, ich denke ein Blick auf die Service-Manpage wäre hilfreich.
Ravexina

1
Es gibt einige offensichtliche Unterschiede. Syntax ist eine. Ein weiterer Grund ist, dass sich systemv-Skripte meines Wissens nie mit Sockets befassten. Die Tatsache, dass systemd versucht, mit netzwerkartigen Dingen umzugehen, ist eine andere und es ist ein häufiger Kritikpunkt. Insgesamt versucht systemd, mehr zu tun, als nur Dienste zu starten
Sergiy Kolodyazhnyy,

Ich möchte hier eine Beschwerde darüber einreichen, dass systemd Logmeldungen vor fehlgeschlagenen service startVersuchen versteckt . Pre-systemd, service startwürde mich sofort sehen lassen, warum mein Dienst nicht starten würde. Nach dem System muss ich mir vier oder fünf verschiedene Protokolle ansehen, bevor ich sie finden kann. Trotzdem ist mein Kommentar zweifellos vom Thema abgefallen und wird wahrscheinlich gelöscht.
Ross Presser

11
AFAICS Diese Antwort scheint nichts über den serviceBefehl zu sagen , war das nicht Teil der Frage?
Ilkkachu
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.