Wie sehe ich, wann ein systemd-Dienst gestartet / gestoppt / neu gestartet wurde?

12

Ich habe einen Dienst (von mir selbst geschrieben), der auf einem Debian-Server (Jessie) ausgeführt wird, und die eigenen Protokolle des Dienstes weisen darauf hin, dass er zu einem bestimmten Zeitpunkt neu gestartet wurde. Es gibt keinen Hinweis auf einen Segfault oder einen anderen Absturz. Daher versuche ich jetzt herauszufinden, ob die Anwendung im Stillen fehlgeschlagen ist und von systemd erneut gestartet wurde oder ob ein Benutzer den Dienst absichtlich über neu gestartet hat systemctl.

Der Shell-Verlauf zeigt keine solche Aktivität an, aber das ist nicht schlüssig, da export HISTCONTROL=ignorebothund weil eine SSH-Sitzung möglicherweise gerade abgelaufen ist und verhindert wird, dass der Bash-Verlauf eines vorherigen Logins auf die Festplatte geschrieben wird. Der Server wurde zu diesem Zeitpunkt nicht neu gestartet.

Ich würde jedoch erwarten, dass systemd selbst ein Protokoll führt, das angibt, wann ein Dienst absichtlich neu gestartet wurde. Zu meiner Überraschung konnte ich keine Dokumentation (z. B. für journalctl) finden, wie man solche Protokolle erhält.

Einige andere Beiträge (z. B. Wo ist / warum gibt es kein Protokoll für normale Benutzer-Systemdienste? ) Scheinen darauf hinzuweisen, dass Protokollnachrichten wie diese vorhanden sein sollten:

Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Starting chatty.service...
Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Started chatty.service.

Auf meinem System werden solche Protokollmeldungen jedoch nicht angezeigt.

Gibt es eine Möglichkeit herauszufinden, wann systemd-Dienste gestartet, gestoppt oder neu gestartet wurden?

Bearbeiten : Es scheint, dass das typische Problem darin besteht, dass journalctlBenutzer als nicht privilegierte Benutzer ausgeführt werden. Dies ist bei mir nicht der Fall, ich habe rootdie ganze Zeit gearbeitet. Als Antwort auf einen Kommentar grep systemd /var/log/sysloggibt mir das Laufen nur Folgendes:

Jun  6 09:28:35 server systemd[22057]: Starting Paths.
Jun  6 09:28:35 server systemd[22057]: Reached target Paths.
Jun  6 09:28:35 server systemd[22057]: Starting Timers.
Jun  6 09:28:35 server systemd[22057]: Reached target Timers.
Jun  6 09:28:35 server systemd[22057]: Starting Sockets.
Jun  6 09:28:35 server systemd[22057]: Reached target Sockets.
Jun  6 09:28:35 server systemd[22057]: Starting Basic System.
Jun  6 09:28:35 server systemd[22057]: Reached target Basic System.
Jun  6 09:28:35 server systemd[22057]: Starting Default.
Jun  6 09:28:35 server systemd[22057]: Reached target Default.
Jun  6 09:28:35 server systemd[22057]: Startup finished in 59ms.
Jun  6 09:37:08 server systemd[1]: Reexecuting.
systemd  systemd-journald 
— Mindriot
quelle
"Solche Protokollnachrichten nicht sehen" - seltsam? Ich habe viel ingrep systemd /var/log/syslog
— hschou
Auf meinem System werden nur sehr allgemeine Nachrichten wie usw. angezeigt. Nichts Stopped target Defaultweist Starting Shutdownauf einzelne Dienste hin. Vielleicht ist es nur ein Konfigurationsproblem? Hinweis: Ich bin in diesem speziellen Fall auf Debian Jessie.
— Mindriot
Überprüfen Sie, ob Ihr oder /etc/systemd/journald.confnicht überschrieben wurde , und suchen Sie an allen anderen Stellen, an denen Sie Journald wie unter aufgeführt konfigurieren können . MaxLevelStoreMaxLevelSyslogman journald.conf
— Meuh
Danke für den Tipp. Leider sind alle unter befindlichen Konfigurationsdateien /etc/systemdim Wesentlichen leer (alle Optionen sind auskommentiert, einschließlich der von Ihnen genannten).
— Mindriot

Antworten:

11

Wenn Sie ein Skript erstellen müssen, sollten Sie die Verwendung des systemctl show Befehls prüfen. Es ist für Skripte nützlicher, als zu versuchen, irgendetwas davon zu analysieren status. Um beispielsweise herauszufinden, wann der Dienst zuletzt gestartet wurde, können Sie Folgendes verwenden:

$ systemctl show systemd-journald --property=ActiveEnterTimestamp
ActiveEnterTimestamp=Wed 2017-11-08 05:55:17 UTC

Wenn Sie alle verfügbaren Eigenschaften sehen möchten, lassen Sie einfach das Flag weg und es werden alle gelöscht.

$ systemctl show <service_name>

Die Dokumentation zu diesen Eigenschaften finden Sie hier .

— jdf
quelle
Interessant, ich war mir der Eigenschaften nicht bewusst. Leider sind sie genauso eingestellt, unabhängig davon, ob der Dienst fehlgeschlagen und erneut gestartet wurde oder der Dienst absichtlich von einem Benutzer neu gestartet wurde.
— Mindriot
1
Ein besserer Link für die Eigenschaften scheint übrigens die dbus-Dokumentation zu sein .
— Mindriot
Danke @mindriot, das ist ein besserer Link für Dokumente. Ich habe meine Antwort aktualisiert.
— JDF
1
@mindriot in Bezug auf Ihren ersten Punkt, haben Sie überprüft StatusErrnound Result? Ich würde mich fragen, ob sich diese ändern, wenn der Dienst fehlschlägt oder neu gestartet wird. Wenn Sie wirklich weiter gehen müssen, fügen Sie einen ExecStopPostSchritt hinzu, in dem Sie eine Datei berühren und beim Herunterfahren einen Zeitstempel aktualisieren. Dies hilft Ihnen, zwischen stillen und zielgerichteten Neustarts zu unterscheiden.
— JDF
Danke, das ist auch ein guter Punkt. Ich werde die Situation nicht leicht überprüfen / reproduzieren können; Mein ursprünglicher Beitrag ist bereits fast ein halbes Jahr alt und wir haben seitdem einige Änderungen am System vorgenommen. Ich werde prüfen, ob ich es irgendwo ausprobieren kann - wenn ich eine Chance bekomme.
— Mindriot
3

Mit der Standardkonfiguration unter Debian hat ein nicht privilegierter Benutzer weder Zugriff auf die Protokolle systemd-journald noch auf syslog. Wenn Sie als normaler Benutzer angemeldet sind, erhalten Sie diese Antwort von journalctl:

$ journalctl 
No journal files were found.

Das ist ein bisschen verwirrend.

Wenn Sie als root angemeldet sind, journalctl --unit=yourservicesollten Sie die gesuchten Informationen erhalten. Nach einem systemctl restart bind9auf meinem Server erhalte ich Folgendes journalctl --unit=bind9:

Jun 03 18:20:24 ns systemd[1]: Stopping BIND Domain Name Server...
Jun 03 18:20:24 ns named[27605]: received control channel command 'stop'
Jun 03 18:20:24 ns systemd[1]: Starting BIND Domain Name Server...
Jun 03 18:20:24 ns systemd[1]: Started BIND Domain Name Server.

Wenn ich bind9 explizit mit töte kill -9, journalctl --unit=bind9gibt es:

Jun 03 18:46:25 ns systemd[1]: bind9.service: main process exited, code=killed, status=9/KILL
Jun 03 18:46:25 ns rndc[28028]: rndc: connect failed: 127.0.0.1#953: connection refused
Jun 03 18:46:25 ns systemd[1]: bind9.service: control process exited, code=exited status=1
Jun 03 18:46:25 ns systemd[1]: Unit bind9.service entered failed state.
Jun 03 18:46:25 ns systemd[1]: bind9.service holdoff time over, scheduling restart.
Jun 03 18:46:25 ns systemd[1]: Stopping BIND Domain Name Server...
Jun 03 18:46:25 ns systemd[1]: Starting BIND Domain Name Server...
Jun 03 18:46:25 ns systemd[1]: Started BIND Domain Name Server.

Die erste Zeile zeigt an, dass der Prozess beendet wurde, weil er beendet wurde.

systemd-journald leitet auch alle Protokollnachrichten an syslog weiter, sodass Sie diese Nachrichten auch in finden sollten /var/log/syslog.

Systemd und systemd-journald haben eine Standardkonfiguration, die in /etc/systemd/system.confund geändert werden kann /etc/systemd/journald.conf.

Es kann nützlich sein zu wissen , dass standardmäßig, systemd-journald speichert die Protokolle unter /run, das ist tmpfs, und deshalb verschwindet nach einem Neustart. Dies bedeutet, dass Sie sich Syslog-Dateien ansehen müssen, um Protokollmeldungen zu erhalten, die älter als der letzte Start sind. In diesem Fall erhalten Sie mit journalctl keine Protokolle, die älter als der letzte Start sind. Dies kann /etc/systemd/journald.confdurch Einstellen geändert werden Storage=persistent.

Die Handbuchseiten, die dies dokumentieren, sind:

man 8 systemd-journald
man 5 journald.conf
man 5 systemd-system.conf
man 5 systemd-user.conf

Beachten Sie außerdem, dass ein Dienst, der von systemd automatisch neu gestartet werden soll, in seiner .serviceDatei konfiguriert werden muss . Von man 5 systemd.service:

   Restart=
       Configures whether the service shall be
       restarted when the service process exits, is
       killed, or a timeout is reached. The service
       process may be the main service process, but it
       may also be one of the processes specified with
       ExecStartPre=, ExecStartPost=, ExecStop=,
       ExecStopPost=, or ExecReload=. When the death
       of the process is a result of systemd operation
       (e.g. service stop or restart), the service
       will not be restarted. Timeouts include missing
       the watchdog "keep-alive ping" deadline and a
       service start, reload, and stop operation
       timeouts.

       Takes one of no, on-success, on-failure,
       on-abnormal, on-watchdog, on-abort, or always.
       If set to no (the default), the service will
       not be restarted.
— Tom Bjerck
quelle
Vielen Dank für den umfangreichen und gut geschriebenen Beitrag, der das Problem wahrscheinlich für die meisten Benutzer löst . Leider werden in meinem Fall keine Protokollzeilen systemdangezeigt, die bei der Ausgabe des Journals wie von Ihnen beschrieben zugeordnet sind, obwohl ich die ganze Zeit als Root gearbeitet habe. /var/log/syslogzeigt auch nichts. Dies ist übrigens systemd 215.
— Mindriot
3

Sie können sehen, wann Ihr Dienst das letzte Mal gestartet oder neu gestartet wurde. Verwenden Sie service chatty statusoder systemctl status chatty. Hier sind Beispiele für den Apache2- oder httpd-Dienst:

# service apache2 status
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
  Drop-In: /lib/systemd/system/apache2.service.d
       └─forking.conf
   Active: active (running) since ven. 2017-06-02 15:53:01 CEST; 21min ago
  Process: 14773 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS)
  Process: 22912 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
  Process: 14880 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/apache2.service

Die Zeile Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agozeigt, wie der Dienst ausgeführt wird, aber ich weiß nicht, ob Sie wie eine Liste genau das anzeigen können, wonach Sie suchen.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-10-11 00:35:58 EEST; 1 weeks 3 days ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 29728 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
 Main PID: 10722 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   Memory: 8.7M
— klaypez
quelle
1
serviceist ein alter Upstart-Befehl, der aus Kompatibilitätsgründen mit systemd zusammenarbeitet. Der native systemdBefehl lautet systemctl status apache2.
— Mark Stosberg
Vielen Dank. Leider wird nur angezeigt, wann der Dienst (neu) gestartet wurde, aber nicht warum ; und es zeigt auch nur die aktuelle Situation, dh den letzten Neustart.
— Mindriot
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.