Wie kann der Systemctl-Status einen falschen aktiven Wert anzeigen?

Wie kann der Systemctl-Status einen falschen aktiven Wert anzeigen?

Ich verwende das Betriebssystem CentOS 8. Ich habe einen Dienst, der Tomcat beim Booten startet. Und es wurde ein Fehler gemeldet, bei dem Tomcat nach einem Update, das einen Neustart auslöst, nicht gestartet wurde (das System wurde neu gestartet). Das Ergebnis von

systemctl status {service.name}

War

Loaded: loaded (/etc/systemd/system/{service.name}; enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-10-02 18:42:21 EEST; 2 weeks 3 days ago

Das Problem hier ist, dass „Aktiv: vor 2 Wochen, 3 Tagen, direkt nach dem Neustart“ angezeigt wird. Das Problem konnte leicht durch einen Neustart des Dienstes behoben werden.

Aber ich konnte es immer noch nicht reproduzieren und verstehen, wie das möglich sein konnte.

Ich habe versucht, den dauerhaften Speicher für das Systemd-Journalprotokoll zu aktivieren, indem ich manuell /var/log/journaleinen Ordner erstellt und journalctl -u {service.name} Protokolle vor und nach angezeigt habe. -- Reboot -- Aber das Ergebnis von

systemctl status {service.name}

Berechnet weiterhin die Zeit seit dem letzten Dienststart.

Weiß also jemand, was die Ursache dafür sein könnte, Active: active (running)dass es veraltet ist und einen falschen Status anzeigt? (da der Dienst weder die falsche Zeit noch den falschen aktiven Status anzeigen sollte). Danke

Außerdem ist die Startzeit des Dienstes am Ende von systemctl status {service.name}vor 2 Wochen, sodass das gesamte Protokoll veraltet aussieht.

Aktualisierter Service

[Unit]
Description=Start tomcat service
After=network-online.target snmpd.service
Wants=network-online.target
Conflicts=tomcat-debug.service

[Service]
ExecStart=/opt/infrascale/stark-scripts/tomcat-start.sh
ExecStop=/opt/infrascale/stark-scripts/tomcat-stop.sh
StandardOutput=journal
StandardError=journal
Restart=always
Type=forking

[Install]
WantedBy=multi-user.target

Im Moment sieht es so aus, als ob es sich entweder um einen menschlichen Fehler handelt und der Dienststatus vor dem Neustart übernommen wurde, oder es könnte ein Problem mit systemd nach dem Kernel-Update von 4.18 auf 5.14 geben.

verwandte Informationen