98_update.pm (Retry bei Verbindungsproblemen)

[dominik]

@Puschel74, klar, nur solange es keine Nebenwirkungen gibt. Deswegen habe ich den Patch auch extra klein gehalten um eventuelle Auswirkungen überschaubar zu halten.
Mich würde freuen, wenn mehr Leute das testen würden um sicher zu gehen dass es auch überall funktioniert.

@Icinger, korrekt. Man müsste nur vorher das Modul updaten und danach läuft es durch.

[Puschel74]

@Puschel74, klar, nur solange es keine Nebenwirkungen gibt. Deswegen habe ich den Patch auch extra klein gehalten um eventuelle Auswirkungen überschaubar zu halten.
Mich würde freuen, wenn mehr Leute das testen würden um sicher zu gehen dass es auch überall funktioniert.

Wenn in Beitrag 1 die 98_update.pm inkl. deines DIFF enthalten ist zieh ich mir die runter und probier sie auf meinem Versuchssystem aus.
Natürlich auf dem System mit dem das letzte update geklappt hat 
Stell sie doch bitte zusätzlich als Datei in den ersten Beitrag - ich hasse copy&paste (damit kann es nur zu Fehler kommen die wir hier nicht brauchen).
Klar könnte ich auch das Diff einarbeiten - aber bei mir klappt das update ja 
Den Test werde ich dann am Mittwoch machen - ich kopier extra eine alte Sicherung ein um zu schauen was passiert.

[dominik]

Steht bereit Puschel74
Siehe 1. Post.

[rudolfkoenig]

Der Patch im ersten Post versucht mit einem primitiven Verfahren das immerhin seit 30 Jahren bewaehrte TCP/IP, was auch selbst retries kennt, zu verbessern. Bevor ich die Symptome mit solch kruden Mitteln ueberdecke, wuerde ich gerne wissen, wo die Probleme eigentlich herkommen.

[Doggiebert]

Ein gebräuchliches Muster in der IT: wir implementieren schon mal eine Lösung für ein Symptom, dessen Ursache noch völlig unklar ist.
Ich hatte noch nie Probleme mit dem Update, und wenn es der Update sporadisch nicht schafft, einzelne kleine Dateien herunterzuladen - lt. Originalpost lustigerweise nur in einem bestimmten Ordner, dann ist irgendwas faul, das man vielleicht mit einem Workaround im update erstmal unsichtbar machen kann, dem man aber auf den Grund gehen sollte. Da stimme ich Rudi zu - bitte nicht solche Lösungen.

[Puschel74]

Danke Rudi - dann brauch ich auch nichts testen 

[dominik]

Ich bin bei euch, dass da eine gründlichere Ursachenforschung notwendig ist, da es vielleicht nicht NUR ein Problem der Internetverbindung ist, sondern eventuell auch noch ZUSÄTZLICH ein anderes Problem besteht. Das Problem einer schlechten Internetverbindung werden wir aber definitiv für den User (leider) nicht lösen können.

Und genau da setze ich an...Ursache: schlechte Internetverbindung in Verbindung mit einer Update Implementierung die keinen Status speichert. Daraus resultiert, dass solche User kein Update durchführen können.

Ich denke emerge, apt-get & co haben schon eine Berechtigung gefunden wieso man Retries bei solchen Updatefunktionalitäten einbaut. Gleiches war auch mein primitiver Ansatz in der Update Logik. Nicht mehr und nicht weniger...ich liefere einfach eine simple (und damit in den Auswirkungen überschaubare) Lösung für ein Problem welche defacto besteht (siehe auch http://forum.fhem.de/index.php?topic=34076.0).

[dev0]

Mag jemand, der das Update Problem hat, testweise mal versuchen die mtu size runterzusetzen und dann das Update noch einmal laufen lassen?
Ich vermute, dass Raspbian dazu folgende Syntax hat (habe keinen Pi im Zugriff):
sudo /sbin/ifconfig eth0 mtu 1000
Kann man nachher wieder mit 1500 zurücksetzen.
Falls ein anderes Interface als eth0 für den Internetzugriff genutzt wird, dann das bitte angeben.

/Uli

(Kopiert von: http://forum.fhem.de/index.php/topic,34076.msg323989.html#msg323989)

[speex]

Hi, also ich habe die mtu size wie beschrieben herunter gesetzt:

Code Auswählen Erweitern

sudo /sbin/ifconfig eth0 mtu 1000

Der update prozess schlägt aber leider wieder fehl, dieselbe fehlermeldung.

Code Auswählen Erweitern

2015-08-18 22:33:11 Global global http://fhem.de/fhemupdate/FHEM/10_HXBDevice.pm: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout

[dev0]

Schade, der Fehler wäre typisch dafür.

[dev0]

Code Auswählen Erweitern

sudo /sbin/ifconfig eth0 mtu 1000

Laut Email Benachrichtigung (vor Edit) hast Du noch einen reboot vor dem Update durchgeführt. Das würde nicht funktionieren, da das ifconfig statement nicht bootfest ist, dazu müsstest du unter /etc/network/interfaces dem Interface ein "mtu 1000" mitgeben. Du hast das Update vor dem reboot getestet und eth0 ist sicher dein benutztes Interface? Wie schon geschrieben, die Problemtik würde sehr gut zu einer falschen mtu size passen.
Könntest Du das bitte noch einmal wiederholen und vor dem Update den Output von "sudo /sbin/ifconfig" (ohne Parameter) und "sudo /sbin/route -n" kopieren und anschiessend posten?

[speex]

Hi,
danke für deine Aufmerksamkeit ich hatte es extra editiert da es ja gerade nicht die beschriebene Vorgehensweise war, sorry dafür.

Code Auswählen Erweitern

root@raspberrypi:~# sudo /sbin/ifconfig eth0 mtu 1000
root@raspberrypi:~# sudo /sbin/ifconfig
eth0      Link encap:Ethernet  Hardware Adresse b8:27:eb:1e:ff:ac 
          inet Adresse:192.168.1.101  Bcast:192.168.1.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1000  Metrik:1
          RX packets:76667 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53111 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:8890511 (8.4 MiB)  TX bytes:3762299 (3.5 MiB)

lo        Link encap:Lokale Schleife 
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:853 errors:0 dropped:0 overruns:0 frame:0
          TX packets:853 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:70426 (68.7 KiB)  TX bytes:70426 (68.7 KiB)

root@raspberrypi:~# sudo /sbin/route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Kein reboot des Systems und update befehl ausgeführt im FHEM backend selber fehler...

[rudolfkoenig]

Was passiert, wenn du in FHEM/HttpUtils.pm Zeile 103, timeout erhoehst, von 4 auf z.Bsp. 15 Sekunden?

[P.A.Trick]

Was passiert, wenn du in FHEM/HttpUtils.pm Zeile 103, timeout erhoehst, von 4 auf z.Bsp. 15 Sekunden?

Ich habe das mal ausprobiert. Der Timeout Wert wird dann durch das Update selbst wieder überschrieben wenn ich das richtig sehe, oder?
Im Gegensatz zu manch anderen bricht bei mir das Update immer bei der folgenden Stelle ab:

Code Auswählen Erweitern

2015.08.19 20:12:44 1: UPD www/images/openautomation/phone_ring_in.svg


Edit: FHEM hängt danach und ich muss den Prozess abschiessen und neu starten!

[rudolfkoenig]

Mit welcher Fehlermeldung bricht es ab?
Wieso haengt FHEM, wenn update abbricht?
Laeuft bei dir update nicht in Background? Wenn nein, wieso nicht?