Subroutine redefined bei "shutdown restart" (neu seit 1.6.2014)

Begonnen von u302320, 01 Juni 2014, 12:49:55

Vorheriges Thema - Nächstes Thema

u302320

Hallo,

nach Update auf den Stand vom 1.6 beschwert sich Perl über die doppelte Definition folgender Subroutines:

2014.06.01 12:41:11 1: Including /var/media/ftp/uStor01/fhem/fhem.cfg
Subroutine Untoggle redefined at /var/media/ftp/uStor01/fhem/FHEM/99_MyUtils.pm line 10, <$fh> line 8.
Subroutine addLog redefined at /var/media/ftp/uStor01/fhem/FHEM/99_MyUtils.pm line 34, <$fh> line 8.
Subroutine GetState_Initialize redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 42, <$fh> line 8.
Subroutine CommandGetState redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 52, <$fh> line 8.
Subroutine stringToNumber redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 100, <$fh> line 8.
Subroutine stripNumber redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 111, <$fh> line 8.
Subroutine isNumber redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 124, <$fh> line 8.
Subroutine isInteger redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 130, <$fh> line 8.
Subroutine isFloat redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 136, <$fh> line 8.


Wie gehabt habe ich keine Änderungen (ausser dem Update) vorgenommen.

Die Funktionen sind nicht doppelt vorhanden:

root@fb:/var/media/ftp/uStor01/fhem/FHEM# grep isFloat *
99_getstate.pm:sub isFloat;
99_getstate.pm:        $v = $val if (isFloat($val) && !$v);
99_getstate.pm:sub isFloat


Interessanterweise scheint das Problem nur bei "shutdown restart" aufzutreten. Bei getrenntem shutdown und nachfolgend normalem Start gibt es keine Fehler:

2014.06.01 12:50:50 0: Server shutdown
2014.06.01 12:50:58 1: CallBlockingFn: Can't connect to localhost:7072

Can't use an undefined value as a symbol reference at /var/media/ftp/uStor01/fhem/FHEM/Blocking.pm line 129.
2014.06.01 12:51:57 1: Including /var/media/ftp/uStor01/fhem/fhem.cfg
2014.06.01 12:51:58 3: telnetPort: port 7072 opened
2014.06.01 12:51:58 3: Opening cul device /dev/ttyACM0
2014.06.01 12:51:59 3: Setting cul baudrate to 115200
2014.06.01 12:51:59 3: cul device opened
2014.06.01 12:51:59 3: cul: Possible commands: BCFiAZEGMRTVWXefmltux
2014.06.01 12:52:00 3: WEB: port 8083 opened
2014.06.01 12:52:04 1: Including /var/media/ftp/uStor03/fhem/fhem.save
2014.06.01 12:52:05 0: Server started with 88 defined entities (version $Id: fhem.pl 6007 2014-05-30 06:58:37Z rudolfkoenig $, os linux, user root, pid 19759)


betateilchen

Denn sie wissen nicht, was sie tun...

Das ist weder eine Fehlermeldung noch eine Beschwerde von fhem, sondern ein völlig korrekte Konsolenmeldung von perl.

Die Dateien 99_MyUtils.pm und 99_getstate.pm beinhalten vermutlich Funktionen, die unter gleichem Namen bereits in der 99_Utils.pm vorhanden sind. Damit wird die jeweilige Funktion aus der 99_Utils.pm durch den Inhalt der jeweils anderen Datei ersetzt und diese Ersetzung von fhem protokolliert.

Warum passiert sowas?

Zum Beispiel, weil irgendjemand einfach Dateien kopiert und modifiziert hat, ohne zu verstehen, was dahintersteckt. Die Ursache liegt in diesem Fall auf dem Anwendersystem, nicht in fhem selbst.

Oder jemand hat in seiner Datei eine Abhängigkeit definiert, beispielsweise "require 99_Utils.pm"
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

u302320

Ich hatte in meinem Beitrag geschrieben Die Funktionen sind nicht doppelt definiert und darüber hinaus noch am Beispiel von isFloat das mit einem grep isFloat * bzw dessen Output zu untermauern. Selbigem hättest du entnehmen können, insbesondere auch in Zusammenhang mit dem Hinweis, dass ich weder Konfiguration noch Perl-Module angefasst habe, entnehmen können dass deine Erklärungsversuche in meinem Fall nicht passen.

Um diese Diskussion nicht gänzlich entgleisen zu lassen würde ich dich bitten, mir grundsätzlich entweder gar nicht zu antworten, oder in sachlicher Form, also insbesondere unter Verzicht auf Beleidigungen und oberlehrerhaften Kommentare. Das Forum ist hier nicht deine persönliche Trollwiese. Danke!

betateilchen

(http://www.champstyle.net/images/smiley/vogelzeig.gif)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

strauch

Zitat von: Mattias am 01 Juni 2014, 22:46:31
grep isFloat *

Also ich bin alles andere als ein Profi, aber darüber Grübel ich heute schon den ganzen Tag. Was soll das bringen? Davon ab das ich die Suche nach isFloat * schon nicht verstehe (wonach sucht er denn damit?). Was soll es auch anzeigen. Perl meckert ja das Dinge doppelt definiert sind und führt aber nur eines aus. Also wie soll man dann was mit der grep Funktion finden.

Also wenn ich mal einen naiven Tipp geben darf, würde mir wenn ich die Fehlermeldung hätte der Inhalt der betreffenden PM Dateien mehr helfen als eine grep Ausgabe.

Zudem hat niemand auch die Fehlermeldung behauptet das du irgendwelche PERL Module angefasst hast. Und das du gar keine Dateien angefasst hast, kann ich mir schlecht vorstellen wenn du eine 99_myUtils und eine gestate hast, meines Wissens sind die nicht standardmäßig bei FHEM dabei?!
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

betateilchen

@strauch:

Die generelle Syntax für grep ist: grep options pattern input_file_names

Mit "grep isFloat *" wird also in allen Dateien (*) nach "isFloat" gesucht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

also ich find den Angang von Mattias ganz ok,

in seinem log steht
Float redefined at /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm line 136, <$fh> line 8.

und mit grep isFloat schaut er im FHEM Verzeichnis ob die Routine in noch einer anderen Datei definiert wird.

Wird sie nicht, könnte also evtl ein fhem.pl "Fehler" sein. Fehler in Hochkomma, weil ist ja eine Warnung und ich denke das es keine funktionalen Einschränkungen gibt. Muss aber noicht, alle user Module kommen genauso in Frage.

Als Tip, Mattias, schau doch mal ob Du Die 99_getstate vielleicht mehrfach per do oder so einliest.

vg
Jörg

u302320

Ich hatte ja bereits berichtet, dass ich die betreffenden Funktionen weder mehrfach definiert noch selber mehrfach geladen habe. Da das Problem sich heute wieder in meinen Logs bemerkbar gemacht hat, bin ich dem nochmal nachgegangen und fündig geworden.

Die Fehlermeldung wird durch mehrfaches Laden des Moduls (seitens fhem.pl) getriggert. Scheinbar tritt das Problem nur dann auf, wenn es sich um ein autoload-Modul (99_.*pm) handelt UND die Groß-/Kleinschreibung von Dateiname nicht zu der Moduldefinition passt.

In meinem Fall handelt es sich um 99_getstate.pm, ohne Änderungen meinerseits von SourceForge aus fhem/contrib/getstate heruntergeladen.

Das Initialize der Datei sieht folgenermaßen aus

sub GetState_Initialize($$)
{
  my %lhash = ( Fn=>"CommandGetState",
                Hlp=>"<devspec>,list short status info" );
  $cmds{getstate} = \%lhash;
}


fhem.pl scheint Autoload-Module beim Hochfahren zweimal zu laden, wobei ich durch die zugrundeliegende Mechanik noch nicht vollständig durchgestiegen bin. Anhand von mir eingebauter Logausgaben in fhem.pl habe ich den Eindruck, dass das Setzen des Attributs modpath das erneute Laden auslöst. Da Initialize- und Dateiname nicht zueinander passen _und_ der Code, um genau dieses Problem zu erkennen, leider nicht anschlägt, wird versucht, das Modul ein zweites Mal zu laden.

2014.09.01 13:21:17 0: Server shutdown
2014.09.01 13:21:28 1: CommandReload: Loading /var/media/ftp/uStor01/fhem/FHEM/99_SUNRISE_EL.pm
2014.09.01 13:21:28 5: Loading /var/media/ftp/uStor01/fhem/FHEM/99_SUNRISE_EL.pm
2014.09.01 13:21:29 1: CommandReload: Loading /var/media/ftp/uStor01/fhem/FHEM/99_Utils.pm
2014.09.01 13:21:29 5: Loading /var/media/ftp/uStor01/fhem/FHEM/99_Utils.pm
2014.09.01 13:21:29 1: CommandReload: Loading /var/media/ftp/uStor01/fhem/FHEM/99_XmlList.pm
2014.09.01 13:21:29 5: Loading /var/media/ftp/uStor01/fhem/FHEM/99_XmlList.pm
2014.09.01 13:21:29 1: CommandReload: Loading /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm
2014.09.01 13:21:29 5: Loading /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm
2014.09.01 13:21:29 1: CommandReload: Loading /var/media/ftp/uStor01/fhem/FHEM/99_myUtils.pm
2014.09.01 13:21:29 5: Loading /var/media/ftp/uStor01/fhem/FHEM/99_myUtils.pm
2014.09.01 13:21:29 5: Initializing Type Library:
2014.09.01 13:21:29 1: Including fhem.cfg
2014.09.01 13:21:29 5: Cmd: >attr global verbose 5<
2014.09.01 13:21:29 5: Cmd: >attr global autoload_undefined_devices 1<
2014.09.01 13:21:29 5: Cmd: >attr global backup_before_update 1<
2014.09.01 13:21:29 5: Cmd: >attr global backupcmd fhem-backup.sh<
2014.09.01 13:21:29 5: Cmd: >attr global backupdir /var/media/ftp/uStor03/fhem/backup<
2014.09.01 13:21:29 5: Cmd: >attr global backupsymlink no<
2014.09.01 13:21:29 5: Cmd: >attr global logdir /var/media/ftp/uStor03/fhem<
2014.09.01 13:21:29 5: Cmd: >attr global logfile %L/fhem-%Y-%m.log<
2014.09.01 13:21:29 5: Cmd: >attr global modpath /var/media/ftp/uStor01/fhem<
2014.09.01 13:21:29 1: CommandReload: Loading /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm
2014.09.01 13:21:29 5: Loading /var/media/ftp/uStor01/fhem/FHEM/99_getstate.pm
2014.09.01 13:21:29 5: Cmd: >attr global motd none<


Nach dem Umbenennen der Datei von 99_getstate.pm nach 99_GetState.pm tritt das Problem nicht mehr auf. Ich würde trotzdem zusätzlich vorschlagen:

  • die Groß-/Kleinschreibung der Datei im Contrib-Verzeichnis anzupassen und
  • den Code für die Erkennung dieses Problems anzupassen (fhem.pl, 1503ff)

Danke.

betateilchen

Zitat von: Mattias am 01 September 2014, 13:59:05
Nach dem Umbenennen der Datei von 99_getstate.pm nach 99_GetState.pm tritt das Problem nicht mehr auf. Ich würde trotzdem zusätzlich vorschlagen:

  • die Groß-/Kleinschreibung der Datei im Contrib-Verzeichnis anzupassen ...

erledigt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!