blocking.pm: BlockingCall() liefert PID, Funktion wird aber nicht aufgerufen

[TeeVau]

Hallo,

2 User haben mit meinem 70_VIERA Modul Probleme (http://forum.fhem.de/index.php/topic,48878.0.html). Es scheint das selbe Fehlerbild zu sein: Ein Child wird per Blocking Funktion gestartet, es gibt auch eine PID, aber die Funktion, die non blocking sein soll, scheint nicht aufgerufen zu werden.
Per InternalTimer() rufe ich alle 30 Sekunden die Funktion VIERA_GetStatus() auf. Dort wird mit folgendem Code eine Funktion (VIERA_GetDoIt) non blocking ausgeführt:

Code Auswählen Erweitern

    Log3 $name, 4, "VIERA[VIERA_GetStatus]: Using non blocking...";
    $hash->{helper}{RUNNING_PID_GET} = BlockingCall("VIERA_GetDoIt", $hash, "VIERA_GetDone", 10, "VIERA_GetAbortFn", $hash) unless(exists($hash->{helper}{RUNNING_PID_GET}));
    if($hash->{helper}{RUNNING_PID_GET}) {
      Log3 $name, 4, "VIERA[VIERA_GetStatus]: VIERA_GetDoIt() BlockingCall process started with PID $hash->{helper}{RUNNING_PID_GET}{pid}";
    }
    else {
      Log3 $name, 3,  "VIERA[VIERA_GetStatus]: BlockingCall process start failed for VIERA_GetDoIt()";
    }

Die Logmeldungen sind auch im FHEM Log zu sehen, inkl. PID.
Die Funktion VIERA_GetDoIt() gibt direkt am Anfang eine Log Meldung aus. Diese taucht aber nicht mehr im FHEM Log auf. Von daher gehe ich davon aus, dass die Funktion VIERA_GetDoIt gar nicht gestartet/ausgeführt wird.

Code Auswählen Erweitern


sub VIERA_GetDoIt($) {
  my ($hash) = @_;
  my $myVol = "";
  my $myMute = "";
 
  Log3 $hash, 4, "VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for ".$hash->{NAME}." start...";
...


Hat jemand einen Hinweis, woran das liegen kann?

Was mir aufgefallen ist: Bei mir zählt die PID immer hoch. Bei dem Log von einem User, ist die PID bei 2 Aufrufen identisch. Kann das abhängig vom Linux sein, oder ist das ein Hinweis, dass was schief läuft?

Tobias

[rudolfkoenig]

Mit "attr global verbose 4" bekommt man im Mutter(?)-Prozess etwas mehr an Ausgaben, vermutlich wird das aber nicht weiterhelfen.

Klassisch waere Speicherengpass: fork geht zwar durch, damit werden alle Speicherseiten beim Kind auf CopyOnWrite gesetzt. Falls es anfaengt was sinnvolles zu machen, dann muessen neue Seiten alloziert werden, und das geht schief, der Prozess wird terminiert. Das ist nur eine Vermutung/Theorie, basierend auf evtl. veraltetes Wissen.
Um die Theorie zu unterstuetzen wuerde ich bei den Notleidenden regelmaessig free protokollieren (oder head -4 /proc/meminfo).

Alternativen:
- das Kind verklemmt sich im fhemFork in einem TcpServer_Close oder DevIo_CloseDev. Pruefen mit strace -p oder lsof aufs Kind.
- Eine SELinux/etc Konfiguration unterbindet bestimmte Aktionen fuer Kinder.
Ich habe das verlinkte Thema auf beobachten gesetzt.

[TeeVau]

Hi Rudi,

für den Fall, dass es trotz "Beobachten" an dir vorbei gegangen ist: Bei einem Problemfall hat ein fhem update und restart abhilfe geschaffen und zur Lösung geführt. Die PID wird nun auch wieder korrekt hochgezählt.