[geloest] Zombie Prozesse durch Lan-Ping

Begonnen von automatisierer, 14 Mai 2016, 08:01:27

Vorheriges Thema - Nächstes Thema

StefanP

Bei mir leider dasselbe. Ich habe zudem festgestellt, dass enablen/disablen der einzelnen PRESENCE-Entities keinen (direkten) Einfluss auf die Anzahl der Zombies hat. Meine Überschlags-Rechnung 4 Presence-Defines - 1 x disablen = 3 Zombies war also etwas vorschnell.

Soweit erstmal
Gruß StefanP

automatisierer

Wenn die Zombies da sind, dann sind die da bis der Elternprozess gestoppt wird - also FHEM shutdown - ein disable 1 und disable 0 während FHEM läuft bringt nix. Du kannst nur die Pings auf disable 1 setzen, speichern, dann FHEM neu starten und die Pings wieder auf disable 0 setzen - dann sind sie weg.
Aber die lieben Kleinen tun in unserem Fall ja nix...

Markus Bloch

Hallo ihr beiden,

könnt ihr bitte mal in fhem.pl die Zeile 4525

$SIG{CHLD} = 'DEFAULT';  # Forum #50898

auskommentieren ("#" davor setzen)? Dann FHEM beenden, schauen, dass alle Zombies weg sind und erneut starten?

Danke

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

rudolfkoenig

Und falls das Problem weiterhin besteht, die Ausgaben von:
- grep Sig /proc/<FHEM-PID>/status
- ps -ef | grep fhem
hier posten? ps -ef wg. Parent-PID.

Wernieman

Eine "kleine" Verbesserung:

Für die erste Ausgabe "grep Sig /proc/<FHEM-PID>/status" eine "copy-paste-Lösung"

for i in $(pgrep [f]hem); do echo $i; grep Sig /proc/$i/status; done


Und das 2. ist Optimaler mit:

ps -ef | grep [f]hem

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rudolfkoenig

ZitatEine "kleine" Verbesserung:
Aeh: das mit Sig wollt ich nur vom "richtigen" FHEM-Prozess wissen, die Zombies interessieren mich weniger...

ZitatUnd das 2. ist Optimaler mit:
Warum eigentlich? Je nachdem wo man ps ausfuehrt, kriegt man dann: grep: No match.




Wernieman

das 2. hatte ich nur geschrieben, damit es "übersichtlicher" ist. bei einem "ps | grep" findet man auch immer den grep-Prozess. Mit dem "trick" [] kann er sich aber nicht selber finden. Macht es manchmal "übersichtlicher". Und da ich für Deinen 1. Punkt schon etwas geschrieben hatte ...

Du wolltest also eigentlich "grep Sig /proc/<FHEM-Parend-PID>/status"? Rauszufinden mit 2.?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rudolfkoenig

ZitatMit dem "trick" [] kann er sich aber nicht selber finden.
Sorry, habs uebersehen, dass das "no match" Problem nur im tcsh besteht.

ZitatDu wolltest also eigentlich "grep Sig /proc/<FHEM-Parend-PID>/status"? Rauszufinden mit 2.?
Verstehe nicht, was du damit sagen willst.

Wernieman

Du schriebst:
"grep Sig /proc/<FHEM-PID>/status"

Später als Ergänzung "das mit Sig wollt ich nur vom "richtigen" FHEM-Prozess wissen", deshalb meine "Ergänzung".

Warten wir aber erst mal auf die Antwort der "Betroffenen" .. und ich hoffe mit meinem Beitrag nicht zu viele Verunsicherungen aufgerufen zu haben.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

automatisierer

Zombies sind noch da... Zeile 4525 habe ich wieder 'einkommentiert'.

Hier die gewünschten Ausgaben:


bananapi@bapiFHEM /opt/fhem $ ps aux|grep fhem
fhem     15188 28.7  5.1  51408 46000 pts/0    S    12:49   0:35 perl fhem.pl fhem.cfg
fhem     15216  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15218  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15219  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15222  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15228  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15230  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15231  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15233  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15236  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15237  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15240  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15241  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15244  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15248  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>
fhem     15256  0.0  0.0      0     0 pts/0    Z    12:49   0:00 [perl] <defunct>



bananapi@bapiFHEM /opt/fhem $ grep Sig /proc/15188/status
SigQ: 15/6993
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000011080
SigCgt: 0000000180006003



bananapi@bapiFHEM /opt/fhem $ ps -ef | grep fhem
fhem     15188     1 15 12:49 pts/0    00:00:42 perl fhem.pl fhem.cfg
fhem     15216 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15218 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15219 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15222 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15228 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15230 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15231 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15233 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15236 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15237 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15240 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15241 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15244 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15248 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15256 15188  0 12:49 pts/0    00:00:00 [perl] <defunct>
fhem     15370 15188  0 12:54 pts/0    00:00:00 perl fhem.pl fhem.cfg
fhem     15371 15370  0 12:54 pts/0    00:00:00 ping -c 4 192.168.171.131
fhem     15372 15188  0 12:54 pts/0    00:00:00 perl fhem.pl fhem.cfg
fhem     15373 15188  1 12:54 pts/0    00:00:00 perl fhem.pl fhem.cfg
fhem     15374 15372  0 12:54 pts/0    00:00:00 ping -c 4 192.168.171.141
fhem     15375 15373  0 12:54 pts/0    00:00:00 ping -c 4 192.168.171.142
bananapi 15377 14918  0 12:54 pts/0    00:00:00 grep --color=auto fhem


rudolfkoenig

ps -ef sagt: Alle <defunct> Prozesse haben den Prozess 15188 (den "eigentlichen" FHEM-Prozess) als Elternprozess.
grep status sagt: SIGCHLD steht auf Ignore: SIGCHLD ist 17, und Bit 17 ist laut "SigIgn: 0000000000011080" (Zahl ist als Hex zu lesen) gesetzt.

Theorie: Die Prozesse sind verstorben, bevor FHEM die Signal-Behandlung konfiguriert hat, und ein nachtraeglich gesetztes $SIG{CHLD} = 'IGNORE' hat keine Auswirkung auf Zombies.
Pruefung: Bitte den Aufruf von SignalHandling(); in fhem.pl weiter nach oben schieben, z.Bsp. direkt unter "# End of client code".

Markus Bloch

Zitat von: rudolfkoenig am 17 Mai 2016, 19:44:59
Theorie: Die Prozesse sind verstorben, bevor FHEM die Signal-Behandlung konfiguriert hat, und ein nachtraeglich gesetztes $SIG{CHLD} = 'IGNORE' hat keine Auswirkung auf Zombies.

Das bestätigt meine Theorie, dass der Fork innerhalb von 60 Sekunden nach Start von BlockingCall() noch garnicht durch das OS gestartet wird, aufgrund der enormen Last beim Starten und Initialisieren von FHEM. Nach 60 Sekunden werden die Calls durch BlockingKill() abgeschossen. Ich glaube, dass zu dieser Zeit der Fork noch garnicht vom OS gestartet wurde und die Child-Prozesse deshalb als Zombies enden.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

StefanP

'Nabend,

nachdem ich jetzt 3 Std. gebraucht hab' erst den Raspi kaputt zu updaten (der Framebuffer war plötzlich nicht mehr da), und dann fhem solange zu bearbeiten bis es nicht mehr startete, braucht ihr jetzt meine Untersuchungsergebnisse wohl nicht mehr.

Ihr kriegt sie aber trotzdem  ;) :

pi@dbDB-Raspi:/opt/fhem $ ps aux|grep fhem
fhem      1094 15.3 14.6  74208 65288 ?        S    19:48   9:44 /usr/bin/perl fhem.pl fhem.cfg
fhem      1098  0.0  0.0      0     0 ?        Z    19:49   0:01 [perl] <defunct>

pi@dbDB-Raspi:/opt/fhem $ grep Sig /proc//1094/status
SigQ:   1/3410
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000011084
SigCgt: 0000000180006003

pi@dbDB-Raspi:/opt/fhem $ ps -ef | grep fhem
fhem      1094     1 15 19:48 ?        00:09:44 /usr/bin/perl fhem.pl fhem.cfg
fhem      1098  1094  0 19:49 ?        00:00:01 [perl] <defunct>


Komischerweise hab ich jetzt nur noch einen Zombie, nicht mehr drei.

Gruß StefanP

automatisierer

Ich hab mal ganz mutig irgend welche Zeilen in der fhem.pl verschoben...

Das von Zeile 527 nach  446 ...


SignalHandling();

my $pfn = $attr{global}{pidfilename};
if($pfn) {
  die "$pfn: $!\n" if(!open(PID, ">$pfn"));
  print PID $$ . "\n";
  close(PID);
}

my $gp = $attr{global}{port};
if($gp) {
  Log 3, "Converting 'attr global port $gp' to 'define telnetPort telnet $gp'";
  my $ret = CommandDefine(undef, "telnetPort telnet $gp");
  Log 1, "$ret" if($ret);
  delete($attr{global}{port});
}

my $sc_text = "SecurityCheck:";
$attr{global}{motd} = "$sc_text\n\n"
        if(!$attr{global}{motd} || $attr{global}{motd} =~ m/^$sc_text/);

$init_done = 1;
$lastDefChange = 1;

foreach my $d (keys %defs) {
  if($defs{$d}{IODevMissing}) {
    Log 3, "No I/O device found for $defs{$d}{NAME}";
    delete $defs{$d}{IODevMissing};
  }
}

DoTrigger("global", "INITIALIZED", 1);
$fhem_started = time;

$attr{global}{motd} .= "Running with root privileges."
        if($^O !~ m/Win/ && $<==0 && $attr{global}{motd} =~ m/^$sc_text/);
$attr{global}{motd} .=
        "\nRestart FHEM for a new check if the problem is fixed,\n".
        "or set the global attribute motd to none to supress this message.\n"
        if($attr{global}{motd} =~ m/^$sc_text\n\n./);
my $motd = $attr{global}{motd};
if($motd eq "$sc_text\n\n") {
  delete($attr{global}{motd});
} else {
  if($motd ne "none") {
    $motd =~ s/\n/ /g;
    Log 2, $motd;
  }
}

my $osuser = "os:$^O user:".(getlogin || getpwuid($<) || "unknown");
Log 0, "Featurelevel: $featurelevel";
Log 0, "Server started with ".int(keys %defs).
        " defined entities ($attr{global}{version} perl:$] $osuser pid:$$)";


Ich hab keinen Plan was ich da gemacht hab und ob das richtig war.

Die Zombies sind weg, beim Start gabs aber ein paar Fehlermeldungen.


bananapi@bapiFHEM ~ $ sudo service fhem start
Starting fhem...
Use of uninitialized value in numeric gt (>) at fhem.pl line 819.
Use of uninitialized value in numeric gt (>) at fhem.pl line 819.
Use of uninitialized value in numeric gt (>) at fhem.pl line 819.
2016.05.18 08:11:37 0: Featurelevel: 5.7
Use of uninitialized value in numeric gt (>) at fhem.pl line 819.
2016.05.18 08:11:37 0: Server started with 1 defined entities ( perl:5.014002 os:linux user:bananapi pid:2803)


Beim ersten mal hab ich nach der Meldung 'Server started with 1 defined entities' die Nerven verloren, abgebrochen und wieder die Originale fhem.pl genommen. Da der Start danach reibungslos lief, hab ich dann einen zweiten Versuch mit der veränderten fhem.pl gestartet.

Wieder die gleichen Fehlermeldungen, der Start dauerte sehr lange, dass Webif war lange (~2 Minuten) nicht zu erreichen - geht jetzt aber. Im LOG (global verbose 1) steht nix besonderes.

rudolfkoenig

Ich habe SignalHandling nach oben geschoben und fhem.pl eingecheckt.

ZitatIch hab mal ganz mutig irgend welche Zeilen in der fhem.pl verschoben...
Na so kaputt ist die Initialisierung auch nicht.
Bin gerne bereit was zu aendern, aber nicht planlos.

ZitatWieder die gleichen Fehlermeldungen, der Start dauerte sehr lange, dass Webif war lange (~2 Minuten) nicht zu erreichen - geht jetzt aber. Im LOG (global verbose 1) steht nix besonderes.
Ist kein Wunder, selbst auf dem default 3 wird nichts zu sehen sein. Mit "attr global verbose 5" und "attr global mseclog" koennte man vermutlich feststellen, welche der 500+ FHEM-Geraete fuer die Verzoegerung zustaendig ist. Wie man das beheben kann, ist eine andere Baustelle.