Verhalten von seriellen Devices beim Beenden von Sub-Prozessen

[zap]

Ich habe mehr oder weniger durch Zufall einen Effekt beim Beenden von Sub-Prozessen festgestellt. Ich habe 2 serielle Devices in FHEM definiert (EnOcean und CUL 433). Wenn nun ein geforkter Sub-Prozess beendet wird, tauchen manchmal(!) im FHEM-Log folgende Meldungen auf:

Code Auswählen Erweitern


2017.04.18 09:11:05 1: /dev/ttyUSB1 disconnected, waiting to reappear (TCM_ESP3_2)
2017.04.18 09:11:05 1: /dev/ttyACM0 disconnected, waiting to reappear (d_cul433)
2017.04.18 09:11:10 1: /dev/ttyACM0 reappeared (d_cul433)
2017.04.18 09:11:10 1: /dev/ttyUSB1 reappeared (TCM_ESP3_2)


Nun wird ja beim Forken eines Sub-Prozesses eine Kopie des fhem.pl Prozesses angelegt, inkl. der seriellen Devices. Ich interpretiere die Meldungen so, dass diese von den Kopien kommen, wenn der Sub-Prozess beendet wird. Wenn dem aber so ist, woher kommen dann die "reappeared" Meldungen? Die Devices funktionieren im Hauptprozess ja weiter wenn Sub-Prozesse gestartet werden.

Ist dieses Verhalten kritisch oder kann man die Meldungen ignorieren? Ich denke nicht, dass die Meldungen EnOcean bzw. dem CUL zuzuschreiben sind, da sie ja für beiden Devices auftreten.

[rudolfkoenig]

Wie startest du diese Prozesse?

[zap]

Derzeit verwende ich SubProcess.pm. Da sieht das so aus:

Code Auswählen Erweitern


my $child = SubProcess->new ({ onRun => \&HMCCU_CCURPC_OnRun,
  onExit => \&HMCCU_CCURPC_OnExit, timeoutread => $to_read, timeoutwrite => $to_write });
my $pid = $child->run ();


In SubProcess.pm passiert folgendes:

Code Auswählen Erweitern


  my $pid= fork;

  if(!$pid) {
    # CHILD
   
    # run
    my $onRun= $self->{onRun};
    if(defined($onRun)) {
      eval { &$onRun($self) };
    }
   
    # exit
    my $onExit= $self->{onExit};
    if(defined($onExit)) {
      eval { &$onExit($self) };
    }
   
    #close(PARENT);
    POSIX::_exit(0);
   
  } else {
    # PARENT
    return $pid;
  } 


Den Code habe ich etwas gekürzt. Also eigentlich klassisches Verfahren beim Forken wie auch in anderen Sprachen. Und wie gesagt, die Meldungen kommen nicht bei jedem Beenden eines Sub-Prozesses.

Ergänzung: In meinem Modul werden 4 Sub-Prozesse gestartet und irgendwann auch mal beendet. Trotzdem kommen die o.g. Meldungen nur 1x (wenn sie denn kommen).

[rudolfkoenig]

Blocking benutzt fhemFork(), die Netzwerkports zumacht, und die DB-Verbindung speziell kennzeichnet, sonst gab es Probleme.
Zu deinem Problem kann ich aber leider nichts sagen, ausser dass ich es zum ersten mal hoere.

[zap]

Ok, danke trotzdem. Mittlerweile habe ich herausgefunden, dass die Meldungen aus DevIo.pm kommen. Grundsätzlich funktionieren die Devices ja auch nach dem Beenden der Sub-Prozesse. Scheint also nicht so kritisch zu sein.

Update: Habe jetzt mal die fhemFork() kopiert, d.h. lasse alle DevIo Devices im Child schließen. Dann kommen die Meldungen nicht beim Beenden sondern bereits beim Starten des Sub-Prozesses beim Aufruf von DevIo_CloseDev(). Scheint also wirklich daran zu liegen, dass die seriellen Devices beim Forken mitgeclont werden.

[justme1968]

beim forken werden alle geöffneten filedescriptoren mit geklont.

damit das system zuverlässig funktioniert und z.b. ein 'shutdown restart' immer funktioniert muss man das beachten und alle nicht benötigten filedescriptoren nach dem forken schliessen. sonst kann es alle möglichen probleme geben.

einige davon haben damals zum zentralen fhemFork geführt und es ist sinnvoll das es von allen modulen soweit wie möglich verwendet wird.

[zap]

Genau das habe ich ja mal testweise implementiert. Nur habe ich eben nicht fhemFork() verwendet sondern den Code von fhemFork() kopiert.
Beim Schließen von Devices im Child bzw. dem Schließen der geclonten FDs kommen eben die "Device disconnected" Meldungen. Aber ich denke, das ist normal, zumal die FDs im Child ja nicht mehr benötigt werden.

Ich liefere mal einen Patch für SubProcess.pm, der fork durch fhemFork() ersetzt.

[Dr. Boris Neubert]

Ich liefere mal einen Patch für SubProcess.pm, der fork durch fhemFork() ersetzt.

Danke. Werde ich gerne einbauen.