Univention Bugzilla – Bug 25246
UCS 3.0 RC1 Installer hängt beim LDAP join
Last modified: 2017-08-08 07:07:36 CEST
Created attachment 3977 [details] installer.log Ich versuche gerade, UCS 3.0 in einer KVM VM zu installieren. Seit mittlerweile einer Viertelstunde hängt das System bei 95,5% Fortschritt bzw. beim Skript 10univention-ldap-server.inst. Kein Fortschritt, VM läuft auf 100% CPU. Der Prozess der diese hohe Last erzeugt ist python2.6, genauer gesagt /usr/bin/python2.6 /usr/bin/univention-config-registry set ldap/hostdn=cn=ucs30rc1,cn=dc,cn=computers,dc=kvm,dc=local
Created attachment 3978 [details] progress.log
Created attachment 3979 [details] installation_profile
Bitte noch /var/log/univention/join.log anhängen. Auf welcher Plattform wird KVM eingesetzt und mit welchem Kernel?
Created attachment 3983 [details] join.log Auf Fedora 15 mit Kernel 2.6.41.1. $ rpm -q kernel libvirt qemu-kvm kernel-2.6.40.4-5.fc15.x86_64 kernel-2.6.40.6-0.fc15.x86_64 kernel-2.6.41.1-1.fc15.x86_64 libvirt-0.8.8-7.fc15.x86_64 qemu-kvm-0.14.0-8.fc15.x86_64
Da wir noch eine Anpassung im Kernel nach dem RC1 hatten, hier nochmal aktuelle DVDs: http://testing.univention.de/download/UCS-3.0-test/ Kannst du es damit nochmal testen?
Wir haben es hier auf einem System mit Fedora 15 nochmal getestet und konnte es mit der finalen Version und der letzten Testversion nicht reproduzieren. Reagiert die VM noch oder hängt die gesamte Maschine?
Die VM läuft noch, ich kann an einer anderen Konsole noch arbeiten, allerdings schleppend wegen der hohen Load. Momentan lade ich gerade die 3.0 Final runter und werde es damit nochmal testen. Beides sind überigens 64bit Systeme, sowohl die VM als auch der Host.
(In reply to comment #7) > Die VM läuft noch, ich kann an einer anderen Konsole noch arbeiten, allerdings > schleppend wegen der hohen Load. > > Momentan lade ich gerade die 3.0 Final runter und werde es damit nochmal > testen. Beides sind überigens 64bit Systeme, sowohl die VM als auch der Host. In unserem Test hatten wir auch für beides 64bit. Könntest du vielleicht strace installieren und einmal nachschauen, wo der Prozess hängt?
So, jetzt habe ich es auf unserer Infrastruktur probiert, Server läuft mit Centos 6.2 Final. Wieder hängt der Installer lange (jetzt seit 20 Minuten) bei 95,5%, aber er arbeitet die Joinscripts ab. Der Prozess mit der hohen Last ist diese Mal /usr/bin/python2.6 /usr/sbin/univention-management-console-web-server start und ein strace darauf ergibt Unmengen von gettimeofday({1324924593, 774682}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) gettimeofday({1324924593, 875059}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) gettimeofday({1324924593, 975676}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) gettimeofday({1324924594, 76087}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) gettimeofday({1324924594, 176460}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) gettimeofday({1324924594, 276887}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) gettimeofday({1324924594, 377275}, NULL) = 0 Aber die Installation läuft weiter, nur unwahrscheinlich langsam und mit extremer Load.
Created attachment 4051 [details] print traceback of running python process (In reply to comment #9) > Der Prozess mit der hohen Last ist diese Mal > /usr/bin/python2.6 /usr/sbin/univention-management-console-web-server start > und ein strace darauf ergibt Unmengen von > > select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) Hier wird select() als eine portable Implementierung für sleep(0.1s) benutzt, da das klassische sleep() nur mit einer ganzzahligen Sekundenangabe funktioniert. Solch ein sleep() oder select() kommt nicht direkt im UMC-Server vor, sondern wird entweder intern irgendwo im Python-Interpreter und dessen Laufzeitumgebung verwendet, oder kann auch von einer der vielen Bibliotheken verwendet werden; von daher hilft die Erkenntnis aus dem strace hier auch nicht direkt weiter. Für eine weitere Diagnose wäre ein Backtrace aus gdb heraus hilfreich: Dazu muß das Paket "gdb" installiert sein, die Pakete "libc6-dbg" und "python3.0-dbg" sollten zusätzlich für aussagekräftige Ausgaben installiert sein. Anschließend den Debugger per "gdb -p $pid -batch -n -ex 'set pagination off' -ex 'thread apply all bt'" mit dem Prozeß verbinden und einen Stack-Trace aller Threads erzeugen. Für Python-Programme geht das noch besser mit dem angehängten Skript, da dieses dann auch direkt die Python-Funktionen anzeigt. Ein ähnliches Phänomen hatte ich auch schon mal beobachtet, als die Netzwerkverbindung nicht funktionierte und verschiedene PAM-und NSS-Bibliotheken dann hingen. Da das Problem auch vorher schon bei UCR auftrat, würde ich einen Fehler in UCR und UMC selber erstmal ausschließen. > Aber die Installation läuft weiter, nur unwahrscheinlich langsam und mit > extremer Load. Der verursachende Prozeß kann per "kill -STOP $pid" angehalten und später per "kill -CONT $pid" fortgesetzt werden, was zumindest den Durchlauf der Join-Skripte beschleunigen sollte.
(In reply to comment #10) > Für eine weitere Diagnose wäre ein Backtrace aus gdb heraus hilfreich: [...] > Für Python-Programme geht das noch besser mit dem angehängten Skript, da dieses > dann auch direkt die Python-Funktionen anzeigt. Danke, werde ich später mal durchführen. > Ein ähnliches Phänomen hatte ich auch schon mal beobachtet, als die > Netzwerkverbindung nicht funktionierte und verschiedene PAM-und > NSS-Bibliotheken dann hingen. Meinst Du ein Netzwerkproblem des Hosts oder des Gasts? Jetzt wo Du es erwähnst, fällt mir nämlich ein, dass bei mir libvirt einige Probleme mit der Netzwerkkonfiguration hatte, siehe https://bugzilla.redhat.com/show_bug.cgi?id=746960 Das könnte vielleicht erklären, dass es auf unserem KVM Server lief, aber nicht auf meinem Laptop. > Da das Problem auch vorher schon bei UCR auftrat, würde ich einen Fehler in UCR > und UMC selber erstmal ausschließen. Ja, ich denke dass es ein Problem mit allen Python-Programmen ist und dieser bug und bug 25247 nur unterschiedliche Symptome dessen.
(In reply to comment #11) > (In reply to comment #10) > Meinst Du ein Netzwerkproblem des Hosts oder des Gasts? Beides: Wichtig ist hier, daß der Gast ein funktionierende Netzwerkverbindung hat. Wenn der Host schon Probleme hat, dann kann das mit dem Gast schon nichts werden. > Jetzt wo Du es erwähnst, fällt mir nämlich ein, dass bei mir libvirt einige > Probleme mit der Netzwerkkonfiguration hatte, siehe > https://bugzilla.redhat.com/show_bug.cgi?id=746960 Das könnte vielleicht > erklären, dass es auf unserem KVM Server lief, aber nicht auf meinem Laptop. Das erklärt auch ein bisschen, warum wir das bei unseren natürlich mit UCS laufenden Servern nie beobachtet haben: Unter UCS (und Debian) gibt es kein netcf für die Konfiguration der Netzwerkeinstellungen, was von libvirt verwendet wird. > Ja, ich denke dass es ein Problem mit allen Python-Programmen ist und dieser > bug und bug 25247 nur unterschiedliche Symptome dessen. Wichtig wäre hier eben der Backtrace der "hängenden" Prozesse, damit klar wird, in welchem Code-Pfad das Problem auftritt. Der häufige select()-Aufruf alleine gibt leider nicht genügend Informationen her, als das man damit die problematische Stelle finden könnte. Fehlende Netzverbindungen haben in der Vergangenheit in Verbindung mit PAM öfters zu sehr langen Verzögerungen geführt, insbesondere wenn das Netzwerk zwar "irgendwie" bereits konfiguriert war, aber eben nicht funktioniert hat und Pakete ins Nirvana umgeleitet wurden.
Nicht critical. Tritt das Problem mit UCS 3.1 noch auf?
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
This issue has been filed against UCS 3.0. UCS 3.0 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" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.