Nach dem Einspielen der OXSE Lizenz werden durch den Listener UCR Variablen gesetzt, dadurch werden Scripte ausgeführt. Diese Prozesse verbleiben dann als Zombie Prozesse im System. 0 ? Z 13:50 0:00 [ox-selector.sh] <defunct> 0 ? Z 13:50 0:00 [ox-branding-swi] <defunct> 0 ? Z 13:50 0:00 [ox-udm-modules-] <defunct> Scheint aber ein generelleres Problem zu sein. Ich habe es einmal mit einem ganz einfachen Skript getestet #!/bin/bash date >> /tmp/x gebunden an die Variable "univention-ox-directory-integration/oxae". Auch diese Skript hinterlässt einen Zombie.
Zomie-Prozesse sind Prozesse, die sich bereits selber beendet haben, aber vom Vater-Prozeß noch nicht vollständig beerdigt wurden; dort fehlt ein wait(). Von daher ist hier interessant, welches der Vater-Prozeß dieser Zombie-Prozesse ist: "ps -l" zeigt es z.B. in der Spalte PPID (=Parent Prozess Identifier) an. Oder aus ASCII-grafisch in "ps axf".
Created attachment 2991 [details] ps axf
Vermutlich nutzen die Module die run(file, argv, wait=False)-Funktionalität aus ucs/management/univention-directory-listener/python/listener.py: Dadurch wird ein Prozeß abgespalten, auf den dann niemand mehr wartet. Eigentlich müsste das aufrufende Listener-Modul das zugehörige wait() machen, aber das widerspricht dem eigentlichen Gedanken hinter wait=False: Starte einen länger andauernden Prozeß, der im Hintergrund seine Aufgabe erledigt; der Listener hat damit seine Aufgabe erledigt und kann zurückkehren. Deswegen sollte der Listener selber einen Signal-Handler für SIGCHLD installieren: Dieser wird aufgerufen, wenn ein Kind stirbt. Dann sollte dieses durch den Aufruf waitpid() endgültig beerdigt werden. Siehe <http://www.steve.org.uk/Reference/Unix/faq_toc.html#TOC83> oder <http://mail.python.org/pipermail/tutor/2003-December/026748.html> oder <http://www.win.tue.nl/~aeb/linux/lk/lk-5.html> Allerdings ist dabei zu beachten, das für wait=True-Prozesse das ganze weiterhin funktioniert. Für die Probleme dabei siehe dazu unbedingt <http://bugs.python.org/issue9127> Derhalb ist vermutlich sowas zu implementieren: 1. Wenn der Handler gerade läuft und Python-Interpreter aufruft, dann SIGCHLD (vom Python-Interpreter) behandeln lassen. 2. Ansonsten SIGCHLD ignorieren oder bei Auftreten Zombies einsammeln.
*** Bug 24636 has been marked as a duplicate of this bug. ***
22859 ? S 0:11 | \_ /usr/sbin/univention-directory-listener -F -b dc=phahn,dc=dev -m /usr/lib/u 30517 ? Z 0:00 | \_ [univention-virt] <defunct> 30518 ? Z 0:00 | \_ [univention-virt] <defunct> 30519 ? Z 0:00 | \_ [univention-virt] <defunct> 30520 ? Z 0:00 | \_ [univention-virt] <defunct> 30521 ? Z 0:00 | \_ [univention-virt] <defunct> 30522 ? Z 0:00 | \_ [univention-virt] <defunct> 30523 ? Z 0:00 | \_ [univention-virt] <defunct> 30524 ? Z 0:00 | \_ [univention-virt] <defunct> 30525 ? Z 0:00 | \_ [univention-virt] <defunct> 30526 ? Z 0:00 | \_ [univention-virt] <defunct> 30527 ? Z 0:00 | \_ [univention-virt] <defunct> 30528 ? Z 0:00 | \_ [univention-virt] <defunct> 30529 ? Z 0:00 | \_ [univention-virt] <defunct> 30530 ? Z 0:00 | \_ [univention-virt] <defunct> 30531 ? Z 0:00 | \_ [univention-virt] <defunct> 30532 ? Z 0:00 | \_ [univention-virt] <defunct> 30533 ? Z 0:00 | \_ [univention-virt] <defunct> 30534 ? Z 0:00 | \_ [univention-virt] <defunct> 30535 ? Z 0:00 | \_ [univention-virt] <defunct> 30536 ? Z 0:00 | \_ [univention-virt] <defunct> 30551 ? Z 0:00 | \_ [univention-virt] <defunct> 30552 ? Z 0:00 | \_ [univention-virt] <defunct> 30553 ? Z 0:00 | \_ [univention-virt] <defunct> 30554 ? Z 0:00 | \_ [univention-virt] <defunct> 30563 ? Z 0:00 | \_ [univention-virt] <defunct> 30572 ? Z 0:00 | \_ [univention-virt] <defunct> 30573 ? Z 0:00 | \_ [univention-virt] <defunct> 30574 ? Z 0:00 | \_ [univention-virt] <defunct> 30575 ? Z 0:00 | \_ [univention-virt] <defunct> 30615 ? Z 0:00 | \_ [univention-virt] <defunct> 30618 ? Z 0:00 | \_ [univention-virt] <defunct> 30619 ? Z 0:00 | \_ [univention-virt] <defunct> 30652 ? Z 0:00 | \_ [univention-virt] <defunct> 30654 ? Z 0:00 | \_ [univention-virt] <defunct> 30655 ? Z 0:00 | \_ [univention-virt] <defunct> 30656 ? Z 0:00 | \_ [univention-virt] <defunct> 30657 ? Z 0:00 | \_ [univention-virt] <defunct> 30658 ? Z 0:00 | \_ [univention-virt] <defunct> 30659 ? Z 0:00 | \_ [univention-virt] <defunct> 30660 ? Z 0:00 | \_ [univention-virt] <defunct> 30661 ? Z 0:00 | \_ [univention-virt] <defunct> 30662 ? Z 0:00 | \_ [univention-virt] <defunct> 30663 ? Z 0:00 | \_ [univention-virt] <defunct> 30670 ? Z 0:00 | \_ [univention-virt] <defunct> 30680 ? Z 0:00 | \_ [univention-virt] <defunct> 30708 ? Z 0:00 | \_ [univention-virt] <defunct> 30710 ? Z 0:00 | \_ [univention-virt] <defunct> 30711 ? Z 0:00 | \_ [univention-virt] <defunct>
This issue has been filed against UCS 2.4. UCS 2.4 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug". In this case please provide detailed information on how this issue is affecting you.