FHEM nach reboot auf uraltem Stand?

[micomat]

Hallo zusammen,

ich hatte jetzt schon zwei mal das Problem, dass mein FHEM nach einem neustart des PI auf einem uralten Stand startet.
Das Statefile hat noch die aktuellsten States, aber alle Defines usw scheinen weg.
Ich konnte das zwar (bis auf einmal) immer mit einem Backup abfangen, aber das ist trotzdem sehr aergerlich und laestig.
Und ich hab nicht den blassesten Schimmer wieso das so ist.

Ich bilde mir auch ein, dass einige Backup_Files nach dem letzten Reboot ploetzlich nicht mehr im Backup Ordner waren...

Kann das damit zusammen haengen, dass evtl beim Start die Systemzeit erst mal noch nicht stimmt?

Gruß
Markus

[Hollo]

Das ist eigentlich unwahrscheinlich bzw. wäre sehr ungewöhnlich.
Sofern Du Deine Daten nicht in /tmp lagerst oder eine Datei bei einem Absturz gerade geschrieben wird, sollte nach einem ordnungsgemäßen reboot alles wie gewohnt sein.
Die config-Datei(en) mit den define interessiert die Zeit ja erstmal nicht sonderlich.
Es sei denn, Du hast Deine config auf mehrere Dateien aufgeteilt und beim Start passt die Reihenfolge nicht zueinander (z.B. structure definiert BEVOR das Device überhaupt definiert ist oder sowas).
Aber dann solltest Du auch entsprechende Fehlermeldungen im LOG haben, was sagt das denn so?

[Wernieman]

Zur Analyse, guck doch mal, ob die Config aktuallisiert wird

Code Auswählen Erweitern

ls -lha /opt/fhem/fhem.cfg
Anschließend ein "save" in Fhem, und obiges nochmal eingeben.

Es sollte das Datum/Zeitstempel der Datei sich Ändern

[micomat]

nein, nach /tmp wird nix geschrieben.

das Log faengt nach einem Reboot dann direkt mit den ersten devices an, die nicht definiert sind...
Der Zeitstempel aendert sich wie erwartet.

Wenns nur einmal gewesen waer, dann haett ichs vermutlich ignoriert, aber nach dem zweiten Mal nun muss ja irgendwat sein...

[dev0]

<Wilde Spekulationen>
- wenn $currcfgfile (fhem.pl), durch was auch immer, verbogen wird, dann könnte ich mir solche seltsamen Effekte vorstellen.
- defektes filesystem/medium
</Wilde Spekulationen>

[micomat]

Das Filesystem hatte ich auch schon im Verdacht, aber dann wuerden auch andere Logs fehlen...
Wie koennte denn $currcfgfile verbogen sein? Wie kann ich das pruefen?

Solange fhem laeuft und, selbst nach einem shutdown restart, funktioniert alles prima. Das Problem trat bisher nur nach einem System-Reboot auf.

[dev0]

Stand nach dem reboot etwas in den system logs bzgl. filesystem?
Edit: $currcfgfile scheidet aus, würde sonst auch nach shut restart auftreten.

[Wernieman]

Code Auswählen Erweitern

Solange fhem laeuft und, selbst nach einem shutdown restart, funktioniert alles prima. Das Problem trat bisher nur nach einem System-Reboot auf.

Wie häufig startest Du den RasPi durch?

Kannst Du uns bitte mal die Ausgabe von "mount" geben?

[Beta-User]

<Wilde Spekulation>
Nach dem starten automatisch wird "irgendwie" ein anderes global-attr configfile gesetzt als im Startup-script angegeben?
</Ende Wilde Spekulation>

[micomat]

Hier mal meine Ausgabe von Mount:

Code Auswählen Erweitern

/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=469756k,nr_inodes=117439,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/sda1 on /media/usb0 type ext4 (rw,nodev,noexec,noatime,nodiratime,sync,data=ordered)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=94812k,mode=700,uid=1000,gid=1000)


Mir ist eben noch eingefallen, dass sogar das Featurelevel beim letzten mal 5.6 statt 5.7 war...
Hier ist ein Thread mit aehnlichem Problem, der leider unbeantwortet blieb.
https://forum.fhem.de/index.php?topic=47284.0

Gruß
Markus

[Wernieman]

Wo (Ordner) liegt Dein FHEM?

[micomat]

ganz "normal" in /opt/fhem
nur die Logfiles schreibe ich auf einen am Pi angeschlossenen USB Stick um die Schreibzyklen der SD im Pi zu reduzieren.

[Wernieman]

komisch ... und im /etc/init.d/fhem steht auch kein anderer Ordner für die Konfiguration?

[micomat]

guter Hinweis, werde ich heute abend mal pruefen

[micomat]

also im genannten file ist als dir /opt/fhem angegeben und als start command nur

Code Auswählen Erweitern

perl fhem.pl fhem.cfg