Hallo zusammen,
nachdem meine SD-Karte auf dem Raspi jetzt einige Male überraschend vollgelaufen ist, habe ich auch die Ursache dafür gefunden:
FHEM erstellt zwar nicht jeden Tag, aber dafür teilweise mehrmals täglich ein Backup (ich habe schon bis zu 6 Backups pro Tag gefunden, manchmal mit nur wenigen Minuten Abstand dazwischen).
Ich habe ja nichts gegen Backups und mache auch gelegentlich selbst welche :-) , aber alleine 18 in der letzten Woche ist einfach zuviel (ob die SD-Karte jetzt der richtige Ort dafür ist, ssteht auf einem anderen Blatt).
Aber keinen dieser Backups habe ich selbst angestossen und habe auch nie einen Cron-Job oder FHEM-Task (DOIF, at, ..) o.ä. definiert, der das erledigen soll.
Daher meine Frage: was kann FHEM veranlassen, selbst einen Backup anzustossen ?
Im Log sehe ich zu den jeweiligen Zeitpunkten immer einen 'normalen' Eintrag, als wenn ich ein Backup manuell angestossen hätte; mehr aber auch nicht.
Wie kann ich da weiter forschen ?
Einziger wager Hinweis vielleicht: ich baue gerade an meiner ersten FTUI-Oberfläche und da gibt es natürlich dauernd was zu tun ... Kann das damit zu tun haben ? Die Korrelation bei den Zeitpunkten ist allerdings eher lose ....
Schon mal vielen Dank für Eure Tipps
und Gruß aus Aachen
Uef
Zitat von: Uef am 05 Februar 2018, 12:42:10
was kann FHEM veranlassen, selbst einen Backup anzustossen ?
Du und nur du.
irgendwo der Browser offen, backup eingetragen und zurück springen - backup wird wiederholt.
Ich kenne das von Früher als backup im Browser nicht in den Hintergrund tauchte. Der Browser machte auf Grund der fehlenden Rückmeldung eine Wiederholung nach einem Timeout von 1 minute, dann hatte man immer zwei Backups hintereinander.
Also nur als Idee ...
Hast es evtl eingerichtet dass beim "save" automatisch ein backup erzeugt wird?
Wie schon oben von marvin78 erwähnt, FHEM macht nicht ohne Aufforderung Backups.
Hi,
evtl auch Backupbeforeupdate aktiv? Wobei so oft machst du sicher kein Update :-)
Grüße
Achim
Ah, vielen Dank für Eure Hinweise.
@marvin78: die Antwort hatte ich befürchtet :-(
@Otto123: klingt nachvollziehbar; da ich oft mit vielen Browserfenstern arbeite, wäre das eine Richtung, in die ich mal weiter forsche (auch wenn ich den Backup-Befehl selbst eher selten in der Eingabezeile habe ...)
@Frank_Huber: hm, wüsste jetzt auf Anhieb gar nicht, wie ich so etwas einrichten sollte
@Achim: nein, Updates mache ich ganz sicher seltener als Backups; ist aber auch nicht so eingestellt ...
Es bleibt also weiter nebulös ...
Gruß
Uef
Da klar ist, dass es nur durch dein tun (in welcher Form auch immer) ausgelöst werden kann, ist das hier ein Ratespiel. Du musst deine Config und alles drumherum durchsuchen. Das kann keiner von uns für dich machen. Nebulös ist hier nichts.
fhem.cfg öffnen,
darin nach "backup" suchen.
Wenn gefunden entsprechendes Device im Webinterface bearbeiten / löschen / whatever.
Hallo Frank,
Danke; das hatte ich bereits gemacht; 'backup' taucht da selbst mit Suchvarianten kein einziges Mal auf ...
Ich habe jetzt mal den loglevel von WEB hochgedreht; ggf. lässt sich drüber herausfinden, ob das Kommando von außen (über eine Connection ) kommt oder ob ich mir selbst etwas in die FHEM-Config eingebaut habe.
Danke und Gruß
Uef
Hallo zusammen,
leider bin ich mit dem Thema immer noch nicht weiter.
Die Backups finden nicht mehr ganz so häufig statt (daher habe ich in der Zwischenzeit die Backups auch einfach nur regelmässig gelöscht) und ich habe mir Alarme für den freien Speicherplatz eingerichtet, aber das grundsätzliche Problem besteht weiter und ist ja auch kein befriedigender Zustand.
In der gesamten FHEM Konfig finde ich einfach nichts zu "Backup".
Gibt es vielleicht eine Möglichkeit, die 98_backup.pm so zu erweitern, dass ich bei geeignetem Log-Level erkennen kann, von wo sie aufgerufen wird ? (dafür fehlen meine PERL-Kenntnisse nämlich bei weitem). Oder ist das am Ende doch immer der FHEM-Hauptprozess (falls der Aufruf aus FHEM kommt) ?
Danke für Eure Hilfe
Entferne doch mal die Datei 98_backup.pm aus FHEM und beobachte danach, ob im Logfile Fehler auftreten, weil ein Backup nicht ausgeführt werden konnte.
Nach der Fehlereingrenzung kannst Du die Datei dann wieder in FHEM verfügbar machen.
Gute Idee. Danke !!
Zitat von: Uef am 17 August 2021, 12:58:47
In der gesamten FHEM Konfig finde ich einfach nichts zu "Backup".
"Backup" oder "backup" gesucht?
Aber auch der Tipp von betateilchen wird dich dem Übeltäter näher bringen.
Es muss ja nicht unbedingt direkt in der Config eingetragen sein. Wenns in einer 99_myUtils steht und aufgerufen wird, findest du nix dazu in der .cfg
PS: Einfach mal ein
grep -r --exclude=*.js --exclude=*.svg --exclude=*.css " backup " ./
im FHEM-Ordner loslassen und schaun, ob was auffälliges dabei ist.
So, ich denke, ich habe einen Hinweis:
in den FHEM Logs fanden sich wiederholt folgende Kombinationen von Einträgen:
2021.08.08 17:22:29.261 5: CUL_HM FunkSchalterP_01 sent ACK:2
2021.08.08 17:22:29.335 2: backup include:
2021.08.08 17:22:29.393 2: backup include:
2021.08.08 17:22:29.411 2: Backup with command: tar czf ./backup/FHEM-20210808_172229.tar.gz "./www" "./README_DEMO.txt" "./fhem_backup.sh" "./restoreDir" "./FHEM" "./CHANGED" "./regSave.cfg" "./docs" "./MAINTAINER.txt" "./fhem.pl" "./demolog" "./archive_old_log_files.sh" "./backup_was_launched" "./log" "./fhem.cfg" "./contrib" "./archive" "./lib" "./updates" "./fhem_backup.log" "./unused" "./fhem.cfg.demo" "./configDB.pm"
2021.08.08 17:22:29.453 3: PowerHC return value: Started the backup in the background, watch the log for details
2021.08.08 17:22:36.714 5: CUL_HM FunkSchalterP_01 protEvent:CMDs_done
Auf die richtige Spur gebracht hat mich dann die Zeile mit dem PowerHC; das Device sagte mir gar nichts (kann mich nicht erinnern, das überhaupt angelegt zu haben oder zu welchem Zweck) und es stellte sich als ein notify heraus:
defmod PowerHC notify FunkSchalterP_01_Pwr:power:\s[1-9]{1}[0-9]* b
attr PowerHC room CUL_HM,Küche
Dessen Definition scheint offensichtlich unvollständig zu sein, denn die Aktion besteht nur aus dem "b".
Meine aktuelle Theorie ist, dass, wenn das notify getriggert wird, FHEM das "b" zu "backup" vervollständigt.
Wenn man nun weiß, wonach man suchen muss, finden sich im EventMonitor finden sich auch schnell die richtigen Events:
2021-08-08_17:22:29 FunkSchalterP_01_Pwr energyCalc: 414808
2021-08-08_17:22:29 FunkSchalterP_01_Pwr frequency: 49.94
2021-08-08_17:22:29 FunkSchalterP_01_Pwr power: 179
2021-08-08_17:22:29 FunkSchalterP_01_Pwr 47330.5
2021-08-08_17:22:29 FunkSchalterP_01_Pwr voltage: 221.4
das power Attribut des HM Funkschalter hat zufällig immer mal wieder einen Wert, der KEINEN Dezimalpunkt enthält und damit das Muster für das notify erfüllt.
Das erklärt dann auch, wieso die Backups so unregelmässig kamen (mal 1, 2 oder 3 am Tag, dann wieder tagelang Ruhe).
Woher dieses notify kommt und welchen Zweck es u.U. mal haben sollte, weiß ich noch nicht; vielleicht beim Testen etwas nicht zu Ende geschrieben oder ein Dateifehler in der fhem.cfg oder ... (ist vielleicht auch nicht so wichtig).
Ich werde das jetzt mal löschen und die Sache weiter beobachten; bin aber doch recht sicher, mit Eurer Hilfe die Ursache endlich endlich (!) gefunden zu haben.
@Icinger: Danke für das grep ! Das hat die hilfreichen Daten, die in den Logs ja quasi schon die ganze Zeit vor meiner Nase waren, so hervorgehoben, dass ich endlich den Zusammenhang gesehen habe.
Danke Euch und Grüße aus Aachen
Gebe mal "b" in die Kommandozeile ein ;)
Danke für den Tipp, aber das habe ich gestern natürlich auch gleich probiert (und vergessen zu erwähnen), da kam aber nur folgende Meldung, der ich dann wegen ihrer (für mich) mangelnden Aussagekraft nicht weiter nachgegangen bin:
No BlockingCall processes running currently
Und ein backup wurde dadurch nicht angestoßen.
Die drop-down Liste der Kommandozeile bietet nach Eingabe des "b"s zwar auch das "backup" als Vorschlag an, aber ich bin davon ausgegangen, dass im Gegensatz zum Webfrontend so ein Mechanismus bei Events und Kommandos zwischen Devices nicht implementiert wurde. Schließlich muss der Wert dann ja auch noch ausgewählt werden.
Es sei denn, der Code zu Erkennung eines Kommandos (vor der Weiterleitung an die eigentliche Ausführung) nimmt in jedem Fall einen best-guess (analog type-ahead), falls das Kommando nicht zu 100% erkannt wird.
Daher habe ich das nur als Theorie bezeichnet.
In wieweit so etwas dann sinnvoll oder best practice ist, kann ich nicht beurteilen, denn dazu programmiere ich zu wenig und da will ich meinen Fall hier auch gar nicht in die Waagschale werfen, denn die Ursache lag (sehr wahrscheinlich) ja an dem unvollständig notify.
Wenn du glaubst es kommt durch das notify, dann löse es doch gezielt aus, z.B.:
setreading FunkSchalterP_01_Pwr power 179
Oder mittels trigger...
EDIT: ansonsten (wurde aber ja schon angesprochen) mal nach z.B. einem at (gut scheidet aus, wenn es nicht regelmässig ist) suchen oder auch in einer myUtils nach backup suchen (gut sollte der grep tun) oder irgendwelche "System-Scripte" laufen?
Gruß, Joachim
Prima, dass Du Dein Problem gelöst hast :)
Zitat von: Uef am 18 August 2021, 09:54:32
Es sei denn, der Code zu Erkennung eines Kommandos (vor der Weiterleitung an die eigentliche Ausführung) nimmt in jedem Fall einen best-guess (analog type-ahead), falls das Kommando nicht zu 100% erkannt wird.
So clever ist dieser Mechanismus nicht.
Er nimmt einfach die Länge Eingabe (bei b = 1) und prüft die Namen der in FHEM bekannten Befehle (alphabetisch sortiert) auf Übereinstimmung vom Beginn an auf diese Länge. Konkret wird also der erste Befehl gesucht, der mit b beginnt. Und da kommt dann eben "backup" raus und das wird ausgeführt. Würdest Du "li" eingeben, würde "list" ausgeführt.
Ein simples Gadget, das aber durchaus Tipparbeit (vor allem im Webfrontend oder per telnet) ersparen kann, wenn man weiß, wie man es gezielt einsetzt. In notify oder at o.ä. sollte man es aber besser nicht einsetzen.
Hallo Joachim, marvin78,
so jetzt sind auch die letzten Unklarheiten beseitigt :-):
ich hatte ja auch schon den Tipp von betateilchen (98_backup.pm zu entfernen bzw. umzubennen) umgesetzt; daher gab es kein Backup-Kommando mehr :-[
Und daher also die komische Fehlermeldung.
(war einfach schon zu spät gestern)
Habe jetzt alles wieder hergestellt incl notify (hatte ich schon gelöscht) und gerade nochmal getestet:
- eine Eingabe von "b" löst ein Backup aus
- und das notify triggert entsprechend ebenfalls ein Backup
Also war das notify die auslösende Ursache und und im zweiten Schritt und in Kombination damit das (zumindest für mich) unerwartete Verhalten bei der Eingabe eines unvollständigen Kommandos.
Nochmal Danke für Eure Tipps und Unterstützung !