Hi zusammen,
Seit über einem Jahr läuft mein Fhem System auf einem Raspberry Pi 3 nun sehr zuverlässig.
Jede Nacht erstelle ich ein Backup auf einem Netzlaufwerk, was auch super funktionierte.
Aber vor 2 Wochen fing es an, dass mein Fhem jeden Tag aufs neue nicht mehr erreichbar ist und ich ihn neustarten muss.
ich vermutete den nächtlichen backup-Prozess: Also im Web-CLI den backup cmd manuell ausgeführt, und kurz darauf ist FHEM nichtmehr erreichbar.
Ich kann die IP-Adresse zwar noch pingen, aber per WEB und SSH erreiche ich das System nichtmehr.
Eine Änderung vom System habe ich seit bestimmt 4-6 Wochen nichtmehr vorgenommen.
Als erstes habe ich nun raspbian upgedatet und danach FHEM, leider ohne eine Verbesserung.
das Netzlaufwerk ist im raspbian noch gemountet und der Zugriff funktioniert.
Zum Zeitpunkt des Backups habe ich folgende Einträge in der FHEM-Logfile:
(Nach dem Backup Eintrag ist das System nicht mehr erreichbar und ein aus/einschalten vom Raspberry Pi notwendig. )
2017.12.14 23:59:26 3: FHEMWEB WEB CSRF error: ne csrf_679575281668381 for client WEB_192.168.2.1_62040. For details see the csrfToken FHEMWEB attribute.
2017.12.14 23:59:59 2: Backup with command: tar -cf - "./3.test" "./alexa-fhem" "./backup" "./certs" "./CHANGED" "./concheck.log" "./concheck.sh" "./concheck.sh.save" "./configDB.pm" "./contrib" "./demolog" "./docs" "./etc_init.d_fhem_ORG_BU" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./killfhem.sh" "./killwatchdog.sh" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./regSave.cfg" "./restoreDir" "./runfhem.sh" "./runwatchdog.sh" "./startfhem" "./stopfhem" "./test" "./transferscript.sh" "./unused" "./watchdogloop.sh" "./www" "./yowsup" |gzip > /opt/fhem/backup/FHEM-20171214_235959.tar.gz
2017.12.14 23:59:59 3: AT_Backup: Started the backup in the background, watch the log for details
2017.12.14 23:17:12 1: Including fhem.cfg
2017.12.14 23:17:12 3: telnetPort: port 7072 opened
2017.12.14 23:17:13 3: WEB: port 8083 opened
2017.12.14 23:17:13 3: WEBphone: port 8084 opened
2017.12.14 23:17:13 3: WEBtablet: port 8085 opened
2017.12.14 23:17:13 2: eventTypes: loaded 2099 events from ./log/eventTypes.txt
2017.12.14 23:17:14 3: Opening ZWAVE1 device /dev/ttyAMA0
2017.12.14 23:17:14 3: Setting ZWAVE1 serial parameters to 115200,8,N,1
2017.12.14 23:17:15 3: ZWAVE1 device opened
2017.12.14 23:17:15 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2017.12.14 23:17:16 2: Registering GEOFANCY geofancy for URL /geo...
2017.12.14 23:17:16 3: WEBhook: port 8088 opened
2017.12.14 23:17:16 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.12.14 23:17:16 3: Opening HMLAN1 device 192.168.2.220:1000
2017.12.14 23:17:16 1: HMLAN_Parse: HMLAN1 new condition init
2017.12.14 23:17:16 3: HMLAN1 device opened
2017.12.15 00:12:01 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
Ich habe für das Backup ein SYS_BackupRUN angelegt, hier das list des notify devices:
Internals:
DEF SYS_Backup:* {
fhem("backup");
opendir DIR, "/mnt/AirPort" or die $!;
my @mybackups =();
while(my $file = readdir DIR){
next if($file eq "." || $file eq "..");
push(@mybackups,$file);
}
closedir DIR;
@mybackups = join("</br>", sort(@mybackups) );
fhem("set SYS_Backup @mybackups");
}
NAME SYS_BackupRun
NR 106
NTFY_ORDER 50-SYS_BackupRun
REGEXP SYS_Backup:*
STATE active
TYPE notify
READINGS:
2017-12-15 00:12:02 state active
Attributes:
group Backup-Einstellung
room s_Systemconfig
So wie ich das als Laie interpretiere wird versucht das backup in /opt/fhem/backup/ zu speichern und da das Verzeichnis ./backup mit ins "backup" kommt, stürzt hier fhem wahrscheinlich ab, oder liege ich da falsch?
Warum wird hier aber nicht das Netzlaufwerk verwendet, bisher hat das immer geklappt, Netzlaufwerk ist auch noch unter der selben IP-Adresse vorhanden und das mount auf dem RaspberryPi funktioniert ebenso.
Würde mich freuen, wenn mir hier jemand weiterhelfen kann.
Beste Grüße
Dave
Ich würde woanders suchen:
Der Rechner stürzt Dir komplett ab? Also incl. Betriebsystem?
Was sagen denn die üblichen Verdächtigen? /Var/log/kern.log, /var/log,syslog etc.
Danke Wernieman,
was ich noch vergessen habe zu sagen, dass ich auch den Raspberry Pi 3 getauscht habe (SD-Karte ist jedoch die gleiche).
syslog zeigt zum backup zeitpunkt folgendes:
Dec 14 23:58:01 FhemPi /USR/SBIN/CRON[14419]: (root) CMD (/opt/fhem/concheck.sh)
Dec 14 23:58:01 FhemPi /USR/SBIN/CRON[14418]: (CRON) info (No MTA installed, discarding output)
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@$
Dec 14 23:17:10 FhemPi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2119" x-info="http://www.rsyslog.com"] start
Dec 14 23:17:10 FhemPi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00
Dec 14 23:17:10 FhemPi kernel: [ 0.000000] Initializing cgroup subsys cpuset
kern.log:
Dec 14 19:28:24 FhemPi kernel: [ 60.557047] FS-Cache: Netfs 'cifs' registered for caching
Dec 14 19:28:24 FhemPi kernel: [ 60.557938] Key type cifs.spnego registered
Dec 14 19:28:24 FhemPi kernel: [ 60.558060] Key type cifs.idmap registered
Dec 14 23:17:10 FhemPi kernel: imklog 5.8.11, log source = /proc/kmsg started.
Dec 14 23:17:10 FhemPi kernel: [ 0.000000] Booting Linux on physical CPU 0xf00
Dec 14 23:17:10 FhemPi kernel: [ 0.000000] Initializing cgroup subsys cpuset
Dec 14 23:17:10 FhemPi kernel: [ 0.000000] Initializing cgroup subsys cpu
solange kein backup ausgeführt wird, habe ich aktuell auch keine Probleme mit dem System.
Zitat von: vga am 15 Dezember 2017, 09:34:10
Zum Zeitpunkt des Backups habe ich folgende Einträge in der FHEM-Logfile:
(Nach dem Backup Eintrag ist das System nicht mehr erreichbar und ein aus/einschalten vom Raspberry Pi notwendig. )
2017.12.14 23:59:59 3: AT_Backup: Started the backup in the background, watch the log for details
2017.12.14 23:17:12 1: Including fhem.cfg
2017.12.14 23:17:12 3: telnetPort: port 7072 opened
2017.12.14 23:17:13 3: WEB: port 8083 opened
2017.12.14 23:17:13 3: WEBphone: port 8084 opened
2017.12.14 23:17:13 3: WEBtablet: port 8085 opened
2017.12.14 23:17:13 2: eventTypes: loaded 2099 events from ./log/eventTypes.txt
.....
2017.12.14 23:17:16 3: HMLAN1 device opened
2017.12.15 00:12:01 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
ob es der grunde für deine probleme ist, weiß ich nicht, aber du hast Zeitsprünge!
dein fhem wird neu gestartet!! oder gleich der ganze raspi?? hast du das manuell ausgelöst??
Richtig nils_, wenn ein Backup ausgeführt wird und alles hängt, bleibt mir natürlich nur noch ein harter Neustart, vom Strom trennen und wieder dran.
Während des Bootvorgangs ist die Zeit nicht korrekt, wenn der Pi aber fertig gebootet hat, bekommt er die korrekte Zeit über einen Zeitserver.
Zeitsprünge kommen also nur wenn der Pi am durchstarten ist. mir ist nicht aufgefallen ob das schon immer so ist, mit der Kernproblematik kann ich das aber nicht in Verbindung bringen.
ok alles klar, dann passt das vermutlich so.
Also wenn ich es mir ansehe:
Dec 14 23:58:01 FhemPi /USR/SBIN/CRON[14418]: (CRON) info (No MTA installed, discarding output)
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@$
Dec 14 23:17:10 FhemPi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2119" x-info="http://www.rsyslog.com"] start
die ^@ sind NICHT normal ... dazwischen dürfte der Harte reboot sein.
Du hast die SD Karte getauscht, wie hast Du die neue geschrieben?
Ich würde denken Du hast es geklont und auf dem Filesystem ein defekt. Diesen hast Du beim Clonen mit kopiert.
Zitat...den Raspberry Pi 3 getauscht habe (SD-Karte ist jedoch die gleiche).
@ Wernieman: Nur den Pi getauscht, SD-Karte habe ich übernommen. ;)
Bisher deutet nichts weiter darauf hin dass die SD-Karte ein defekt hat, solange ich kein Backup ausführe läuft alles normal.
Zitat von: vga am 15 Dezember 2017, 11:58:56
@ Wernieman: Nur den Pi getauscht, SD-Karte habe ich übernommen. ;)
Bisher deutet nichts weiter darauf hin dass die SD-Karte ein defekt hat, solange ich kein Backup ausführe läuft alles normal.
naja, diese "Schmierzeichen" deuten auf eine defekte SD Karte hin ...
Backup braucht temporären Speicherplatz auf der SD Karte und gibt ihn nach dem Backup natürlich auf wieder frei ...
zum Testen kannst Du z.B. folgendes machen:
auf dem PI einloggen
df -h --> merken wieviel frei Platz auf der SD Karte noch vorhanden ist und ggfls in der nächsten Zeile Count verkleinern
dd if=/dev/null of=sdKartenTest.tmp bs=1M count=1000
rm sdKartenTest.tmpdamit schreibst Du mal eben 1GB (bs=1Megabyte * Count=1000) Nullen in die Datei sdKartenTest.tmp wenn dabei in Hänger kommt ....
Zitat von: vga am 15 Dezember 2017, 09:34:10
So wie ich das als Laie interpretiere wird versucht das backup in /opt/fhem/backup/ zu speichern und da das Verzeichnis ./backup mit ins "backup" kommt, stürzt hier fhem wahrscheinlich ab, oder liege ich da falsch?
Hi Dave,
Ich denke dieser Gedanke war falsch.
hast Du backupdir gesetzt? -> https://forum.fhem.de/index.php/topic,26728.msg196912.html#msg196912
Gruß Otto
OK, das wusste ich nicht, Danke Wuppi68 für den Vorschlag!
Den Befehl habe ich als Benutzer pi im Homeverzeichnis ausgeführt.
pi@FhemPi ~ $ dd if=/dev/null of=sdKartenTest.tmp bs=1M count=1000
0+0 Datensätze ein
0+0 Datensätze aus
0 Bytes (0 B) kopiert, 0,000100573 s, 0,0 kB/s
der count wird wohl noch nicht wirklich ausgeführt:
-rw-r--r-- 1 pi pi 0 Dez 15 12:29 sdKartenTest.tmp
Hi,
versuch mal
dd if=/dev/zero of=sdKartenTest.tmp bs=1M count=1000Zitat/dev/zero provides an endless stream of zero bytes when read. This function is provided by the kernel and does not require allocating memory.
;D
Gruß Otto
@Otto123,
stimmt, folgendes ist gesetzt:
attr global backupdir /opt/fhem/backup
Hab ich das richtig verstanden, wenn das Verzeichnis gesetzt ist wird es mitgesichert und wenn nicht wird es ausgelassen?
Wenn, dann hätte ich das eigentlich andersrum erwartet ??? ...aber ok, man lernt ja dazu.
Damit würde ich doch meine aktuell zu erstellende Sicherung mitsichern und gerate in eine Schleife?
Wird mein Backup also standardmäßig in backupdir geschrieben? ....kann mir absolut nicht erklären wieso ich dann auf dem Netzlaufwerk soviele Sicherungen liegen hab, geändert habe ich das definitiv nicht :o
Zitat von: Otto123 am 15 Dezember 2017, 12:45:45
Hi,
versuch mal
dd if=/dev/zero of=sdKartenTest.tmp bs=1M count=1000
;D
Gruß Otto
Danke Otto,
mein Fehler vga's Problem :-)
zero ist eben nicht immer null ;D ;D ;D
Das mit dem backupdir verstehe ich so. Es ist also kontraproduktiv es auf den Wert zu setzen auf den es per default steht?!
Gruß Otto
Danke soweit für die Hilfe! :)
also das top File konnte ich mit 1GB große erstellen, is nix passiert - ist zwar gut, aber noch keine Lösung. ;)
Ich habe jetzt mal das backupdir auf mein Netzlaufwerk gelegt, da wird nun auch angefangen das backup zu erstellen, aber auch hier bleibt dann nach 4 Minuten alles hängen. :(
Irgendwie fällt mir nichtsmehr ein.
muss ich das Backupdir vielleicht irgendwie aus dem backup ausschließen?
Ich habe das so verstanden, dass Du das nicht musst:
ZitatIch habe das gerade mal getestet. Bei mir wird das ./backup Verzeichnis ebenfalls mit gesichert (laut Log). Das Verzeichnis ist jedoch leer, da ich das Attribut backupdir auf einen anderen Pfad gesetzt habe. Nach weiteren Tests sieht es für mich so aus, als wäre das ./backup Verzeichnis immer dann im Backup enthalten, wenn das Attribut backupdir gesetzt ist. Wohl auch, wenn es den Pfad /PFAD/zu/FHEM/backup enthält.
Gruß Otto
Ja, danke Otto123, so macht es ja auch Sinn.
Wenn jetzt der Zielpfad und höchst wahrscheinlich auch die SD-Karte ausgeschlossen werden kann als, bin ich echt ratlos.
In den Fhemlog/syslog/kernellog steht einfach nicht mehr drin. :(
Naja wenn es nur beim backup passiert kannst Du doch einfach mal das tar Kommando im Terminal anstoßen und schauen ob es auch passiert. Und dann einzelne Unterpfade nehmen.
Gruß Otto
Genau das hätte ich jetzt auch mal vorgeschlagen.
ich hab jetzt mal den Pi an einen Monitor gehängt und direkt auf der Konsole den backup cmd ausgeführt. Nach einigen Minuten kommt das was auf dem Bild zu sehen ist.
...also wohl doch ein Problem mit der SD-Karte?
Zitat von: vga am 15 Dezember 2017, 22:10:23
ich hab jetzt mal den Pi an einen Monitor gehängt und direkt auf der Konsole den backup cmd ausgeführt. Nach einigen Minuten kommt das was auf dem Bild zu sehen ist.
...also wohl doch ein Problem mit der SD-Karte?
sieht glatt so aus ... dann kamen bestimmt auch bei dem dd Befehl auf der Console die entsprechenden Meldungen
...möglich.
Alles klar, dann soweit mal Danke für eure Unterstützung, dann werd ich mal nen neues System aufsetzen! :/
Ich weiß jetzt nicht, ob es die SD ist, auf jeden Fall hat das Dateisystem einen defekt! Mann könnte noch probieren, ob ein Dateisystemcheck hilft.
Du könntes, wenn das System noch läuft, mal gucken, ob i/o-Probleme im Kern-log auftreten:
grep -i i/o /var/log/kern.log
Danke Wernieman für den Tipp, der cmd gibt keine Meldungen zurück.
Ich habe nun einen 1zu1 Sektor-Clone von der SD-Karte gemacht, die neue Karte im Pi eingesetzt und noch einmal backup getestet.
Diesmal ging das backup wieder ohne Probleme. :)
Danke für den Support!
Dann mach bitte auch mal einen filesystemcheck! Vorher würde ich der neuen Karte auch nicht trauen ...