Leap-second-bug Jul 2012

UCS - Univention Corporate Server
#1

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).

Kerneldatei (sowohl von 2.4 als auch von 3.2)

-rw-r--r-- 1 root root  2511104 23. Apr 2012  vmlinuz-2.6.32-ucs62-amd64

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.

Der bei Novell http://www.novell.com/support/kb/doc.php?id=7010351 zu diesem Thema beschreibene Workaround

date -s “$(LC_ALL=C date)”

scheint keinerlei Wirkung zu haben.
java_strace_fp.log (9.27 KB)

#2

Hallo!

[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.

Dies ist der aktuellste Kernel mit UCS 3.2:

-rw-r--r-- 1 root root 3268896 10. Okt 20:51 vmlinuz-3.10.0-ucs43-amd64 root@master:~# uname -a Linux master 3.10.0-ucs43-amd64 #1 SMP Debian 3.10.11-1.43.201310101020 (2013-10-10) x86_64 GNU/Linux

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.

Mit freundlichen Grüßen,
Tim Petersen

#3

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
#4

Hallo,

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.

Mit freundlichen Grüßen,
Tim Petersen

Mastodon