- √ - Wiregate spinnt seit PL30

[StefanW]

Nun,

Für mich verdichtet sich das Bild, dass hier irgendwie die TU-UART eine entscheidende Rolle spielt. Jetzt geht alles wieder und ich lasse den KNX mal laufen um zu sehen, ob ich in 8h wieder keine Charts mehr bekomme.

also, ich halte es für völlig ausgeschlossen, dass dies auch nur am Rande etwas mit den in PL30/PL31 gemachten Änderungen zu tun hat. Weil die einzige Softwarekomponente für die Kommunikation mit dem KNX ist der eibd und der wurde zuletzt vor sechs Monaten angefasst und das auch nur minimal.

Mit Patchlevel PL30/31 wurde nur das OFWS verbessert und der wiregated.pl verändert. Die wesentlichen Probleme auf einigen Installationen rühren aus der Veränderung am wiregated.pl her und bedingen durch einen (so wie es im Moment aussieht) Fehler des Perl-Interpreters ein Anhalten der Ausführung des eigentlich richtigen Codes in einer der Komponenten darin. Das betrifft dann aber auch "nur" Schreiben in die RRDs und an den KNX (was allerdings heftig ist).

Hinsichtlich der von Dir geschilderten Problematik muss es eine andere Ursache geben die mit an Sicherheit grenzender Wahrscheinlichkeit gar nichts mit PL30/31 zu tun hat.

PS: Makki ist derzeit unter Dampf, daher müsst ihr hier nur mit mir vorlieb nehmen.

Stefan

[StefanW]

Hallo,

Seit Update auf PL30 kann ich mit mobilen Browsern (iPad2, HTC Wildfire, Samsung Galaxy S) nicht mehr auf die Weboberflächen (Webmin, CometVisu) des Wiregate zugreifen.

auch dies hat sehr vermutlich nichts mit PL30/31 zu tun, da diese Komponente nicht betroffen ist.

Es hat sich bei einem anderen Kunden aber gezeigt, dass neben dem lighty auch der Apache gestartet wurde und daher der Zugriff auf den Webmin gestört war, dies ist aber auch keine direkte Folge von PL30/31 sondern eine des damit empfohlenen Restarts (wäre also schon vor PL30/31 bei einem kompletten Restart aufgetreten). Gibt es einen separaten Thread dafür.

Dass Du mit dem normalen Browser drauf kommst, spricht allerdings dagegen. Ich würde das eher in einem separaten Thread behandel, weil es mit dieser Diskussion sehr vermutlich nichts zu tun hat.

merci

Stefan

[alexbeer]

Hallo Stefan, glaub ich gerne.
Habe nen neuen Thread eröffnet: https://knx-user-forum.de/wiregate/1...tml#post226850

P.S. Analyse etc eurerseits reicht mir vollkommen in der kommenden Woche

[makki]

Also zu jeglichen Sticheleien werde ich auch nichts mehr sagen (sondern eher Threads zumachen!), das ist mit Tante Google ausreichend beantwortet.. Punkt.

Wir haben ein Problem, ja, das ist bekannt, das wurde eingeräumt und es wird alsbald möglich ein Update erfolgen (das betrifft nach aktuellem Kenntnisstand aber nur wenige "power-user", die werden versorgt oder sollten einfach besser auf PL32 warten)
Das Problem von alexbeer werd ich mir dann auch ansehen, (neuer Thread=gut) aber das hat 100% sicher beileibe nicht mit PLxx zu tun tun, weil erstens wurde da seit Jahren nichts geändert und zweitens ist dem echt wurscht, ob da ein PC oder ein iPad zugreift.. (auch wenn ich berechtigt in verdacht stünde, dem i* ne Rote Lampe zu zeigen, könnte sein, ist aber nicht so )

Makki

[nobillings]

Hi,

ich weiss ja ihr seid schwer mit dem PL30 Problemen beschäftigt, aber vielleicht kann diese Beobachtung ja zur Fehlereingrenzung beitragen?

Was mir aufgefallen ist folgendes:
Im Plugin Log sehe ich das bestimmte Werte ins RRD geschrieben, so wie es sein sollte.

2012-04-30 22:22:39.449,rrd_graph_FBH.pl,RRD E0_WohnenN_FBH_Stellgroesse aktualisiert
2012-04-30 22:27:40.002,rrd_graph_FBH.pl,RRD E0_WohnenS_FBH_Stellgroesse aktualisiert
2012-04-30 22:27:40.005,rrd_graph_FBH.pl,RRD E0_WohnenN_FBH_Stellgroesse aktualisiert
2012-04-30 22:32:40.130,rrd_graph_FBH.pl,RRD E0_WohnenS_FBH_Stellgroesse aktualisiert
2012-04-30 22:32:40.136,rrd_graph_FBH.pl,RRD E0_WohnenN_FBH_Stellgroesse aktualisiert
2012-04-30 22:37:41.019,rrd_graph_FBH.pl,RRD E0_WohnenS_FBH_Stellgroesse aktualisiert
2012-04-30 22:37:41.023,rrd_graph_FBH.pl,RRD E0_WohnenN_FBH_Stellgroesse aktualisiert
2012-04-30 22:47:43.418,rrd_graph_FBH.pl,RRD E0_WohnenS_FBH_Stellgroesse aktualisiert
2012-04-30 22:47:43.421,rrd_graph_FBH.pl,RRD E0_WohnenN_FBH_Stellgroesse aktualisiert

Ein ls auf das RRD Verzeichnis zeigt mir aber an, dass die letzte Änderung am RRD schon mehrere Wochen her ist.

root@wiregate286:/var/www/rrd# ls -l E0_Wohnen*
-rw-rw-rw- 1 root root 382240 14. Apr 00:07 E0_WohnenN_FBH_Stellgroesse.rrd
-rw-rw-rw- 1 root root 382240 14. Apr 00:07 E0_WohnenS_FBH_Stellgroesse.rrd

Das beobachte ich bei Werten aus verschiedenen Plugins, die laut Plugin-Seite auch immer brav ausgeführt werden.
Oder ist das eine falsche Fährte?

VG

PS: Darf ich fragen, ob schon jemand ins WG286 geschaut hat und ich das Wartungs-VPN abschalten kann? Gemerkt habe ich jedoch nichts. Das kann aber auch an meiner Unfähigkeit liegen...

[swiss]

Als bei mir die lücke eintrat, wurden folgende Zeilen in's daemon.log geschrieben:

Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_daemon.c:(143) Entered background mode, quitting.
Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_usb_msg.c:(333) Opened USB DS9490 bus master at 2:6.
Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_usb_cycle.c:(191) Set DS9490 2:6 unique id to 81 5B 88 2D 00 00 00 64
Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_usb_msg.c:(333) Opened USB DS9490 bus master at 2:5.
Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_usb_cycle.c:(191) Set DS9490 2:5 unique id to 81 52 9A 2D 00 00 00 0D
Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_usb_msg.c:(333) Opened USB DS9490 bus master at 2:4.
Apr 28 11:53:32 wiregate314 OWFS[23689]: DEFAULT: ow_usb_cycle.c:(191) Set DS9490 2:4 unique id to 81 61 E8 2D 00 00 00 57
Apr 28 11:54:24 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 11:54:24 wiregate314 monit[2791]: 'owserver' process PID changed to 23689
Apr 28 11:55:25 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 11:55:25 wiregate314 monit[2791]: 'owserver' PID has not changed

und kurz bevor das protokollieren wieder einsetzte, wurde folgendes gelogt:

Apr 28 20:57:35 wiregate314 monit[2791]: 'wiregated.pl' total mem amount of 131088kB matches resource limit [total mem amount>131072kB]
Apr 28 20:57:35 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 20:58:35 wiregate314 monit[2791]: 'wiregated.pl' total mem amount of 131128kB matches resource limit [total mem amount>131072kB]
Apr 28 20:58:35 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 20:59:35 wiregate314 monit[2791]: 'wiregated.pl' total mem amount of 131172kB matches resource limit [total mem amount>131072kB]
Apr 28 20:59:35 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 21:00:35 wiregate314 monit[2791]: 'wiregated.pl' total mem amount of 131212kB matches resource limit [total mem amount>131072kB]
Apr 28 21:00:35 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 21:01:35 wiregate314 monit[2791]: 'wiregated.pl' total mem amount of 131260kB matches resource limit [total mem amount>131072kB]
Apr 28 21:01:35 wiregate314 monit[2791]: 'wiregated.pl' trying to restart
Apr 28 21:01:35 wiregate314 monit[2791]: 'wiregated.pl' stop: /etc/init.d/wiregated
Apr 28 21:01:36 wiregate314 monit[2791]: 'wiregated.pl' start: /etc/init.d/wiregated
Apr 28 21:01:36 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_daemon.c:(143) Entered background mode, quitting.
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_usb_msg.c:(333) Opened USB DS9490 bus master at 2:6.
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_usb_cycle.c:(191) Set DS9490 2:6 unique id to 81 5B 88 2D 00 00 00 64
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_usb_msg.c:(333) Opened USB DS9490 bus master at 2:5.
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_usb_cycle.c:(191) Set DS9490 2:5 unique id to 81 52 9A 2D 00 00 00 0D
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_usb_msg.c:(333) Opened USB DS9490 bus master at 2:4.
Apr 28 21:01:44 wiregate314 OWFS[4733]: DEFAULT: ow_usb_cycle.c:(191) Set DS9490 2:4 unique id to 81 61 E8 2D 00 00 00 57
Apr 28 21:02:36 wiregate314 monit[2791]: 'wiregated.pl' resource passed
Apr 28 21:02:36 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 21:02:36 wiregate314 monit[2791]: 'owserver' process PID changed to 4733
Apr 28 21:03:36 wiregate314 monit[2791]: 'bootfs' space usage 95.3% matches resource limit [space usage>95.0%]
Apr 28 21:03:36 wiregate314 monit[2791]: 'owserver' PID has not changed

Es scheint, als ob das WG für ca. 9 Stunden die 1-Wire BUS Master verloren hat. Die RRD's die über ein Plugin mit Werte vom KNX befüllt werden haben keine Lücken. Vieleicht hilft dass ja weiter.

Lg Patrik

[makki]

@nobillings: also das Plugin rrd_graph_FBH.pl ist mal IMHO reichlich Wirr (sollte ich das kennen? kann sein, vielleicht.. gefallen hats mir dann aber nicht)

Das ist totaler Overkill, beim eintreffen eines jeden Telegramms es nochmal zu lesen und dann das RRDs zu aktualisieren
Für die Syntax ist es mir grad echt zu spät, das zu analysieren, Arrays of hashes kann man machen -> muss man aber nicht..
Ich stehe auf die einfache Variante, ohne 27 verschiedene Klammern, 10 Zeilen für 10 Werte, fertig, das funktioniert nach wie vor ziemlich sicher..

@swiss: Das Thema ist bekannt und behoben, erfordert wegen recht massiver Änderungen aber noch weitere Tests. Was hier passiert ist, das der Prozess quasi stehenbleibt und "dank" eines Speicherlecks in Plugins doch irgendwann restarted wird

Makki

[nobillings]

Das Plugin habe ich mal hier Forum gefunden und dann nur mit Adressen und Namen gefüllt.
Bin gerade dabei, das vorgeschlagene anzupassen.

Aber sollte der Plugin-Code die Ursache für dieses komische Verhalten sein?

Das andere Plugin für die Temperaturen der Wärmepumpe (ist der gleiche Code) hat auch Lücken aber komischerweise sind die Lücken unterschiedlich.

VG
ImageUploadedByTapatalk1335902146.976356.jpg

[Sandman60]

Nu steht er...

So, heute war es leider mal wieder soweit und die RTR's zeigen keine Zeit mehr an. Wartungs-VPN ist offen (WG270). Soweit ich sehen konnte ist der wiregated schon am Montag abgeflogen. Bitte um kurze Rückmeldung, falls Ihr das Fehlerbild kennt bzw. keinen Zusammenhang zum PL30 Update seht, dann starte ich neu.
Wie gesagt, nachdem ich eigentlich keine RRD's und Co. verwende und sonst alles ruhig vor sich hin blubbert, merke ich den Ausstieg leider erst immer an der nicht mehr vorhandenen UhrZeit an den RTR's
VG, Oliver

[makki]

@Sandman: sorry erst jetzt gesehen. Das war das bekannte PL30-Problem, wir sind in den letzten Zügen mit den Tests für einen endgültigen Fix..

Makki

[Klausi]

Hallo,

habe beim Release von PL 30 dieses auch installiert und konnte bisher keine Probleme feststellen. Beim Updatevorgang habe ich mir die Ausgaben angeschaut und bin nicht so ganz sicher, ob da alles glatt gelaufen ist. Vielleicht kann mal jemand drüberschauen?
Ich habe die Stellen, die mir komisch vorkommen mal fett makiert:

Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
eibd-clients eibd-config-wg libeibclient-dev libeibclient0 libow-perl
libowfs27 libownet-perl librrd4 linknx owfs-fuse owfs-httpd owfs-server
webmin-wiregate wg-patch wiregated
15 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 5536kB of archives.
After this operation, 11.5MB of additional disk space will be used.
Get:1 Index of /apache2-default wiregate-0.1/main webmin-wiregate 0.3-43 [1356kB]
Get:2 Index of /apache2-default wiregate-0.1/main eibd-config-wg 0.2-12 [4218B]
Get:3 Index of /apache2-default wiregate-0.1/main libeibclient-dev 0.0.4+nmu18 [55.0kB]
Get:4 Index of /apache2-default wiregate-0.1/main libeibclient0 0.0.4+nmu18 [18.2kB]
Get:5 Index of /apache2-default wiregate-0.1/main libowfs27 2.8p14-2+nmu1 [278kB]
Get:6 Index of /apache2-default wiregate-0.1/main owfs-server 2.8p14-2+nmu1 [91.8kB]
Get:7 Index of /apache2-default wiregate-0.1/main eibd-clients 0.0.4+nmu18 [67.9kB]
Get:8 Index of /apache2-default wiregate-0.1/main wiregated 0.9-45 [31.6kB]
Get:9 Index of /apache2-default wiregate-0.1/main wg-patch 0.0.30-2 [12.9kB]
Get:10 Index of /apache2-default wiregate-0.1/main librrd4 1.3.1-4+nmu2 [238kB]
Get:11 Index of /apache2-default wiregate-0.1/main libow-perl 2.8p14-2+nmu1 [17.6kB]
Get:12 Index of /apache2-default wiregate-0.1/main libownet-perl 2.8p14-2+nmu1 [19.3kB]
Get:13 Index of /apache2-default wiregate-0.1/main linknx 0.0.1.30-1 [3307kB]
Get:14 Index of /apache2-default wiregate-0.1/main owfs-fuse 2.8p14-2+nmu1 [18.9kB]
Get:15 Index of /apache2-default wiregate-0.1/main owfs-httpd 2.8p14-2+nmu1 [19.5kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 5536kB in 1min12s (76.6kB/s)
(Reading database ... 53371 files and directories currently installed.)
Preparing to replace webmin-wiregate 0.3-41 (using .../webmin-wiregate_0.3-43_all.deb) ...
Unpacking replacement webmin-wiregate ...
Preparing to replace eibd-config-wg 0.2-11 (using .../eibd-config-wg_0.2-12_all.deb) ...
Unpacking replacement eibd-config-wg ...
Preparing to replace libeibclient-dev 0.0.4+nmu16 (using .../libeibclient-dev_0.0.4+nmu18_i386.deb)
...
Unpacking replacement libeibclient-dev ...
Preparing to replace libeibclient0 0.0.4+nmu16 (using .../libeibclient0_0.0.4+nmu18_i386.deb) ...
Unpacking replacement libeibclient0 ...
Preparing to replace libowfs27 2.8p2 (using .../libowfs27_2.8p14-2+nmu1_i386.deb) ...
Unpacking replacement libowfs27 ...
Preparing to replace owfs-server 2.8p2 (using .../owfs-server_2.8p14-2+nmu1_i386.deb) ...
Unpacking replacement owfs-server ...
Preparing to replace eibd-clients 0.0.4+nmu17 (using .../eibd-clients_0.0.4+nmu18_i386.deb) ...
Unpacking replacement eibd-clients ...
Preparing to replace wiregated 0.9-41 (using .../wiregated_0.9-45_all.deb) ...
Unpacking replacement wiregated ...
Preparing to replace wg-patch 0.0.29-1 (using .../wg-patch_0.0.30-2_all.deb) ...
Unpacking replacement wg-patch ...
Preparing to replace librrd4 1.3.1-4+nmu1 (using .../librrd4_1.3.1-4+nmu2_i386.deb) ...
Unpacking replacement librrd4 ...
Preparing to replace libow-perl 2.8p2 (using .../libow-perl_2.8p14-2+nmu1_i386.deb) ...
Unpacking replacement libow-perl ...
Preparing to replace libownet-perl 2.8p2 (using .../libownet-perl_2.8p14-2+nmu1_all.deb) ...
Unpacking replacement libownet-perl ...
Preparing to replace linknx 0.0.1.28-1 (using .../linknx_0.0.1.30-1_i386.deb) ...
Unpacking replacement linknx ...
Preparing to replace owfs-fuse 2.8p2 (using .../owfs-fuse_2.8p14-2+nmu1_i386.deb) ...
Unpacking replacement owfs-fuse ...
Preparing to replace owfs-httpd 2.8p2 (using .../owfs-httpd_2.8p14-2+nmu1_i386.deb) ...
Unpacking replacement owfs-httpd ...
Processing triggers for man-db ...
Setting up webmin-wiregate (0.3-43) ...
Setting up eibd-config-wg (0.2-12) ...
*** Restarting EIB/KNX daemon eibd
failed!
dpkg: error processing eibd-config-wg (--configure):
subprocess post-installation script returned error exit status 1
Setting up libeibclient0 (0.0.4+nmu18) ...
Setting up libeibclient-dev (0.0.4+nmu18) ...
Setting up libowfs27 (2.8p14-2+nmu1) ...
Setting up owfs-server (2.8p14-2+nmu1) ...
Setting up eibd-clients (0.0.4+nmu18) ...
dpkg: dependency problems prevent configuration of wg-patch:
wg-patch depends on eibd-config-wg; however:
Package eibd-config-wg is not configured yet.
dpkg: error processing wg-patch (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of wiregated:
wiregated depends on wg-patch; however:
Package wg-patch is not configured yet.
dpkg: error processing wiregated (--configure):
dependency problems - leaving unconfigured
Setting up librrd4 (1.3.1-4+nmu2) ...
Setting up libow-perl (2.8p14-2+nmu1) ...
Setting up libownet-perl (2.8p14-2+nmu1) ...
Setting up linknx (0.0.1.30-1) ...

Configuration file `/etc/linknx.xml'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
==> Keeping old config file as default.
Setting up owfs-fuse (2.8p14-2+nmu1) ...
insserv: warning: current stop runlevel(s) (0 1 6) of script `owfs-fuse' overwrites defaults (0 1 6
S).
Setting up owfs-httpd (2.8p14-2+nmu1) ...
insserv: warning: current stop runlevel(s) (0 1 6) of script `owfs-httpd' overwrites defaults (0 1
6 S).
Errors were encountered while processing:
eibd-config-wg
wg-patch
wiregated
E: Sub-process /usr/bin/dpkg returned an error code (1)

Was ist da schiefgelaufen?

Grüße Klausi

Edit: Habe gerade gesehen, es gibt dazu noch mehr Threads, wo mein Beitrag evtl. besser aufgehoben wäre. Vielleicht kann Ihn ja jemand dahin verschieben!?

[makki]

Einfach nochmal auf Update drücken, ansonsten ist vermutlich die Config für den EIB/KNX Buszugriff irgendwie verhunzt(?)

Makki

[swiss]

Ich wollte mal nachfragen, ob das Problem nun schon behoben wurde?

Ich habe ja kein Problem damit, dass der 1-Wire BUS ab und zu nicht tut und die RRD's löcher aufweisen. Viel mühsamer ist, dass immer in der Zeit, in der das Problem besteht, auch das komplete Pluginsystem einfriert. Ich habe fast alle meine Logiken in Plugins abgebildet und spüre es ganz massiv wenn das System wieder still steht. Dazu kommt es mir so vor, als ob das Problem immer schilimmer wird. Wo noch vor ein paar Tagen immer ca. 2 Tage ruhe dann 12h Loch und danach wieder 2 Tage ruhe war, habe ich nun nach 1 Tag wieder das Problem und es dauert aktuell schon über 20h.

Ich hoffe es gibt bald ien Patch der dass behebt.

[StefanW]

Hallo Patrick, die Patches sind seit einigen Tagen schon im Beta-Test bei uns und einigen Kundenanlagen. Wann wir es freigeben wird Makki dann mitteilen.

Du kannst allerdings mit dem WG-Deamon auch zurück auf PL29, wenn es bei Dir weiterhin Probleme macht (tritt insbesondere mit heftigen Plugins auf). Makki hat weiter oben geschrieben, wie man das downgrade ausführt.

glg

Stefan

[makki]

PL32 ist soeben raus
Das grobe sollte behoben sein..

Makki