Ich habe einen Dienst (von mir selbst geschrieben), der auf einem Debian-Server (Jessie) läuft, und die eigenen Protokolle des Dienstes zeigen zufällig an, dass er zu einem bestimmten Zeitpunkt neu gestartet wurde. Es gibt keinen Hinweis auf einen Segfault oder einen anderen Absturz, also versuche ich jetzt herauszufinden, ob die Anwendung irgendwieschweigendfehlgeschlagen ist und von systemd neu gestartet wurde, oder ob ein Benutzer den Dienst absichtlich über neu gestartet hat systemctl.
Der Shell-Verlauf zeigt keine derartige Aktivität, aber das ist nicht schlüssig, da export HISTCONTROL=ignorebotheine SSH-Sitzung möglicherweise gerade abgelaufen ist, wodurch der Bash-Verlauf einer vorherigen Anmeldung nicht auf die Festplatte geschrieben werden konnte. Der Server wurde zu diesem Zeitpunkt nicht neu gestartet.
Ich würde aber erwarten, dass systemd selbst ein Protokoll führt, das angibt, wann ein Dienstabsichtlichneu gestartet. Zu meiner Überraschung konnte ich keine Dokumentation (z. B. für journalctl) dazu finden, wie man solche Protokolle erhält.
Einige andere Beiträge (zBWo befindet sich bzw. warum gibt es kein Protokoll für normale systemd-Dienste von Benutzern?) scheinen darauf hinzudeuten, dass es Protokollmeldungen wie diese geben sollte:
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.
Aber ich sehe solche Protokollmeldungen nicht auf meinem System.
Gibt es eine Möglichkeit herauszufinden, wann systemd-Dienste gestartet, gestoppt oder neu gestartet wurden?
Bearbeiten: Das typische Problem, auf das Leute stoßen könnten, scheint zu sein, dass sie journalctlals nicht privilegierter Benutzer arbeiten. Das ist bei mir nicht der Fall, ich habe rootdie ganze Zeit als privilegierter Benutzer gearbeitet. Als Antwort auf einen Kommentar grep systemd /var/log/syslogbekomme ich beim Ausführen 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.
Antwort1
Wenn Sie dies in einem Skript ausführen müssen, sollten Sie den systemctl show
Befehl verwenden. Er ist für Skripte nützlicher als der Versuch, irgendetwas aus 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 das Flag einfach weg, und es werden alle gelöscht.
$ systemctl show <service_name>
Die Dokumentation zu diesen Eigenschaften finden SieHier.
Antwort2
Mit der Standardkonfiguration unter Debian hat ein nicht privilegierter Benutzer weder Zugriff auf die systemd-journald- noch auf die Syslog-Protokolle. Wenn Sie als normaler Benutzer angemeldet sind, erhalten Sie diese Antwort von journalctl:
$ journalctl
No journal files were found.
was ein wenig verwirrend ist.
Wenn Sie als Root angemeldet sind, journalctl --unit=yourservicesollten Sie die gesuchten Informationen erhalten. Nach einem Login 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 beende kill -9, journalctl --unit=bind9ergibt sich:
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 gibt an, dass der Prozess beendet wurde, weil er beendet wurde.
systemd-journald leitet auch alle Protokollnachrichten an syslog weiter, daher sollten Sie diese Nachrichten auch in finden /var/log/syslog.
Systemd und systemd-journald haben eine standardmäßig kompilierte Konfiguration, die in /etc/systemd/system.confund geändert werden kann /etc/systemd/journald.conf.
Es kann hilfreich sein zu wissen, dass systemd-journald die Protokolle standardmäßig unter speichert /run, was bedeutet tmpfs, dass sie nach einem Neustart verschwinden. Dies bedeutet, dass Sie sich die Syslog-Dateien ansehen müssen, um Protokollnachrichten zu erhalten, die älter als der letzte Start sind. In diesem Fall gibt Ihnen journalctl keine Protokolle aus, die älter als der letzte Start sind. Dies kann /etc/systemd/journald.confdurch Festlegen von geändert werden Storage=persistent.
Die Manualpages, die dies dokumentieren, sind:
man 8 systemd-journald
man 5 journald.conf
man 5 systemd-system.conf
man 5 systemd-user.conf
Beachten Sie auch, dass ein Dienst in seiner Datei konfiguriert werden muss, damit er automatisch von systemd neu gestartet werden kann .service. 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.
Antwort3
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