[gelöst] PRESENCE und snmpCheck

Begonnen von majorshark, 26 Dezember 2014, 19:46:17

Vorheriges Thema - Nächstes Thema

majorshark

Hallo ins Forum.

Nachdem ich mich jetzt mehrere Monate mit einer Fehlermeldungen im Log herumschlage, wollte ich dieser auf den Grund gehen. Auslöser ist auf jeden Fall die "snmpCheck" Funktion in der 99_myUtils.pm.
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81
was dann auf die Zeile verweist?!
@nextid = keys %$response;

Da ich mit Perl noch nicht so gut kann habe ich mich mal auf dem analytischen Weg dem Problem genähert. Dabei habe ich verschiedene Logbucheinträge generiert und folgendes festgestellt. Wird die Funktion nur von einem PRESENCE aufgerufen ist alles in Ordnung. wird Sie dagegen von mehreren PRESENCE Abfragen aufgerufen, kommt es scheinbar zu Überschneidungen und möglicherweise zum Verlust der SESSION. Ohne korrekte Session gibt es auch keine Werte und die Funktion produziert den o.g. Fehler im Logbuch. So meine Vermutung.

Eine "normale Abfrage" sieht so aus:

2014.12.26 18:49:18 3: SNMP Check fuer Client: 0x88308a6447d3.
2014.12.26 18:49:18 3: Response: HASH(0x38e1638)
2014.12.26 18:49:19 3: >0x00015c543e40< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x9c029889fc65< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0xb827ebbbea5a< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x801f028502c2< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x60d9c79f9daa< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x00113206f6af< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x00b60010b4fb< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x98fe949ddc63< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x60921783420a< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x4844f74ae938< >0x88308a6447d3<
2014.12.26 18:49:19 3: >0x88308a5d2d83< >0x88308a6447d3<
2014.12.26 18:49:28 3: SNMP Check fuer Client: 0x88308a5d2d83.
2014.12.26 18:49:28 3: Response: HASH(0x38e1638)
2014.12.26 18:49:29 3: >0x00015c543e40< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x9c029889fc65< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0xb827ebbbea5a< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x801f028502c2< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x60d9c79f9daa< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x00113206f6af< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x00b60010b4fb< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x98fe949ddc63< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x60921783420a< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x4844f74ae938< >0x88308a5d2d83<
2014.12.26 18:49:29 3: >0x88308a5d2d83< >0x88308a5d2d83<
2014.12.26 18:49:39 3: SNMP Check fuer Client: 0x60921783420a.
2014.12.26 18:49:39 3: Response: HASH(0x281f680)
2014.12.26 18:49:40 3: >0x00015c543e40< >0x60921783420a<
2014.12.26 18:49:40 3: >0x9c029889fc65< >0x60921783420a<
2014.12.26 18:49:40 3: >0xb827ebbbea5a< >0x60921783420a<
2014.12.26 18:49:40 3: >0x801f028502c2< >0x60921783420a<
2014.12.26 18:49:40 3: >0x60d9c79f9daa< >0x60921783420a<
2014.12.26 18:49:40 3: >0x00113206f6af< >0x60921783420a<
2014.12.26 18:49:40 3: >0x00b60010b4fb< >0x60921783420a<
2014.12.26 18:49:40 3: >0x98fe949ddc63< >0x60921783420a<
2014.12.26 18:49:40 3: >0x60921783420a< >0x60921783420a<


Eine Abfrage mit Fehler sieht dann so aus. Man sieht es auch an den Zeiten des Aufrufes:
2014.12.26 18:51:00 3: SNMP Check fuer Client: 0x88308a5d2d83.
2014.12.26 18:51:00 3: Response: HASH(0x281f680)
2014.12.26 18:51:00 3: SNMP Check fuer Client: 0x88308a6447d3.
2014.12.26 18:51:00 3: Response: HASH(0x281f680)
2014.12.26 18:51:10 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81.
2014.12.26 18:51:10 3: >0x00113206f6af< >0x88308a6447d3<
2014.12.26 18:51:10 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81.
2014.12.26 18:51:10 3: >0x00113206f6af< >0x88308a5d2d83<
2014.12.26 18:51:10 3: >0x801f028502c2< >0x88308a5d2d83<
2014.12.26 18:51:10 3: >0x98fe949ddc63< >0x88308a5d2d83<
2014.12.26 18:51:10 3: >0x60921783420a< >0x88308a5d2d83<
2014.12.26 18:51:10 3: >0x60d9c79f9daa< >0x88308a5d2d83<
2014.12.26 18:51:10 3: >0x88308a5d2d83< >0x88308a5d2d83<
2014.12.26 18:51:15 3: SNMP Check fuer Client: 0x60921783420a.
2014.12.26 18:51:15 3: Response: HASH(0x281f680)
2014.12.26 18:51:15 3: >0x00015c543e40< >0x60921783420a<
2014.12.26 18:51:15 3: >0x9c029889fc65< >0x60921783420a<
2014.12.26 18:51:15 3: >0xb827ebbbea5a< >0x60921783420a<
2014.12.26 18:51:15 3: >0x801f028502c2< >0x60921783420a<
2014.12.26 18:51:15 3: >0x60d9c79f9daa< >0x60921783420a<
2014.12.26 18:51:15 3: >0x00113206f6af< >0x60921783420a<
2014.12.26 18:51:15 3: >0x00b60010b4fb< >0x60921783420a<
2014.12.26 18:51:15 3: >0x98fe949ddc63< >0x60921783420a<
2014.12.26 18:51:15 3: >0x60921783420a< >0x60921783420a<


Dazu habe ich nun folgende Fragen:
1. Ist meine Vermutung zum Fehler richtig?
2. Wenn nicht, was erzeugt dann die Fehlermeldung?
3. Und das wichtigste. Wie kann man es abstellen?

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

justme1968

die routine aus dem wiki erzeugt bei jedem aufruf einen neuen abfrage kontext. fhem ist nicht multithreaded und die von presence geforkten prozesse sind gegeneinander gekapselt.

das problem ist vermutlich eher das aus irgendeinem grund die snmp anfrage tatsächlich ein leeres ergebnis liefert.

bitte poste mal deinen code mit zeilennummern.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

majorshark

Hallo Andre.

Du schreibst:
Zitatdie routine aus dem wiki erzeugt bei jedem aufruf einen neuen abfrage kontext. fhem ist nicht multithreaded und die von presence geforkten prozesse sind gegeneinander gekapselt.
Das bedeutet also das sich die einzelnen Aufrufe nicht überlagern können und auch die Daten in einem Aufruf nicht verloren gehen.

Zur Zeit habe ich die gleiche Fehlermeldung auch noch in Zeile 79. Hier noch ein kurzer Auszug aus dem Log. Wobei ich die extra Logbucheinträge in der myUtils wieder auskommentiert habe.
2014.12.27 06:13:43 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81.
2014.12.27 06:13:50 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 78.
2014.12.27 06:13:50 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81.
2014.12.27 06:16:15 3: Watchdog WatchDogAnwesend triggered
2014.12.27 06:19:32 3: Watchdog WatchDogAnwesend triggered
2014.12.27 06:40:53 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81.
2014.12.27 06:40:53 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 81.
2014.12.27 06:49:54 3: Watchdog WatchDogAnwesend triggered


Ich habe mal die 99_myUtils.pm als Anhang hinzugefügt.

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

justme1968

#3
änder mal die zeile 78 von while ( $nextid[0] =~ m/^$oid/ ) {inwhile ( @nextid && $nextid[0] && $nextid[0] =~ m/^$oid/ ) {

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

majorshark

Das mutiert ja schon zum Chat.  :)

Die Zeile ist geändert ...
Leider gibt es ein Fehler.
Global symbol "$nextid" requires explicit package name at ./FHEM/99_myUtils.pm line 79.

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

justme1968

sorry. copy&paste fehler. hab es oben korrigiert.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

majorshark

Danke . Ist geladen.

Ich las es jetzt mal laufen.

Kannst du mir bitte noch kurz erklären was die Zeile bedeutet.
Soweit ich das erklären kann ...
@nextid ist ein Array und nextid[0] ist das erste Element. Richtig?

Solange  das Muster $oid  in @nextid und nextid[0] und nextid[0] gefunden wird ?
Aber warum zwei mal nextid[0]. Das erscheint mit unlogisch.

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

justme1968

ja richtig.

das erste $nextid[0] prüft auf vorhanden sein, das zweite $nextid[0]  gehört zum regex match ($nextid[0] =~ m/^$oid/). der hat ja probleme gemacht wenn $nextid[0]  undefiniert ist. deshalb wird er so nur noch durchgeführt wenn es das array und ein element 0 gibt (bzw. nicht leer ist).

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

majorshark

Ach so wird das gelesen. Ich habe das =~ anders Interpretiert. Eben als Vergleichsoperator. Aber das ist ja ein Mustervergleich also nur ein Teil der "While" Anweisung.

Bisher noch keine Fehlermeldung in Log.
Top und großes Danke an Dich.
Sollte man die While Anweisung nicht in der Wiki ändern?

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

justme1968

wenn alles geht ändere ich es.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

majorshark

Ok. Ich lass es erst mal laufen und melde mich wieder.

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

majorshark

Noch eine Kurze Rückmeldung.

Keine Fehlermeldung mehr. Vielen Dank.

Grüße Frank
Grüße aus Dewitz

VM auf Synology DS718+ mit FHEM 5.9 auf Debian 9.5/32-Bit (stretch)
Nächster Leipziger Stammtisch:

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968