Moin,
dass es hin und wieder mal beim Update klemmt, ist ja bekannt und dass man sich in Geduld üben soll. Aber dass ich in der letzten Stunde nach gefühlt einem Dutzend Versuche mal 3, mal 10, mal 25 Aktualisierungen schaffe, bevor "Select timeout/error:" kommt (und jedesmal bei einem anderen Modul), finde ich doch nun besonders merkwürdig. So massiv war das hier noch nie.
Mein Internet wuppt wie ne 1 (gerade eben mit 212/12, 9ms).
a) temporäres Problem?
b) kontraproduktiv bei wiederholten Versuchen
b1) unnötige Serverlast
b2) Defekte an meiner Installation?
c) verwirft FHEM die heruntergeladenen Module bei einem solchen Fehler immer komplett und fängt von vorn an? Kann man das umgehen?
Ein Hinweis an prominenter Stelle auf die optimale Verfahrensweise wäre gut. Commandref etwa. Jm2c.
Zitat von: Pfriemler am 14 August 2017, 12:11:47
dass es hin und wieder mal beim Update klemmt, ist ja bekannt
Mir ist das nicht bekannt. Woher stammt die Erkenntnis, dass es hin und wieder Probleme mit dem FHEM Server gibt?
Lief hier problemlos durch:
update
Executing the update the background.
2017.08.14 12:20:25.396 1 :
2017.08.14 12:20:25.397 1 : fhem
2017.08.14 12:20:26.230 1 : RMDIR: ./restoreDir/2017-07-19
2017.08.14 12:20:27.189 1 : UPD ./CHANGED
2017.08.14 12:20:28.309 1 : UPD ./configDB.pm
2017.08.14 12:20:28.462 1 : UPD ./fhem.pl
2017.08.14 12:20:29.411 1 : UPD FHEM/00_FHZ.pm
2017.08.14 12:20:29.598 1 : UPD FHEM/00_HMUARTLGW.pm
2017.08.14 12:20:30.291 1 : UPD FHEM/00_TCM.pm
2017.08.14 12:20:30.618 1 : UPD FHEM/00_THZ.pm
2017.08.14 12:20:31.533 1 : UPD FHEM/00_ZWCUL.pm
2017.08.14 12:20:31.756 1 : UPD FHEM/00_ZWDongle.pm
2017.08.14 12:20:32.018 1 : UPD FHEM/01_FHEMWEB.pm
2017.08.14 12:20:33.069 1 : UPD FHEM/10_CUL_HM.pm
2017.08.14 12:20:36.894 1 : UPD FHEM/10_FS20.pm
2017.08.14 12:20:37.190 1 : UPD FHEM/10_IT.pm
2017.08.14 12:20:37.747 1 : UPD FHEM/10_ZWave.pm
2017.08.14 12:20:39.568 1 : UPD FHEM/11_FHT.pm
2017.08.14 12:20:39.797 1 : UPD FHEM/11_FHT8V.pm
2017.08.14 12:20:40.277 1 : UPD FHEM/12_HMS.pm
2017.08.14 12:20:40.459 1 : UPD FHEM/13_KS300.pm
2017.08.14 12:20:40.573 1 : UPD FHEM/14_CUL_TCM97001.pm
2017.08.14 12:20:40.979 1 : UPD FHEM/14_CUL_TX.pm
2017.08.14 12:20:41.177 1 : UPD FHEM/14_CUL_WS.pm
2017.08.14 12:20:41.293 1 : UPD FHEM/15_CUL_EM.pm
2017.08.14 12:20:41.480 1 : UPD FHEM/16_CUL_RFR.pm
2017.08.14 12:20:41.559 1 : UPD FHEM/18_CUL_HOERMANN.pm
2017.08.14 12:20:41.604 1 : UPD FHEM/21_OWLCD.pm
2017.08.14 12:20:42.054 1 : UPD FHEM/21_OWMULTI.pm
2017.08.14 12:20:42.499 1 : UPD FHEM/21_OWSWITCH.pm
2017.08.14 12:20:42.941 1 : UPD FHEM/22_HOMEMODE.pm
2017.08.14 12:20:44.260 1 : UPD FHEM/31_Nello.pm
2017.08.14 12:20:44.376 1 : UPD FHEM/33_readingsChange.pm
2017.08.14 12:20:44.419 1 : update: skipping FHEM/34_ESPEasy.pm, matches exclude_from_update
2017.08.14 12:20:44.420 1 : UPD FHEM/36_EleroDrive.pm
2017.08.14 12:20:44.740 1 : UPD FHEM/36_EleroStick.pm
2017.08.14 12:20:44.890 1 : UPD FHEM/36_EleroSwitch.pm
2017.08.14 12:20:45.042 1 : UPD FHEM/37_Spotify.pm
2017.08.14 12:20:45.589 1 : UPD FHEM/42_SYSMON.pm
2017.08.14 12:20:46.431 1 : UPD FHEM/49_SSCam.pm
2017.08.14 12:20:47.680 1 : UPD FHEM/50_TelegramBot.pm
2017.08.14 12:20:48.524 1 : UPD FHEM/57_Calendar.pm
2017.08.14 12:20:49.221 1 : UPD FHEM/61_EMWZ.pm
2017.08.14 12:20:49.473 1 : UPD FHEM/62_EMEM.pm
2017.08.14 12:20:49.516 1 : UPD FHEM/70_BRAVIA.pm
2017.08.14 12:20:50.067 1 : UPD FHEM/70_NEUTRINO.pm
2017.08.14 12:20:50.327 1 : UPD FHEM/70_PIONEERAVR.pm
2017.08.14 12:20:51.058 1 : UPD FHEM/70_WINCONNECT.pm
2017.08.14 12:20:51.176 1 : UPD FHEM/72_FB_CALLMONITOR.pm
2017.08.14 12:20:51.441 1 : UPD FHEM/73_AMADCommBridge.pm
2017.08.14 12:20:51.773 1 : UPD FHEM/74_AMADDevice.pm
2017.08.14 12:20:52.215 1 : UPD FHEM/90_at.pm
2017.08.14 12:20:52.332 1 : UPD FHEM/91_eventTypes.pm
2017.08.14 12:20:52.374 1 : UPD FHEM/91_notify.pm
2017.08.14 12:20:53.073 1 : UPD FHEM/91_sequence.pm
2017.08.14 12:20:53.185 1 : UPD FHEM/91_watchdog.pm
2017.08.14 12:20:53.760 1 : UPD FHEM/92_FileLog.pm
2017.08.14 12:20:54.306 1 : UPD FHEM/92_SingleFileLog.pm
2017.08.14 12:20:54.492 1 : UPD FHEM/93_DbLog.pm
2017.08.14 12:20:56.239 1 : UPD FHEM/93_FHEM2FHEM.pm
2017.08.14 12:20:56.318 1 : UPD FHEM/93_PWMR.pm
2017.08.14 12:20:56.546 1 : UPD FHEM/94_PWM.pm
2017.08.14 12:20:56.809 1 : UPD FHEM/95_holiday.pm
2017.08.14 12:20:56.887 1 : UPD FHEM/96_allowed.pm
2017.08.14 12:20:56.967 1 : UPD FHEM/98_BOSEST.pm
2017.08.14 12:20:57.342 1 : UPD FHEM/98_DOIF.pm
2017.08.14 12:20:58.621 1 : UPD FHEM/98_DOIFtools.pm
2017.08.14 12:20:59.276 1 : UPD FHEM/98_GOOGLECAST.pm
2017.08.14 12:20:59.395 1 : UPD FHEM/98_SVG.pm
2017.08.14 12:21:00.015 1 : UPD FHEM/98_cmdalias.pm
2017.08.14 12:21:00.225 1 : UPD FHEM/98_fheminfo.pm
2017.08.14 12:21:00.374 1 : UPD FHEM/98_help.pm
2017.08.14 12:21:00.522 1 : UPD FHEM/98_structure.pm
2017.08.14 12:21:00.715 1 : UPD FHEM/98_weblink.pm
2017.08.14 12:21:00.757 1 : UPD FHEM/99_SUNRISE_EL.pm
2017.08.14 12:21:00.873 1 : UPD FHEM/HMConfig.pm
2017.08.14 12:21:02.053 1 : UPD FHEM/TcpServerUtils.pm
2017.08.14 12:21:02.316 1 : UPD FHEM/lib/74_AMADautomagicFlowset_4.0.3.xml
2017.08.14 12:21:04.139 1 : UPD docs/commandref_frame.html
2017.08.14 12:21:04.585 1 : UPD docs/commandref_frame_DE.html
2017.08.14 12:21:05.270 1 : UPD www/images/fhemSVG/HutschIcon3.svg
2017.08.14 12:21:05.611 1 : UPD www/pgm2/fhemweb.js
2017.08.14 12:21:05.918 1 : saving fhem-dev.cfg
2017.08.14 12:21:05.919 1 : saving ./log/fhem.save
2017.08.14 12:21:05.920 1 :
2017.08.14 12:21:05.920 1 : New entries in the CHANGED file:
2017.08.14 12:21:05.921 1 : - feature: 34_ESPEasy: reject non local IPs wo/ basic auth
2017.08.14 12:21:05.922 1 : - bugfix: 50_TelegramBot: delayed retry & rename (#msg668108)
2017.08.14 12:21:05.923 1 : - changed: 70_BRAVIA: renamed reading/internal modelName to model
2017.08.14 12:21:05.924 1 : - new: 98_GOOGLECAST: first release, read commandref for requirements
2017.08.14 12:21:05.925 1 : - changed: 74_AMADautomagicFlowset_4.0.3.xml: workaround for better auto
2017.08.14 12:21:05.926 1 : flowsetupdate
2017.08.14 12:21:05.926 1 : - feature: 74_AMADDevice: 4.0.5 - Support für NFC and scanning NFC TagId
2017.08.14 12:21:05.927 1 : - bugfix: 74_AMADautomagicFlowset_4.0.2.xml: fix openApp Trigger
2017.08.14 12:21:05.928 1 : - bugfix: 31_Nello: fixed device ID detection
2017.08.14 12:21:05.929 1 : - feature: 93_DbLog: V2.22.1, new attribute "suppressAddLogV3"
2017.08.14 12:21:05.930 1 : - feature: 49_SSCam: V2.6.1, new commands snapGallery, createSnapGallery and
2017.08.14 12:21:05.931 1 : corresponding attributes
2017.08.14 12:21:05.932 1 : - feature: 34_ESPEasy.pm: plugin neopixelfx/nfx added (Forum #73949)
2017.08.14 12:21:05.933 1 : - new: 31_Nello: first release
2017.08.14 12:21:05.934 1 : - feature: 01_FHEMWEB.pm: add webCmdLabel (Forum #72581)
2017.08.14 12:21:05.935 1 : - changed: fhem.pl: search cmds via lowercase/abbrev in modules (Forum #75007)
2017.08.14 12:21:05.936 1 : - changed: 14_CUL_TCM97001: Add rain/wind Sensor
2017.08.14 12:21:05.936 1 : - changed: 10_IT: Add FreeTec update documentation
2017.08.14 12:21:05.937 1 : - changed: configDB: store files base64 encoded, Forum:#74302
2017.08.14 12:21:05.938 1 : - bugfix: 93_DbLog, back to V2.22.0, Forum:#75039
2017.08.14 12:21:05.939 1 : - bugfix: 93_DbLog, V2.22.1, Forum:#74690, warning unitialized value
2017.08.14 12:21:05.939 1 : - feature: 70_WINCONNECT: [WinWebGUI] - Fenster verstecken
2017.08.14 12:21:05.940 1 : - feature: 57_Calendar: added attribute cutoffOlderThan (forum #74481)
2017.08.14 12:21:05.941 1 : - feature: fhem.pl: add -d option for debugging (Forum #74774)
2017.08.14 12:21:05.941 1 : - bugfix: 74_AMADDevice: fix decode_utf8 call in eval
2017.08.14 12:21:05.942 1 : - feature: 57_Calendar: reduce memory footprint (forum #74481)
2017.08.14 12:21:05.942 1 : ... rest of lines skipped.
2017.08.14 12:21:05.943 1 :
2017.08.14 12:21:05.944 1 :
2017.08.14 12:21:05.945 1 : fhemtabletui
2017.08.14 12:21:06.328 1 : UPD www/tablet/css/fhem-tablet-ui.css
2017.08.14 12:21:06.621 1 : UPD www/tablet/css/fhem-tablet-ui.min.css
2017.08.14 12:21:06.861 1 : UPD www/tablet/js/fhem-tablet-ui.js
2017.08.14 12:21:07.162 1 : UPD www/tablet/js/fhem-tablet-ui.min.js
2017.08.14 12:21:07.387 1 : UPD www/tablet/js/widget_famultibutton.js
2017.08.14 12:21:07.578 1 : UPD www/tablet/js/widget_pagebutton.js
2017.08.14 12:21:07.755 1 : saving fhem-dev.cfg
2017.08.14 12:21:07.756 1 : saving ./log/fhem.save
2017.08.14 12:21:07.759 1 :
2017.08.14 12:21:07.760 1 : New entries in the CHANGED file:
2017.08.14 12:21:07.761 1 : FHEM Tablet UI last change:
2017.08.14 12:21:07.762 1 : 2017-08-04
2017.08.14 12:21:07.762 1 : - Support data-get-on from reading
2017.08.14 12:21:07.763 1 :
2017.08.14 12:21:08.150 1 : Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
Mal bei Seite
ZitatExecuting the update the background.
Das ist aber gutes Englisch....
Zitat von: dev0 am 14 August 2017, 12:29:44
Mir ist das nicht bekannt. Woher stammt die Erkenntnis, dass es hin und wieder Probleme mit dem FHEM Server gibt?
Ich habe nicht gesagt dass ein Server-Problem IST. Ich habe es nur vermutet.
SuFu nach "Select timeout/error:" liefert diverse Treffer hier bei "Anfängerfragen", aber keine Lösung außer "immer wieder probieren".
Schön dass es bei Dir läuft. Bei mir habe ich es erstmals bis hierher geschafft, immerhin.
2017.08.14 14:26:47 1 : UPD FHEM/99_SUNRISE_EL.pm
2017.08.14 14:26:51 1 : http://fhem.de/fhemupdate/FHEM/99_SUNRISE_EL.pm: Select timeout/error: Die Liste der Module wird zügig gelistet, aber dann bleibt es einfach bei einem beliebigen Modul hängen.
Mal ganz davon abgesehen, dass eine solche Überempfindlichkeit gegen ausbleibende Serverantworten in vier Sekunden ... ähm ... also da reicht ja ein gut ausgelasteter Knoten irgendwo in Deutschland über den die Daten müssen. Solide ist was anderes. Aber vermutlich bin ich da überempfindlich.
attr global updateInBackground scheint auch ignoriert zu werden, bekomme nichts diesbezügliches angezeigt.
Zitat von: Pfriemler am 14 August 2017, 14:31:41
Ich habe es nur vermutet.
Die Vermutung ist falsch. FHEM-Server läuft (nicht nur heute ;) ) störungsfrei; auch der Hoster meldet keine Störungen. Darum tippe ich auf Probleme mit Deiner Infrastruktur.
ZitatSuFu nach "Select timeout/error:" liefert diverse Treffer hier bei "Anfängerfragen", aber keine Lösung außer "immer wieder probieren".
In Anfängerfragen lesen nicht alle Maintainer mit. Darum evtl das passendere Unterforum suchen (https://forum.fhem.de/index.php/topic,13092.0.html). Dort sind auch etwaige Verbesserungsvorschläge mit besserer Aussicht auf Erfolg unterzubringen.
Zitatverwirft FHEM die heruntergeladenen Module bei einem solchen Fehler immer komplett und fängt von vorn an?
Ja.
ZitatKann man das umgehen?
Einzelupdate der Module (unschön) oder (bitte nicht schimpfen :) ) Problem suchen.
Gruß, Christian
Ah, danke!
Gut:
a) es lohnt sich also den Beelzebub bei mir zu suchen, weil es kein generelles Problem gibt. Solche Info erspart mir möglicherweise viel unnütze Arbeit.
Infrastrukturell habe ich eher keine Probleme bisher. Netzwerk und Internet sind völlig unauffällig gerade.
b) Die Maintainer wollte ich gerade absichtlich nicht wecken. Den Vorschlag dort zu stellen werde ich erwägen. Es war zunächst mehr eine Frage.
c) Einzelupdate bei ...zig Modulen ... ? hm. Is ja immer ein anderes wo es hängt.
Shutdown und restart von FHEM: Ich krieg noch ein Push dass der Server wieder läuft, aber er ist nicht jetzt mehr erreichbar. Jetzt freue ich mich aber :(
Also das volle Programm... Ich bin dann mal weg...
Ich kenne immer nur die Fälle, wo es auf dem LOKALEN FHEM-Server "klemmt". Ich habe auch mal ein ähnliches Problem gehabt, wo es auch definitiv an meiner Infrastruktur lag. Irgendwann kommt es zum timeout und wenn man länger kein Update gemacht hat, ist die Modulliste auch recht lang.
ZitatEinzelupdate bei ...zig Modulen ... ?
Du kannst ja über regex reduzieren.
Ggfs. den FHEM-Server direkt an den Inet-Router hängen. Klappt das auch nicht, würd ich mir mit top mal angucken, was Dein FHEM-Server da so treibt.
Grüße Markus
.
Auch wenn ich "Einzelupdate" erwähnt habe, bitte vorsichtig damit:
- löst nicht das eigentliche Problem
- update macht bei fehlgeschlagenen Updates nicht umsonst die komplette Rückabwicklung (-> es gibt unter Umständen Abhängigkeiten zwischen Dateien/Modulen eines updates). Wenn man bei Einzelupdate nicht aufpasst, ist eventuell das nächste Problem vorprogrammiert.
So, FHEM lief, aber konnte FHEMWEB nicht laden. Über Telnet hatte ich Zugriff. Dort klappte sogar das Update auf Anhieb. Nach dem Neustart gar kein FHEM. "/etc/init.d/fhem status" liefert "segmentation fault".
Also neue Karte aus dem Schrank, zwei Monate altes Image drauf, FHEM Backup von gestern, läuft.
"update": erst im zweiten Versuch durchgegangen.
Nun habe ich aber immer noch keine Idee, warum es klemmt(e). Prinzipiell sollte der Raspi nicht überlastet sein, das CPU-Monitoring und RAM-Auslastung sind völlig normal. top sagt aktuell:
top - 16:45:13 up 18 min, 1 user, load average: 0.17, 0.17, 0.19
Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.5 us, 1.2 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
KiB Mem: 948140 total, 227652 used, 720488 free, 15660 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 97636 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1744 fhem 20 0 66400 61696 6444 S 5.9 6.5 1:45.66 perl
3185 pi 20 0 5248 2512 2104 R 1.0 0.3 0:00.42 top
201 root 20 0 0 0 0 S 0.7 0.0 0:03.02 kworker/u8:3
3169 pi 20 0 12204 3516 2844 S 0.7 0.4 0:00.11 sshd
3248 fhem 20 0 2088 376 300 S 0.7 0.0 0:00.02 ping
4 root 20 0 0 0 0 S 0.3 0.0 0:00.65 kworker/0:0
7 root 20 0 0 0 0 S 0.3 0.0 0:01.27 rcu_sched
1725 root 20 0 0 0 0 S 0.3 0.0 0:01.43 kworker/u8:0
3244 fhem 20 0 2088 384 308 S 0.3 0.0 0:00.02 ping
1 root 20 0 22896 3920 2732 S 0.0 0.4 0:04.15 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.47 ksoftirqd/0... (Rest entfernt)
und danke an krikan - dass das mit einem Einzelupdate neue Probleme hervorrufen kann, schwante mir schon. Mir war wichtig, dass FHEM durch wiederholte Updateversuche nicht durcheinander kommt. Trotzdem bleibe ich dabei, dass FHEM den zu updatenden Modulen durchaus mehr Zeit geben könnte. Offenbar dauert das Ziehen mancher Module durchaus länger (was kein Problem darstellt), aber es könnte im Fehlerfall ruhig wenigstens ein paar Mal automatisch wiederholt werden. Wie es da weitergehen könnte, ist aufgezeigt.
Daher hier für mich gelöst, danke an alle.
Zitatdass das mit einem Einzelupdate neue Probleme hervorrufen kann, schwante mir schon.
Jein. Man muss natürlich ALLE updates über "Einzelupdates" machen. Also über regex reduzieren UND als allerletzten dann zur Sicherheit noch ein update ohne regex. Danach dann erst ein shutdown restart. Problematischer sehe ich bei der Vorgehensweise eher, dass mit jedem update ein backup gemacht wird und meines Wissens gibt es standardmässig nur 3. Man sollte also vorher sicherheitshalber das FHEM-Verzeichnis sichern ;)
ZitatNun habe ich aber immer noch keine Idee, warum es klemmt(e).
Die SD-Karte ?
Zitat von: KölnSolar am 14 August 2017, 18:31:03
... man muss natürlich ALLE updates über "Einzelupdates" machen. ... Danach dann erst ein shutdown restart.
Da fiel der Groschen pfennigweis. Aber ja.
Die SD-Karte hatte auf jeden Fall einen Schuss. Der ganze Raspi hat sich beim nächtlichen Cronjob aufgehangen, genau um vier. Allerdings startete er nach einem Reset völlig problemfrei und lief 2 Stunden fehlerfrei, ich konnte sogar noch eine ganz aktuelle Sicherung ziehen. Dann war es Zeit für das wohlweislich nach den Urlaub gelegte Update und die Probleme begannen.
Optisch unterschied sich das Update vorher und nachher in nichts vom gewohnten Ablauf. Auch das erste Hängenbleiben mit der neuen Karte ist vielleicht mehr als ein Zufall. Abbrüche in den Updates hatte ich bislang praktisch ausschließlich dadurch, dass ich versehentlich manuell geänderte Dateien nicht wieder mit FHEM-Rechten bestückt habe und FHEM daher die "Hände gebunden waren". Die beschriebenen timeouts waren mir eigentlich völlig neu, bzw. ich hatte sie so selten, dass ich sie bislang nie zur Kenntnis genommen habe.
Und dann noch der Punkt, dass das erste per Telnet angestoßene Update, noch mit der alten Karte!, erfolgreich war. Das spricht eher für irgendein internes Problem, aber genausowenig für einen primären SD-Karten-Fehler. Möglich dass der Karte die Sektoren ausgingen und etliche der Updates dann fehlerhaft auf der Karte landeten. Bei einem früheren Fehler hatte es mir mal eine spezielle Config zerlegt, in der ziemlich viele Zeichen nur einzelne Bitfehler hatten. Ich check das noch interessehalber.
"Segmentation Fault" spricht aber deutlich für ein korruptes Filesystem, dann höchstwahrscheinlich für eine defekte SD-Karte.