Problem: Fhem/Raspi stürzt durch "backup"-cmd ab

Begonnen von vga, 15 Dezember 2017, 09:34:10

Vorheriges Thema - Nächstes Thema

vga

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


Wernieman

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.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

vga

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.

nils_

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??
viele Wege in FHEM es gibt!

vga

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.

nils_

viele Wege in FHEM es gibt!

Wernieman

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.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

vga

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.

Wuppi68

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.tmp



damit schreibst Du mal eben 1GB (bs=1Megabyte * Count=1000) Nullen in die Datei sdKartenTest.tmp wenn dabei in Hänger kommt ....

FHEM unter Proxmox als VM

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

vga

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



Otto123

Hi,
versuch mal
dd if=/dev/zero of=sdKartenTest.tmp bs=1M count=1000
Zitat/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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

vga

@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






Wuppi68

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 :-)
FHEM unter Proxmox als VM

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz