Server shutdown alle paar Minuten [gelöst]

[Calivati]

Hi, also im Syslog finde ich zu den shutdownzeiten (z.B 14:04:34) folgendes:
Mar  3 14:04:27 raspberrypi evcc[613]: [lp-2  ] DEBUG 2024/03/03 14:04:27 charger status: B
Mar  3 14:04:30 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:30 ----
Mar  3 14:04:30 raspberrypi evcc[613]: [lp-1  ] DEBUG 2024/03/03 14:04:30 charge power: 3680W
Mar  3 14:04:30 raspberrypi evcc[613]: [lp-2  ] DEBUG 2024/03/03 14:04:30 charge power: 0W
Mar  3 14:04:30 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:30 pv power: 8244W
Mar  3 14:04:30 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:30 battery soc: 66%
Mar  3 14:04:30 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:30 battery power: 0W
Mar  3 14:04:30 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:30 grid power: -3887W
Mar  3 14:04:30 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:30 site power: -3887W
Mar  3 14:04:30 raspberrypi evcc[613]: [lp-1  ] DEBUG 2024/03/03 14:04:30 charger status: C
Mar  3 14:04:30 raspberrypi evcc[613]: [lp-1  ] DEBUG 2024/03/03 14:04:30 vehicle soc: 49%
Mar  3 14:04:30 raspberrypi evcc[613]: [lp-1  ] DEBUG 2024/03/03 14:04:30 vehicle range: 143km
Mar  3 14:04:30 raspberrypi evcc[613]: [lp-1  ] DEBUG 2024/03/03 14:04:30 pv charge current: 32.9A = 16A + 16.9A (-3887W @ 1p)
Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 ----
Mar  3 14:04:33 raspberrypi evcc[613]: [lp-1  ] DEBUG 2024/03/03 14:04:33 charge power: 3680W
Mar  3 14:04:33 raspberrypi evcc[613]: [lp-2  ] DEBUG 2024/03/03 14:04:33 charge power: 0W
Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 pv power: 8067W
Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 battery soc: 65%
Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 battery power: 0W
Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 grid power: -4051W
Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 site power: -4051W
Mar  3 14:04:33 raspberrypi evcc[613]: [lp-2  ] DEBUG 2024/03/03 14:04:33 charger status: B
Mar  3 14:04:36 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:36 ----
Denke, daraus kann man nichts ableiten.
Die Fhem config hänge ich an.

[Wernieman]

Code Auswählen Erweitern

Mar  3 14:04:33 raspberrypi evcc[613]: [site  ] DEBUG 2024/03/03 14:04:33 battery power: 0W
Sag mal .. hast Du eine USV am PI hängen?

[Calivati]

Nein, ich vermute das sind Meldungen meiner Haus-PV, ich habe das Senec-Modul aktiv

[Wernieman]

ich habe das Senec-Modul aktiv

Finde ich momentan nicht in der Doku der Offiziellen Module ... oder habe ich etwas übersehen? Und warum postet es andauernd ins System-Log Debugmeldungen ...

[Calivati]

[36_Senec.pm] FHEM module zur Integration eines SENEC Speicher und MeinSenec, Developer carlos
Das Modul bindet den Senec Wechselrichter und Speicher in FHEM ein. Dass das ständig Meldungen in den syslog schreibt, hab ich auch eben erst bemerkt.

[Wernieman]

Das ist dock separat installiert?

In der offiziellen Doku https://fhem.de/commandref.html#intro finde ich es nicht ...

Wir dabei noch ein externes Programm installiert?

Hinweis:
Es geht mir hier nicht darum, etwas doer ein Modul zu kritisieren, sondern möchte nur das System verstehen um Dir zu helfen, den fehler zu finden ..

P.S.
Findest Du in der kern.log oder syslog etwas bezüglich oom?
z.B. durch:

Code Auswählen Erweitern

grep -i oom /var/log/kern.log
oder:

Code Auswählen Erweitern

journalctl --list-boots | awk '{ print $1 }' | xargs -I{} journalctl --utc --no-pager -b {} -kqg 'killed process' -o verbose --output-fields=MESSAGE

[Calivati]

Zu 1: ja, korrket, das ist separat installiert. Es wird dabei nichts weiter installiert.
Im kern.log finde ich nichts bzgl. oom
Die journalctl Abfrage ergibt: Data from the specified boot (-2) is not available: No such boot ID in journal

[Calivati]

Ich hab eben nochmal im Syslog geblättert und finde vormittags alle 2-3 Minuten:

Mar  3 11:18:19 raspberrypi systemd[8597]: gpg-agent-browser.socket: Succeeded.
Mar  3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Mar  3 11:18:19 raspberrypi systemd[8597]: gpg-agent-extra.socket: Succeeded.
Mar  3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Mar  3 11:18:19 raspberrypi systemd[8597]: gpg-agent-ssh.socket: Succeeded.
Mar  3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Mar  3 11:18:19 raspberrypi systemd[8597]: gpg-agent.socket: Succeeded.
Mar  3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent and passphrase cache.
Mar  3 11:18:19 raspberrypi systemd[8597]: Removed slice User Application Slice.
Mar  3 11:18:19 raspberrypi systemd[8597]: Reached target Shutdown.

und ab 19:39 alle 2 Minuten:

Mar  4 19:39:39 raspberrypi systemd[1]: fhem.service: start operation timed out. Terminating.
Mar  4 19:39:39 raspberrypi perl[11361]: 2024.03.04 19:39:39.678 0: Server shutdown
Mar  4 19:39:39 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Mar  4 19:39:39 raspberrypi systemd[1]: Failed to start FHEM Home Automation.
Mar  4 19:39:39 raspberrypi systemd[1]: fhem.service: Consumed 3.932s CPU time.
Mar  4 19:39:39 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 172.
Mar  4 19:39:39 raspberrypi systemd[1]: Stopped FHEM Home Automation.
Mar  4 19:39:39 raspberrypi systemd[1]: fhem.service: Consumed 3.932s CPU time.
Mar  4 19:39:39 raspberrypi systemd[1]: Starting FHEM Home Automation...

[JoWiemann]

Hallo,

wir kommen der Sache näher.

Fhem wird als Service gestartet. Parametriert wird der Service über die Datei /etc/systemd/system/fhem.service.

Im Original nach der Installion wird Fhem als Type=forked, wenn ich mich richtig erinnere, gestartet. Das hat bei mir mit einer sehr umfangreichen fhem.cfg auch zu diesem Verhalten geführt. Ersetze doch bitte die mal die Zeile Type=forked durch Type=simple. Nach dem Editieren den Service mit sudo systemctl daemon-reload updaten.

Grüße Jörg

[Service]
Type=simple

[Calivati]

Hallo Jörg,
super, vorab schon mal ganz herzlichen Dank! Ich habe den Parameter Type=forking in Type=simple geändert und seit ca. 30 Minuten wurde kein shutdown mehr gemacht. Ich beobachte das jetzt noch eine Weile und melde mich dann final noch einmal. 
Nochmals danke und viele Grüße
Peter

[carlos]

Ich habe gerade in der systemd.service — Service unit configuration nachgelesen, da steht folgendes:

If set to forking, the manager will consider the unit started immediately after the binary that forked off by the manager exits. The use of this type is discouraged, use notify, notify-reload, or dbus instead.

[Wernieman]

after the binary that forked off by the manager exits

Was leider nicht 100% stimmt ... manchmal wird auch gestoppt/gestartet, wenn SystemD "denkt", das der Prozess nicht mehr läuft. Also eine WatchDog Funktionalität.

Laut der Beschreibung würde er es nur tuen, wenn der Prozess sich beendet ...

[Calivati]

Hallo zusammen,
seit Stunden keine Abbrüche mehr  , ihr seid die Besten!
Vielen Dank an alle, die unterstützt haben!
Viele Grüße
Peter

[Wernieman]

Könntest Du bitte noch den Therad als [gelöst] markieren?

Dazu einfach Deinen ersten Post aufrufen, bearbeiten und dort im Subjekt ein [gelöst] eintragen ...


P.S.
Nur eine Info:
Wenn jetzt Dein FHEM mal abschmieren sollte, wird es nicht mehr automatisch gestartet ....

[JoWiemann]

P.S.
Nur eine Info:
Wenn jetzt Dein FHEM mal abschmieren sollte, wird es nicht mehr automatisch gestartet ....

Hallo,

dass kann ich so nicht bestätigen. In der fhem.service steht ja:

TimeoutStartSec=300
RestartSec=10
Restart=always

Grüße Jörg