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

[Wernieman]

Mach mal etwas anderes:

1. Sichern Deiner Konfig (Backup ist immer gut)
2. per Konsole mit touch eine Datei anlegen

Code Auswählen Erweitern

touch /opt/fhem/test
3. Rechner rebooten
4. Nach reboot ansehen, ob Datei "da" ist

Code Auswählen Erweitern

ls -lha /opt/fhem/test

Irgendwas ist "komisch" ...

[micomat]

ich werde das mal testen wenn ich mehr Zeit hab
das restoren dauert immer so lange

[devil77]

Muss mich hier mal mit dran hängen, weil genau das gleiche Problem.
Raspi 3 vor 2 Wochen frisch aufgesetzt und in unregelmäßigen Abständen dieses Phänomen.
Es fehlen Definitionen, hinzugefügte Userrattr usw.. Gerade eben wieder, Tagelang läuft alles ohne Probleme und bei einem Neustart fehlt die Hälfte.
Keine Ahnung woran das liegen kann.

[micomat]

mach mir keine angst... ich hab grad alles wieder so beisammen wie es sein soll.
ich werd heut nochmal ein backup auf mein NAS machen.

der WAF ist aktuell ziemlich am boden, daher werde ich mich hueten irgendwas zu testen.

[Wernieman]

Also .. eigentlich giebt es "nur" 2 Kandidaten für das Problem:
1. FHEM sichert nicht weg:
- save machen
- Gucken ob fhem.cfg aktuallisiert wurde
- Gucken ob in der fhem.cfg auch die passenden Definitionen sind

2. Das "System" sichert nicht auf der SD
- vorgehen zum Testen habe ich oben schon beschrieben

Wobei ... meistens würde ich darauf tippen, das ein "save" vergessen wurde ...

[alpha1974]

Eine mögliche Fehlerquelle können auch "SD-Schreibzugriff-Reduzierungs-Optimierungen" sein.

Bei mir entpuppte sich einmal fs2ram als Übeltäter unter Debian Jessie: Als ein Reboot das fs2ram-Script, das die tmpfs-Daten komprimieren und auf die SD-Karte zurückschreiben soll (fs2ram stop), zu früh abwürgte, war FHEM auf dem Stand des letzten Reboots. Die genaue Ursache konnte ich im Nachhinein aber nicht mehr feststellen... vielleicht hing es damit zusammen, dass fs2ram keine systemd-Unit mitbringt und der Reboot das "fs2ram stop" bei großen Datenmengen zu früh beendet.

Dies nur als weiterer Denkanstoß für mögliche Fehlerquellen.

Gruß
alpha1974

[Happy Fhem User]

Ich hatte ebenfalls das Problem. Bei mir war die Ursache dass in /etc/init.d/fhem ein relativer Pfad für die Config zusammen mit einem Verzeichniswechsel angegeben war.
Z.B.

cd /etc
...
perl /opt/fhem/fhem.pl ./fhem.cfg

fhem lief gut solange ich nicht einen kompletten Neustart durchgeführt habe sondern nur über die fhem-Kommandozeile "shutdown restart". fhem hat - so vermute ich - ab dann die Änderungen an den Configs unter /opt/fhem/... abgelegt. Nach einen Neustart durch das init-Script hat er aber wieder auf die alte Config zugegriffen - da fehlte dann alles neue.

Du kannst ja mal auf der Linux-Kommandozeile

Code Auswählen Erweitern

ps aux|grep fhem

ausführen. Wenn dann irgendetwas mit relativer Pfad-Angabe für die fhem.cfg angezeigt wird, vermute ich, Du hast dasselbe Problem wie ich.
Als Lösung würde ich das Init-Script bearbeiten und einen absoluten Pfad für die Config angeben, z.B. /opt/fhem/fhem.cfg - wo auch immer Deine Config liegt.

[devil77]

Danke für den Tip, klingt auf jeden Fall passender als die anderen Vermutungen.
Bei mir kommt in der Konsole das hier

Code Auswählen Erweitern

/usr/bin/perl fhem.pl configDB
Das ganze sollte doch out of the box laufen, oder nicht?

[CoolTux]

Zwei Möglichkeiten kommen da in Verdacht

• wie Du den anderen Posts entnehmen kannst ist ja der Config Pfad bei Dir ein gaaaanz anderer, gibt es diese Datei configDB überhaupt bei Dir unter /opt/fhem/?
• wenn Du die erste Frage beantwortest, sitzt das Problem vor dem Bildschirm

Grüße

[devil77]

Wie kommst Du drauf das ich aus den anderen Post's meine Config entnehmen kann?
Und bei mir ist es kein aaaaanderer Pfad, fhem.pl und configdb liegen beide unter /opt/fhem.

[CoolTux]

Ja so eine ähnliche Antwort dachte ich mir schon.
Tut mir leid, ich wollte Dich nicht angreifen oder anmachen oder so. Danke für Deine Antwort.


Ich bin dann mal raus.

[CoolTux]

Ok löse auf.

Der Threadersteller speichert seine Config in eine Konfigurationsdatei. Damit meine ich die gesamte Konfiguriert von FHEM. Alle defines und attrs und haste nicht gesehen.

Du dagegen speicherst Deine Konfig in eine KonfigurationsDATENBANK. Deine erwähnte Datei configDB ist nur eine Konfigurationsdatei für den Start von FHEM, damit fhem beim Start auf die DB zu greifen kann. Da steht dann drin wie das Schema der DB heißt, unter welcher IP mit welchem Port sie zu erreichen ist und Benutzername, Passwort.


Daher ist es ganz logisch das die Antworten der Helfenden nicht bei Dir passen können, und auch nicht die Antwort von Happy FHEM User.



Grüße

[alpha1974]

Probleme mit der ConfigDB machen die Fehlersuche doch noch komplexer, weil noch die Datenbank-Anbindung/Server einbezogen werden müssen. Allerdings scheint das ja wohl nicht den Threadersteller zu betreffen.

Muss mich hier mal mit dran hängen, weil genau das gleiche Problem.

Siehe oben, die Symptome scheinen gleich zu sein, aber die Ursache kann eine ganz andere sein. Vielleicht besser in einem neuen Thread probieren?

Gruß
alpha1974

[micomat]

ich nix configDB
das mit dem Pfad im Start Script hab ich schon geprueft, da sieht bei mir alles gut aus.
Das interessante ist, dass eben teilweise auch FHEM backup-Files nach dem reboot weg waren... die, die ich vor dem reboot fuer ein solches szenario noch erstellt hab... Aktuell traue ich mich ehrlich gesagt nich das Teil neu zu starten.

[Wernieman]

Code Auswählen Erweitern

...FHEM backup-Files nach dem reboot weg waren...

Das hört sich jetzt nicht nach einem FHEM-problem, sondern vom darunterliegenden Betriebsystem an.

Deshalb:
1. BACKUP des FHEM-Verzeichnisses außerhalb des RasPi
2. Verwendest Du schon erwähnte "SD-Card" Schreibreduzier-Programme?

[micomat]

Ich habe mittlerweile auch Backups ausserhalb des Pi liegen.
Solche Programme verwende ich nicht bewusst. Sind die automatisch mit installiert?

[Wernieman]

Welche Diestri hast Du denn?

[micomat]

Raspbian Jessie müsste es sein

[Wernieman]

"..müste..."

Weist Du, nach welcher Anleitung Du gegangen bist?

"müste" ist leider nicht gleich "Wissen"

[devil77]

Das Paket ist nicht Standard und muss per Hand installiert werden.
Aber zum prüfen einfach per ssh und folgenden Befehl absetzen

Code Auswählen Erweitern

dpkg - l fs2ram

[CoolTux]

Das Paket ist nicht Standard und muss per Hand installiert werden.
Aber zum prüfen einfach per ssh und folgenden Befehl absetzen

Code Auswählen Erweitern

dpkg - l fs2ram

Code Auswählen Erweitern


dpkg -l fs2ram


[micomat]

sieht nichts so aus:

Code Auswählen Erweitern

dpkg -l fs2ram
dpkg-query: no packages found matching fs2ram


[alpha1974]

Die Ausgabe von mount hast Du ja schon gepostet, aber vielleicht hilft ein Blick in /etc/fstab:

Code Auswählen Erweitern

cat /etc/fstab
Und wie sehen die Verzeichnisse aus?

Code Auswählen Erweitern

ls -lah /opt

Code Auswählen Erweitern

ls -lah /opt/fhem

[Wernieman]

was mir gerade Auffällt ... ich aber kein RasPi-Besitzr bin:

Du schriebst das FHEM auf der SD ist. Laut Mount:

Code Auswählen Erweitern

/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
Ist /dev/mmcblk0 nicht der Flash-Speicher des RasPi??

[RaspiLED]

Hi,
Nö die SD das passt schon.
Gruß Arnd


FHEM auf Raspberry Pi 2, CUL, Signalduino, Intertechno, WifiLight mit H801 - ESP8266, ...

[Jens_B]

Mal ne doofe Frage: habt ihr euer fhem von einen pi1 auf einen pi2 umgezogen?
Schaut doch mal bitte ob ihr euren pi2 übertatet habt, in der config Datei
Sollte beim pi2
Als arm_freq=1000 stehen
Core_freq=450
Sdram_freq=450
Over_voltage=2

Das ist oft nicht richtig, wenn die konfig von einem Pi 1 übernommen wurde.

Das erzeugt die merkwürdigsten Effekte (unregelmäßige Abstürze, Sd Karten Schreibfehler, etc)
Gruß
Jens


Gesendet von iPhone mit Tapatalk

PS: Edit arm_freq=900  ist Standard.

[micomat]

werde das alles mal checken danke fuer die tips.
ich hab mir gestern ein neues, groesseres NAS besorgt auf dem ich zukuenftig auch die Logs aller FHEM und deren Backups speichern werde um die SD zu schonen.

[micomat]

Also die config.txt ist sauber. Da ist nichts dergleichen zu finden.

Hier noch die Ausgaben:

Code Auswählen Erweitern

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that


drwxrwxrwx 11 fhem root 4,0K Jan 16 19:26 fhem

drwxrwxrwx 11 fhem root    4,0K Jan 16 19:26 .
drwxr-xr-x  7 root root    4,0K Nov  7  2015 ..
drwxrwxrwx  2 fhem dialout 4,0K Mai 17 21:12 backup
-rw-r--r--  1 fhem dialout 145K Mai 15 22:22 CHANGED
-rw-r--r--  1 fhem dialout  33K Mai 15 22:22 configDB.pm
drwxrwxrwx 32 fhem dialout 4,0K Sep  6  2015 contrib
drwxrwxrwx  2 fhem dialout 4,0K Aug  5  2015 demolog
drwxrwxrwx  4 fhem dialout 4,0K Aug  5  2015 docs
drwxrwxrwx  5 fhem dialout  20K Mai 15 22:22 FHEM
-rw-r--r--  1 fhem dialout  59K Jun 15 06:34 fhem.cfg
-rw-r--r--  1 fhem dialout  16K Mai 15 22:22 fhem.cfg.demo
-rw-r--r--  1 pi   pi       59K Jan 16 19:26 fhem.new
-rw-rw-rw-  1 fhem dialout  73K Jan 16 19:17 fhem.old
-rw-r--r--  1 fhem dialout 121K Mai 15 22:22 fhem.pl
-rw-r--r--  1 fhem dialout  17K Apr 23  2014 fhem.sav
lrwxrwxrwx  1 pi   pi        20 Nov  9  2015 log -> /media/usb0/fhemlog/
-rw-rw-rw-  1 fhem dialout  761 Okt  6  2013 README_DEMO.txt
drwxr-xr-x  5 fhem dialout 4,0K Mai 15 22:22 restoreDir
drwxr-xr-x  7 fhem dialout 4,0K Apr  1  2015 smaspot
drwxr-xr-x  2 fhem dialout 4,0K Mai 15 22:22 unused
drwxrwxrwx  9 fhem dialout 4,0K Nov  8  2015 www


[micomat]

So, ich hab jetzt heute, nachdem "dmesg" einige FS Fehler ausgeworfen hat, eine neue SD mit dem Image der alten bespielt.
Haarstraeubend! Die haelfte der Files war nicht da, nachinstallierte Module haben ploetzlich wieder gefehlt, usw...
Ich hoffe das mit der neuen SD nun ruhe ist.

[topfi]

Ich habe eine Samsung-SD in meinem Zweit-Raspi, der nur als Intertechno-Repeater fungiert.

Seit einem kurzzeitigen Stromausfall (Gewitter) hatte diese Karte einen Defekt. Sie läßt sich nicht mehr dauerhaft beschreiben. Das bedeutet, während des Betriebs scheint alles in Ordnung, die Logs werden gefüllt usw. Nach einem Reboot ist aber alles wieder auf dem Stand vom 4. Juni. Immer. Egal, was ich mache. Nein, der Lock-Schalter ist nicht aktiviert. Es kommt auch keine Fehlermeldung, im Raspi funktioniert sie scheinbar normal. Nur neu partitionieren oder formatieren läßt sie sich nicht: Weder unter Windows, Linux, Android usw. Selst im Fotoapparat und im Handy nicht. Immerhin: Super Backup-System für meinen Repeater, solange ich nichts ändere...

Der Raspi hat nun eine neue Karte und eine USV.