ioBroker / PI friert ein ENOENT "Cannot save backup file"
-
@thomas-braun Danke für die Einschätzung, ist halt ein Standart Pi3, bin davon ausgegangen, dass ioBroker darauf im "normalen" Umfang laufen sollte...
Zum Dateisystem: Ideen, was ich tun könnte/sollte, um dem auf den Grund zu gehen oder wieder in den Normalbereich zu kommen? Das Setup lief ja ungefähr ein Jahr zwar in etwas kleinerem Umfang als ich es jetzt nutze, aber ohne dass mir derartiges aufgefallen wäre. -
@wendy2702 Außer Stecker ziehen wusste ich mir nicht wirklich zu helfen, wenn weder über Webinterface noch über SSH was zu erreichen war.
Die Geschichte hier ist mein erster größerer Ausflug mit Linux/Unix, wäre super, wenn Du mir einen Tipp geben kannst, wie ich in das Syslog am besten reinschaue bzw. wie ich dort hinkomme, wo ich evtl. was rausfinden kann... -
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
@thomas-braun Danke für die Einschätzung, ist halt ein Standart Pi3, bin davon ausgegangen, dass ioBroker darauf im "normalen" Umfang laufen sollte...
Zum Dateisystem: Ideen, was ich tun könnte/sollte, um dem auf den Grund zu gehen oder wieder in den Normalbereich zu kommen? Das Setup lief ja ungefähr ein Jahr zwar in etwas kleinerem Umfang als ich es jetzt nutze, aber ohne dass mir derartiges aufgefallen wäre.Was ist normaler Umfang? Du kannst mal mit dem kleinen Linux-Werkzeugkasten aus meiner Signatur das System abklopfen.
-
@thomas-braun 15 Instanzen, die laufen, atktuell ca. 860 MB RAM belegt.
Den Guide finde ich super, hangle mich da grade durch. Habe aber das Problem, dass ich nach der config einen reboot gemacht/versucht habe und jetzt wieder auf "Connection refused" hänge.
Bei Deinem Guide komme ich ja aber nirgends am Dateisystem selbst vorbei, da scheint ja irgendwas im Argen zu liegen. Was kann ich da tun?
Wenn nichts hilft, aktuelles Pi-Image flashen, ioBroker installieren und Backup einspielen? Oder fange ich mir dann potentiell das selbe Problem wieder ein?
-
@x4n70 860 MB RAM im Bummelbetrieb. Wenn es was heftiger wird (Backup usw.) dürfte der Speicher Mangelware werden.
-
@thomas-braun Habe heute Nacht noch den kompletten Werkzeugkasten-Beitrag abgearbeitet, vor allem Systemupdates hatte ich bisher keine gemacht. Könnte es sein, dass das geholfen hat, evtl. korrupte Files zu überschreiben? Das war für mein Gefühl einiges, was da geupdated wurde, wie gesagt, vor etwa einem Jahr neu aufgesetzt.
Über Nacht hatte ich keine derartigen Fehler mehr.
Zum RAM: Glaube ich habe gestern den falschen Wert abgelesen, die Auslastung sieht so aus:
gesamte RAM-Nutzung: 955 MB / Frei: 39% = 358 MBDas scheint mir im "okayen" Bereich zu liegen, oder?
-
@x4n70 Wo liest du das ab?
Mach mal
df -hund
topBeenden mit "STRG+C" und zeige uns davon die ausgabe als Text Zeilen.
-
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
vor allem Systemupdates hatte ich bisher keine gemacht.
Das sollte man halt immer zuerst tun, ich weiß gar nicht wie viele Versionen von z. B. der Firmware da zwischenzeitlich mal aktuell waren. Davon sind einige bei mir auch nicht richtig rund gelaufen, viele Meldungen im Log, allerdings lief das bei mir trotzdem.
-
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
Glaube ich habe gestern den falschen Wert abgelesen, die Auslastung sieht so aus:
das ist nicht immer der wahre Wert, schon gar nicht der aus Spitzen.
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
15 Instanzen, die laufen
das ist bei 1GB RAM sehr grenzwertig.
Dann fängt wahrscheinlich dein RasPi an zu swappen und lagert Teile des RAMs auf die SD-Karte aus.
Das kostet zum einen Zeit, zum andern Rechenleistung, was beides zu erhöhter Load führt, was wiederum dazu führt, dass der RasPi keine weiteren Befehle mehr abarbeiten kann.
topwird's zeigen
Dann "friert" er eben ein. -
Habe es ein paar Minuten laufen lassen, das ist zumindest für diese Zeit recht repräsentativ denke ich, zwischenzeitlich geht die CPU-Last eher runter, peakt aber auch mal kurz bei 50%, aber wir suchen ja nach RAM habe ich verstanden.
Die RAM % der ioBroker-Prozesse waren in dieser Zeit recht konstant.
top - 11:02:12 up 10:41, 1 user, load average: 0.08, 0.19, 0.18 Tasks: 135 total, 1 running, 134 sleeping, 0 stopped, 0 zombie %Cpu(s): 6.6 us, 0.9 sy, 0.0 ni, 92.1 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st MiB Mem : 924.2 total, 128.8 free, 576.9 used, 218.5 buff/cache MiB Swap: 100.0 total, 58.7 free, 41.2 used. 336.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2144 iobroker 20 0 183556 90696 28312 S 13.9 9.6 38:04.16 node 2162 iobroker 20 0 172728 75436 29416 S 6.3 8.0 8:38.72 node 2707 iobroker 20 0 191276 101028 27700 S 3.0 10.7 8:50.66 node 2720 iobroker 20 0 153072 64828 28892 S 2.3 6.9 4:48.73 node 2736 iobroker 20 0 154300 64232 27876 S 2.0 6.8 3:16.72 node 393 avahi 20 0 6032 2768 2360 S 1.3 0.3 1:51.81 avahi-daemon 2700 iobroker 20 0 195328 56608 29496 S 0.7 6.0 1:18.39 node 2753 iobroker 20 0 149348 57896 28360 S 0.7 6.1 1:16.98 node 8730 pi 20 0 10368 3076 2496 R 0.7 0.3 0:01.87 top 12 root 20 0 0 0 0 I 0.3 0.0 0:14.28 rcu_sched 2818 iobroker 20 0 142748 50060 28472 S 0.3 5.3 0:54.64 node 6949 pi 20 0 12240 4264 3472 S 0.3 0.5 0:00.56 sshd 1 root 20 0 33692 7508 6340 S 0.0 0.8 0:08.17 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.09 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_rude_ 10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_trace 11 root 20 0 0 0 0 S 0.0 0.0 0:02.95 ksoftirqd/0 13 root rt 0 0 0 0 S 0.0 0.0 0:00.02 migration/0 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 16 root rt 0 0 0 0 S 0.0 0.0 0:00.02 migration/1 17 root 20 0 0 0 0 S 0.0 0.0 0:00.81 ksoftirqd/1 20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2 21 root rt 0 0 0 0 S 0.0 0.0 0:00.01 migration/2 22 root 20 0 0 0 0 S 0.0 0.0 0:01.74 ksoftirqd/2 25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3 26 root rt 0 0 0 0 S 0.0 0.0 0:00.01 migration/3 27 root 20 0 0 0 0 S 0.0 0.0 0:00.73 ksoftirqd/3 30 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 31 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns 35 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd 36 root 20 0 0 0 0 S 0.0 0.0 0:00.07 khungtaskd 37 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper 38 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback 39 root 20 0 0 0 0 S 0.0 0.0 0:05.50 kcompactd0 57 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd 58 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio 59 root -51 0 0 0 0 S 0.0 0.0 0:00.00 watchdogd 61 root 0 -20 0 0 0 I 0.0 0.0 0:01.34 kworker/1:1H-kblockd 62 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rpciod 63 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/u9:0-hci0 64 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 xprtiod 65 root 20 0 0 0 0 S 0.0 0.0 0:02.61 kswapd0 66 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 nfsiod 67 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 iscsi_eh 68 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 iscsi_destroy 69 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 dwc_otg 70 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 DWC Notificatio 72 root 1 -19 0 0 0 S 0.0 0.0 0:00.00 vchiq-slot/0 73 root 1 -19 0 0 0 S 0.0 0.0 0:00.00 vchiq-recy/0 74 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 vchiq-sync/0 75 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 zswap-shrink 78 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mmc_complete 79 root 0 -20 0 0 0 I 0.0 0.0 0:01.03 kworker/2:1H-kblockd 80 root 0 -20 0 0 0 I 0.0 0.0 0:03.17 kworker/0:1H-mmc_complete 81 root 20 0 0 0 0 S 0.0 0.0 0:01.09 jbd2/mmcblk0p2- 82 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ext4-rsv-conver 84 root 20 0 0 0 0 I 0.0 0.0 0:05.19 kworker/u8:1-events_unbound 86 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ipv6_addrconf 91 root 0 -20 0 0 0 I 0.0 0.0 0:01.35 kworker/3:1H-kblockd 115 root 20 0 19028 6068 5776 S 0.0 0.6 0:01.49 systemd-journal 146 root 20 0 18112 2760 2552 S 0.0 0.3 0:00.94 systemd-udevd 166 root 20 0 0 0 0 S 0.0 0.0 0:00.00 vchiq-keep/0 169 root 10 -10 0 0 0 S 0.0 0.0 0:00.00 SMIO 200 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mmal-vchiq 201 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mmal-vchiq 202 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mmal-vchiq 204 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mmal-vchiq 253 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 cfg80211 260 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 brcmf_wq/mmc1:0 262 root 20 0 0 0 0 S 0.0 0.0 0:00.00 brcmf_wdog/mmc1 313 systemd+ 20 0 22416 4792 4724 S 0.0 0.5 0:00.56 systemd-timesyn 349 root 20 0 7948 2276 2220 S 0.0 0.2 0:00.13 cron 355 root 20 0 25512 2636 2340 S 0.0 0.3 0:00.28 rsyslogd 360 nobody 20 0 4320 1896 1880 S 0.0 0.2 0:00.49 thd 361 root 20 0 27656 1332 1232 S 0.0 0.1 0:00.56 rngd 367 root 20 0 13144 5124 4936 S 0.0 0.5 0:00.41 systemd-logind 373 root 39 19 3692 1500 1460 S 0.0 0.2 0:00.04 alsactl -
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
MiB Swap: 100.0 total, 58.7 free, 41.2 used.
Der Speicher ist zu klein.
-
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
das ist zumindest für diese Zeit recht repräsentativ denke ich
ja, aber....
Es gibt Prozesse (Scheduled Adapter, Skripte) die nur zeitweise, dann aber auch teilweise massiv, Ressourcen benötigen.
Das muss in dieser Zeit z.B. nicht passiert sein.Die wichtigste Info steht hier:
MiB Swap: 100.0 total, 58.7 free, 41.2 used.Dir war irgendwann das RAM ausgegangen und Daten wurden auf die SD-Karte ausgelagert
-
@homoran Ich hatte das so verstanden, dass ich "zur Nutzung verfügbar wenn notwendig" so viel habe, wie gerade tatsächlich physisch frei ist (ca. 128 MB) + die ca. 218, die gerade als Cache verwendet werden. Sprich das was bei Avail Mem steht (336 MB).
Was mich viel mehr wundert/freut: Ich hatte ja bisher keine Aussetzer mehr, die waren ja auch so massiv, dass das mMn nicht von "da ist mal "kurz" der Speicher ausgegangen kommen kann, Pi war über Minuten bis hin zu einer halben Stunde dann nicht erreichbar (nicht mal über Konsole) und hat die im ersten Post genannten Fehlermeldungen zum Dateisystem gebracht. Die sind seit gestern Nacht zumindest mal weg.
Daher wundere ich mich, dass wir so intensiv bei der RAM-Ecke suchen, ich hätte es irgendwo anders gesucht.
Kann ich zum Dateisystem noch was tun? Googlen hat mir das sudo touch /forcefsck; sudo reboot zu Tage gefördert, macht das Sinn?
-
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
Ich hatte das so verstanden, dass ich "zur Nutzung verfügbar wenn notwendig" so viel habe, wie gerade tatsächlich physisch frei ist (ca. 128 MB) + die ca. 218, die gerade als Cache verwendet werden. Sprich das was bei Avail Mem steht (336 MB).
das ist korrekt - für den Moment!
der genutzte SWAP zeigt aber, dass es nicht immer reicht@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
das mMn nicht von "da ist mal "kurz" der Speicher ausgegangen kommen kann, Pi war über Minuten bis hin zu einer halben Stunde dann nicht erreichbar (nicht mal über Konsole)
das schaukelt sich dann hoch, und dauert eben so lange, bis es wieder normal wird, da in der Zwischenzeit alles mögliche auf und von der SD-Karte abgearbeitet werden muss.
Erst wenn alle diese Prozesse abgearbeitet sind (die dann wesenlich länger dauern, als wenn sie im RAM ablaufen), kann es sich normalisieren, wobei sich aber wie in einem Stau auf der Autobahn, immer wieder neue in der Schlange anstellenDort hast du auch "nur mal kurz" einen Unfall gehabt, trotzdem staut es sich dann 3 Stunden
-
@x4n70 sagte in ioBroker / PI friert ein ENOENT "Cannot save backup file":
Googlen hat mir das sudo touch /forcefsck; sudo reboot zu Tage gefördert, macht das Sinn?
Das macht das System automatisch, wenn es da Probleme gibt. forcen muss man das eigentlich nicht.
Die Erfolge eines fsck sind aber meist überschaubar, wenn es richtig reingehagelt hat.
