Frage: Ist der leap-second-bug im aktuellen Kernel 64-bit für UCS 2.4-4.9 bzw. 3.2-0.9 (beide haben den gleichen Kernel) beschrieben unter
https://lkml.org/lkml/2012/7/1/27,
aufgetaucht ca. Sun, 1 Jul 2012 05:36:11 -0400,
behoben bzw. behandelt in UCS ? (kann eigentlich nicht, da der Univention-Kernel vorher gebaut wurde).
Hintergrund: Eine nicht sonderlich häufig genutzte java-Applikation (OX-Webinterface) zieht seit langem teilweise viel CPU, auch wenn sich kein Benutzer angemeldet hat. Wenn sich mehrere Benutzer anmelden (wie Freitag geschehen) stellt das Programm den Dienst ein. Ein strace-dump im “Ruhezustand” aller zum Prozess gehörenden Threads/LWPs/Unterprozesse (?) findet man im Anhang. strace -fp 31361 -o /tmp/java_strace_fp.log
Dort ist auch erkennbar, dass die futex()-Aufrufe mit ETIMEOUT zurückkehren, was nicht passieren sollte und die Ursache für die CPU-Last sein soll.
[quote=“saacke”]Frage: Ist der leap-second-bug im aktuellen Kernel 64-bit für UCS 2.4-4.9 bzw. 3.2-0.9 (beide haben den gleichen Kernel) beschrieben unter
https://lkml.org/lkml/2012/7/1/27,
aufgetaucht ca. Sun, 1 Jul 2012 05:36:11 -0400,
behoben bzw. behandelt in UCS ? (kann eigentlich nicht, da der Univention-Kernel vorher gebaut wurde).
[/quote]
Kurz generell: UCS 2.4-4-9 und UCS 3.2-0 haben nicht den gleichen “aktuellen” Kernel.
Das ist der aktuellste Linux Kernel für UCS 2.4 - er basiert auf 2.6.32-41.
Die Regression die zu diesem Verhalten führen konnte wurde erst mit Kernel 2.6.32-45 eingebaut und mit Kernel 2.6.32-46 direkt wieder behoben. In UCS 2.4-4-9 kommt Kernel 2.6.32-41 zum Einsatz - das Verhalten bestand dort also zu keinem Zeitpunkt.
Danke für die Antwort. Dann kann der leap-second-bug nicht die Ursache sein.
Aber das Update von UCS 2.4 auf 3.2 auf dem Testsystem hat dann bei uns auch nicht korrekt funktioniert, da dort immer noch Kernel 2. 6.32 gemeldet wird.
root@ox:~# ssh ox4ucs24
Password:
Univention DC Master 3.2-0:
The UCS management system is available at https://ox4ucs24.saacke.de/ (192.168.98.16)
You can log into the Univention Management Console - the principal tool to manage
users, groups, etc. - using the "Administrator" account and the password selected
for the root user on the master domain controller.
Last login: Mon Dec 23 19:42:13 2013 from lnxedv.saacke.de
root@ox4ucs24:~# pwd
/root
root@ox4ucs24:~# uname -a
Linux ox4ucs24 2.6.32-ucs62-amd64 #1 SMP Mon Apr 23 18:58:05 UTC 2012 x86_64 GNU/Linux
root@ox4ucs24:~# who -r
Runlevel 2 2013-12-03 21:05 last=S
root@ox4ucs24:~# cd /boot
root@ox4ucs24:/boot# ls -ltr
insgesamt 18953
drwx------ 2 root root 12288 28. Apr 2010 lost+found
-rw-r--r-- 1 root root 167264 18. Sep 2011 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 165084 18. Sep 2011 memtest86+.bin
-rw-r--r-- 1 root root 2511104 23. Apr 2012 vmlinuz-2.6.32-ucs62-amd64
-rw-r--r-- 1 root root 1712194 23. Apr 2012 System.map-2.6.32-ucs62-amd64
-rw-r--r-- 1 root root 106189 23. Apr 2012 config-2.6.32-ucs62-amd64
-rw-r--r-- 1 root root 14640684 1. Dez 23:07 initrd.img-2.6.32-ucs62-amd64
drwxr-xr-x 5 root root 7168 3. Dez 19:43 grub
-rw-r--r-- 1 root root 318 3. Dez 19:43 boot.msg
sie können einmal folgendermaßen schauen, ob weitere Kernel installiert aber u.U. nicht vollständig eingerichtet wurden:
dpkg -l linux-image*
dpkg -l univention-kernel-image
dpkg -C
Wurde das Update ohne weitere Auffälligkeiten durchgeführt und das System anschließend neugestartet?
Generell können Sie den Updateverlauf in den entsprechenden Logdateien nachvollziehen:
/var/log/univention/updater.log*
Hier sollten sich entsprechende Hinweise finden lassen.