Ich lasse nachts um 0:30 Uhr per at backup laufen. In der Zeit ist FHEM komplett blockiert, das Log wird erst nach Beendigung weiter geschrieben.
2017.11.28 00:30:00.066 1: NOTE: make sure you have a database backup!
2017.11.28 00:30:00.081 2: Backup with command: tar -chf - "configDB.conf" "./_Inline" "./alexa-fhem" "./certs" "./CHANGED" "./configDB.conf" "./configDB.db" "./configDB.pm" "./contrib" "./db.conf" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.db" "./fhem.pl" "./kindle" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./restoreDir" "./scripts" "./tmp.png" "./unsed" "./unused" "./www" "./ZME_UZB1.bin" |gzip > /media/fhem/backup/FHEM-20171128_003000.tar.gz
2017.11.28 00:53:20.215 1: backup done: FHEM-20171128_003000.tar.gz (925011606 Bytes)
2017.11.28 00:53:20.215 3: backup :
backup done: FHEM-20171128_003000.tar.gz (925011606 Bytes)
2017.11.28 00:53:20.220 1: Perfmon: possible freeze starting at 00:30:00, delay is 1400.22
Aufgefallen ist es mit hauptsächlich, weil meine Z-Wave Zwischenstecker um die Zeit regelmäßig die Verbindung verlieren und wild vor sich hinblinken. Es läuft also in den über 20 Minuten gar nichts. Ein at, daß bei mir minütlich läuft, wird nach dem Backup sooft hintereinander gestartet, wie es eigentlich hätte laufen sollen in der Zeit, hier also 23mal innerhalb von 3 Sekunden.
Läßt sich das irgendwie nicht blockierend machen?
Da sind schon viele drüber gestolpert. ;)
Backup blockiert nur dann nicht, wenn es durch den Update Prozess angestoßen wird und dieser im Hintergrund läuft.
Alternative wäre das FHEM Verzeichnis einfach über ein Shellscript zu sichern.
Was anderes als die Dateien in ein Archiv zu packen macht der Backup Befehl ja sicher auch nicht.
Ok, natürlich könnte ich einfach ein externes Skript per cron laufen lassen.
Aber warum verhält sich backup anders, wenn man es selbst anstößt als wenn es durch ein Update angestoßen wird? Meiner Meinung nach sollte eigentlich alles, was länger braucht, non-blocking laufen.
Zitat von: mahowi am 28 November 2017, 09:24:13
Meiner Meinung nach sollte eigentlich alles, was länger braucht, non-blocking laufen.
Genau, das wäre der Idealzustand. Der Code ist etwas wirr und es gibt einen Unterschied, ob das Backup über FHEMWEB oder Telnet/Command line angestoßen wurde, wenn ich mich recht erinnere. Schreib einen Patch, der das Problem ohne Nebenwirkungen behebt und biete diesen dann dem Maintainer an, wenn es Dich stört.
Ich muß zugeben, ich hab mir den zugehörigen Code noch nicht angesehen. Ich dachte, es gäbe eine Möglichkeit, das Backup im Hintergrund laufen zu lassen, da es beim Update ja auch funktioniert.
Ich mache meine täglichen Backups damit:
http://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/
Und ich meine es ist nicht blockierend.
Klar, ist ja auch ein externes Skript. Es hat ja keinen Einfluß auf FHEM, außer ein paar Readings zu setzen.
Es ging mir hier um den internen Befehl backup. Und der blockiert, wenn man ihn händisch oder per at/notify aufruft, tut dies aber nicht, wenn er beim Update aufgerufen wird.
Dürfte daran liegen, dass update standardmäßig als "updateInBackground" ausgeführt wird.
Wenn dann dort backup aufgerufen wird, ist es Teil des fork-Prozesses, oder?
Ein backup aus der Kommandozeile ist nicht blockierend.
Ok, verhält sich backup je nach Aufruf anders oder liegt es eventuell doch an at?
ZitatIch dachte, es gäbe eine Möglichkeit, das Backup im Hintergrund laufen zu lassen
Wie Du festgestellt hast (und ich schon schrieb) verhält sich das Modul, je nachdem wie es aufgerufen wird, anders. Da kannst Du jetzt viel fragen und diskutieren, dadurch wird es nicht besser. Einarbeiten, besser machen und ggf. Patch einreichen, gut is... Oder?
Ich will ja gar nix schlecht machen oder unnötig diskutieren. Aber es muß ja schließlich einen Grund für das Verhalten geben oder gegeben haben, sonst hätte Rudi es ja nicht extra so eingebaut.
Ich kann ja nix ändern, wovon ich nicht weiß, was der Maintainer sich dabei gedacht hat. Ansonsten bräuchte man vermutlich nur die Zeilen 200 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_backup.pm#L200) und 209 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_backup.pm#L209) bis 223 zu löschen.
Zitat von: mahowi am 28 November 2017, 12:10:52
sonst hätte Rudi es ja nicht extra so eingebaut.
Ich glaube zu wissen, dass Rudi nicht der Autor sondern nur der kommissarische Maintainer ist und es jemand anderes "verbrochen" hat.
Ich hab Martin mal angeschrieben. Laut Source hat er das Modul wohl 2012 geschrieben.
Ich verwalte backup komissarisch, und ich habe es bisher nur "kosmetisch" geaendert, z.Bsp. der Aufruf wird ins Hintergrund verlagert, wenn es aus FHEMWEB direkt aufgerufen wird. Es laeuft auch im Hintergrund, wenn es durch update gestartet wird, der wiederum (als Voreinstellung) im Hintergrund laeuft.
Ich habe es nochmal angepasst: backup wird jetzt mit der "FHEMWEB" Methode im Hintergrund gestartet, wenn nicht bereits im Hintergrund ist, z.Bsp. wg. update.
Danke! :)
Zitat von: rudolfkoenig am 29 November 2017, 23:00:25
Ich habe es nochmal angepasst: backup wird jetzt mit der "FHEMWEB" Methode im Hintergrund gestartet, wenn nicht bereits im Hintergrund ist, z.Bsp. wg. update.
Auch von mir danke, aber nachdem ich auf ein "backup" "Unknown command backup, try help." zurueckbekommen habe,
habe ich "reload 98_backup" versucht und erhalte
Global symbol "$fhemForked" requires explicit package name at ./FHEM/98_backup.pm line 200.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_backup.pm line 201.
Meine Version ist: 98_backup.pm 15522 2017-11-29 21:50:39Z rudolfkoenig
Gruss Helmut
Und die Version von fhem.pl?
Ich habe heute frueh ein update gemacht.
fhem.pl 15522 2017-11-29 21:50:39Z rudolfkoenig
Update: Wegen Deiner Frage habe ich eben ein "shutdown restart" durchgefuehrt. Nun klappt es. Danke.
Gruss Helmut
Zitat von: helmut am 30 November 2017, 12:40:54
Ich habe heute frueh ein update gemacht.
<...>
eben ein "shutdown restart" durchgefuehrt. Nun klappt es.
Genau deshalb wird am Ende von
update auch folgender Hinweis ausgegeben ;)
Zitat
update finished, "shutdown restart" is needed to activate the changes.
Danke, Benni. Da hast Du natuerlich recht. Bis jetzt hatte ich nie Schwierigkeiten damit und die Meldung ist
bei mir schlicht untergegangen, weil ich "updateInBackground" gesetzt habe.
Gruss Helmut
Zitat von: helmut am 30 November 2017, 17:22:29
die Meldung ist
bei mir schlicht untergegangen, weil ich "updateInBackground" gesetzt habe.
Da dabei aber (in FHEMWEB) der EventMonitor aktiviert wird ist die Meldung doch erst recht am Ende des update-Vorgangs sichtbar (s. Screenshot)
Aber ist ja auch Wurscht!
Jetzt weißt du es ja! :D
Grüße Benni.