[gelöst] aktuelles Logfile fehlt

[KNUT345]

Hallo Zusammen,
ich habe FHEM auf einem RasPi3B seit längerem am Laufen
und verwende ein tägliches Logfile, heißt

Code Auswählen Erweitern

attr global logfile ./log/fhem-%Y-%m-%d.log
Seit zwei Tagen wird jedoch keine neues File mehr erzeugt.
Nach komplettem Neustart (reboot RasPi) werden zumindest wieder die Logs der Devices gemacht,
aber weiterhin kein Logfile.
Hat jemand eine Idee?
Ich habe den Speicher in Verdacht,
aber free -m sagt das noch Speicher verfügbar ist.

Grüße

[JoWiemann]

Hallo,

wenn Du nur den RAM Speicher siehst hilft das nicht weiter. Was sagt denn die Abfrage des Datei Speichers? Im selben Paket in dem free bereit gestellt wird sollte sich auch htop befinden. Das zeigt Dir mehr an.

Auf Grund Deiner Beschreibung gehe ich von: Datei Speicher ist voll, aus. Bei einem Neustart werden die Swap Dateien geleert. Das führt zunächst zu freiem Datei Speicher, der dann durch die Swap Dateien wieder aufgebraucht wird.

Grüße Jörg

[betateilchen]

Das globale Attribut "logfile" repräsentiert ja nicht das Logfile selbst.

Ist denn das device "Logfile" selbst noch in Deinem FHEM vorhanden?
Was steht im device "global" in den Internals unter "currentlogfile"

Hast Du mal versucht, FHEM manuell von der Konsole zu starten, um zu sehen, ob dabei Fehler auftreten?

[KNUT345]

Das globale Attribut "logfile" repräsentiert ja nicht das Logfile selbst.

Ist denn das device "Logfile" selbst noch in Deinem FHEM vorhanden?
Was steht im device "global" in den Internals unter "currentlogfile"

Hast Du mal versucht, FHEM manuell von der Konsole zu starten, um zu sehen, ob dabei Fehler auftreten?

das Logfile ist da

Code Auswählen Erweitern

currentlogfile ./log/fhem-2026-02-04.logaber in der Anzeige sehe ich nur Einträge von Vorgestern (02.02.2026...)
Bin aktuell offline, aber Heute Morgen war das File fhem-2026-02-04.log nicht da

Danke und Grüße
Knut

[betateilchen]

das Logfile ist da

Das ist erstmal nur eine Behauptung, mehr nicht.

Schau bitte auf dem Dateisystem nach, ob es die Datei wirklich gibt und - wenn ja - was da drinsteht.
Die Angabe in dem Internal ist lediglich der Name der von FHEM ermittelten Logdatei, die verwendet werden sollte. Man kann daraus nicht ableiten, ob diese benannte Datei tatsächlich existiert.

[passibe]

Wie schon gesagt, free ist der falsche Befehl bzgl. (Festplatten-)Speicherplatz. Richtig ist df -h.

Kann aber auch einfach sein, dass deine SD-Karte hinüber ist.

[KNUT345]

File war nicht da.
Hat definitiv mit Speicher zu tun.
/dev/root war 84%
nach Löschen alter files nun so:

Code Auswählen Erweitern

fhem@RasPi3:~ $ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        15G    7,4G  6,4G  54% /
devtmpfs        431M      0  431M    0% /dev
tmpfs          463M      0  463M    0% /dev/shm
tmpfs          463M    13M  451M    3% /run
tmpfs          5,0M    4,0K  5,0M    1% /run/lock
tmpfs          463M      0  463M    0% /sys/fs/cgroup
/dev/mmcblk0p1  253M    54M  199M  22% /boot
/dev/sda1        15G    9,4G  5,6G  63% /media/usb
tmpfs            93M      0  93M    0% /run/user/1001
fhem@RasPi3:~ $
wollte dann mit

Code Auswählen Erweitern

shutdown restartneu starten, dann hat sich FHEM aufgehängt
und konnte RasPi nur noch per Netz ein/aus starten
danach waren die alten Dateien wieder im Log-Ordner vorhanden
also wieder gelöscht, jetzt mal abwarten wie es weiterläuft

Grüße
Knut

[JoWiemann]

Hallo,

ich würde an Deiner Stelle auch mal prüfen wie umfangreich die Linux System Logs sind. Vor einigen Jahren hatte ich ein ähnliches Problem. Da war Log Rotate nicht aktiviert und die System Logs haben alles blockiert.

Grüße Jörg

[RalfRog]

...danach waren die alten Dateien wieder im Log-Ordner vorhanden...

Klingt auch merkwürdig. Oben war ja schon von einer defekten SD-Karte die Rede.

Ich finde es immer sinnvoll mal kurz zu schauen ob das Verzeichnis /lost&found leer ist. Wenn nicht gab es Fehler im Dateisystem die auf Fehler der Karte hindeuten können. Insbesondere wenn es viele Dateien sind.

Gruß Ralf

[KNUT345]

Ja, auf die SD-Karte habe ich auch schon getippt,
die ist schon recht alt.

/lost&found ist leer

Was ich mir nicht erklären kann.
Obwohl ich nun die alten Files schon mehrfach gelöscht habe,
die Devices auch wieder "normal" geloggt werden,
sind die alten Dateien am anderen Tag wieder da
und die aktuellen Logs sind weg.
Wie wenn ein Prozess alles wieder auf Start stellt.
Das einzige um Mitternacht passiert sind:

• save
• ein linux file copy von SD auf USB

Danke und Grüße
Knut

[MadMax-FHEM]

ein linux file copy von SD auf USB

Was kopierst du hier?
Und: sicher, dass die "USB-Platte/Stick" auch gemountet ist? Weil wenn nicht, dann wird "lokal" kopiert (also "in" den Mountpoint, statt auf das "Mount-Ziel" <- logisch ist ja nicht da)

Gruß, Joachim

[KNUT345]

Und: sicher, dass die "USB-Platte/Stick" auch gemountet ist? Weil wenn nicht, dann wird "lokal" kopiert (also "in" den Mountpoint, statt auf das "Mount-Ziel" <- logisch ist ja nicht da)

Gruß, Joachim

ja, ist da

Code Auswählen Erweitern

/dev/sda1        15G    9,4G  5,6G   63% /media/usb


[KNUT345]

Noch ein Hinweis zu dem "normalen" Loggen, das nicht so normal ist, denn
die Backup-Files von Gestern zeigen obwohl Datum von Heute zum Zeitpunkt der Datensicherung entweder:

• keine neuen Einträge, nur Einträge bis zum Beginn der Störung
• oder kryptische Einträge

Grüße, Knut

[Otto123]

Hi,

Ich würde nach meiner Erfahrung bestätigen: wenn die SD nicht voll war ( was auch meist nur durch Beenden des Logging auffällt) ist sie am Sterben.
Ich hatte seit Wochen das Gefühl, dass ein FHEM, auf einem Raspberry den ich betreue, sich komisch verhält: Die Bedienung "ruckelte". Bei der Suche ist mir ein Tool vom Raspberry OS aufgefallen: agnostics.

Code Auswählen Erweitern

sudo apt install agnosticsDann auf der Kommandozeile:

Code Auswählen Erweitern

sh /usr/share/agnostics/sdtest.shDas lieferte bei mir ein solides Fail obwohl das System an sich scheinbar fehlerfrei lief. Gestern die SD getauscht (nur mit dd kopiert) und nun läuft alles wieder fluffig. Dabei lief die Erzeugung des Images von der SD auch eher unauffällig.
Wäre ein einfacher Test in solchen unklaren Fällen und scheint eventuell noch rechtzeitig vor dem totalem Ausfall zu warnen.

Edit: was mir noch auffiel: das setup installiert offenbar eine komplette GUI, was man eigentlich auf dem Server nicht will. Ich rate deshalb noch zur sparsamen Variante:

Code Auswählen Erweitern

sudo apt install fioUnd dann von github nur die beiden Dateien sd_bench.fio und sdtest.sh holen und nach /usr/share/agnostics kopieren.

Gruß Otto

[passibe]

Vielleicht nur der Hinweis, dass ich mich bei sterbender SD-Karte nicht unbedingt auf dd verlassen würde, sondern persönlich ein besseres Gefühl dabei hätte, wenn ich einfach das ganze System neu aufsetze und FHEM aus einem Backup restore.

Aber ausprobieren schadet natürlich auf keinen Fall.

[KNUT345]

(nur mit dd kopiert)

Sehe ich das richtig, dass du schlicht ein Image der alten SD auf eine neue SD gezogen hast?

Grüße, Knut

[KNUT345]

Ja neu aufsetzen wäre bestimmt besser,
zumal das System nun schon recht alt ist,
aber wenn halt das System gar nicht läuft dauert mir das zu lange.
Mal sehen ob einfaches kopieren funktioniert.
Ansonsten, dann eben neu aufsetzen.

Grüße, Knut

[KNUT345]

beim Wieder-Neustart sagt es nun

Code Auswählen Erweitern

pi@RasPi3:/home/fhem $ sudo systemctl status fhem
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: ena
   Active: active (running) since Mon 2026-02-02 08:18:45 CET; 3 days ago
  Process: 644 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/S
 Main PID: 652 (perl)
    Tasks: 10 (limit: 2065)
   CGroup: /system.slice/fhem.service
           ├─ 652 /usr/bin/perl fhem.pl fhem.cfg
           ├─1182 /usr/bin/perl fhem.pl fhem.cfg
           ├─1184 /usr/bin/perl fhem.pl fhem.cfg
           ├─1185 /usr/bin/perl fhem.pl fhem.cfg
           ├─1186 /usr/bin/perl fhem.pl fhem.cfg
           ├─1188 /usr/bin/perl fhem.pl fhem.cfg
           ├─1189 /usr/bin/perl fhem.pl fhem.cfg
           ├─1190 /usr/bin/perl fhem.pl fhem.cfg
           ├─1199 /usr/bin/perl fhem.pl fhem.cfg
           └─1200 /usr/bin/perl fhem.pl fhem.cfg
Heißt es zeigt mir wieder den 02.02. an, wie wenn Datum nicht aktualisiert wird
Ein paar Sekunden später gibt es dann das fhem-2026-02-05.log
aber mit komischen Einträgen

Code Auswählen Erweitern

OnTimeH: Hour: 0.000 Day: 0.000 Month: 106.407 Year: 302.002
2023-04-25_04:57:29 SolarNeu statMyOnTimeHHour: 0.000
2023-04-25_04:57:29 SolarNeu statMyOnTimeHDay: 0.000
2023-04-25_04:57:29 SolarNeu statMyOnTimeHMonth: 106.407
2023-04-25_04:57:29 SolarNeu statMyOnTimeHYear: 302.002
2023-04-25_04:57:29 SolarNeu statIstYear: 468.5
2023-04-25_04:58:59 SolarNeu Durchfluss: 0
2023-04-25_04:58:59 SolarNeu myLeistungN: 0.0
2023-04-25_04:58:59 SolarNeu myLeistung: 0
2023-04-25_04:58:59 SolarNeu myErtragN: 41024116686.09
2023-04-25_04:58:59 SolarNeu myErtrag: 11402.5
2023-04-25_04:58:59 SolarNeu mySolvis: 11484.7
2023-04-25_04:58:59 SolarNeu myEffizienz: 0.000
2023-04-25_04:58:59 SolarNeu statMyErtragTrend: 1497.9
2023-04-25_04:58:59 SolarNeu myState: off
2023-04-25_04:58:59 SolarNeu trend: 1497.9
2023-04-25_04:58:59 SolarNeu off

und die alten Files sind natürlich wieder da

Grüße, Knut

[passibe]

Das Systemdatum stimmt aber? Was gibt (über SSH) date?

Und was sagt das Syslog nach dem Neustart, siehst du da irgendwo das Datum springen? Es könnte natürlich sein, dass – wieso auch immer – der Pi mit 02.02. startet und dann erst nach einiger Zeit, wenn FHEM schon läuft, auf den 05.02. springt und dann systemd den Startzeitpunkt von FHEM aber (falsch, aber aus seiner Sicht aufgrund des Zeitsprungs richtig) auf "3 days ago" stellt.

[Otto123]

Sehe ich das richtig, dass du schlicht ein Image der alten SD auf eine neue SD gezogen hast?

genau aber offline!

Beim Raspberry wird beim ordentlichen Shutdown eine Datei mit der aktuellen (System) Zeit geschrieben. Beim Start geht es mit dieser Zeit los, wenn dann später Netzwerk, Internet und ntp läuft, wird die Zeit wieder aktuell gesetzt.

Kann (warum auch immer) beim shutdown (oder auch sonst) nicht geschrieben werden, steht die Zeit beim Start auf dem letzten Stand der Datei /etc/fake-hwclock.data

Ohne Internet bzw. ohne ntp wird die Zeit nicht aktuell gesetzt.

[RalfRog]

und die alten Files sind natürlich wieder da

Das hört sich schon recht merkwürdig an ->  Wo kommen die wieder her wenn sie wirklich gelöscht wurden 

Vermutlich wäre ein Neuaufsetzen zielführend wenn das System "ordentlich" laufen muss.
Wenn es egal ist kann man natürlich noch suchen.

[KNUT345]

Problem gelöst.
Es war die SD-Karte.
Ich habe (noch einmal testweise) die Karte kopiert
und mit der neuen Karte läuft alles wieder wie gewohnt.

Nichts desto trotz.
Neu Aufsetzen werde ich zeitnah einplanen.

Danke für eure Tipps und Grüße
Knut