Univention Bugzilla – Bug 26875
Prozeß (konsole) hängt in libnss_ldap nach Netzwerk-Änderung (WLAN → Ethernet), Timeout bei IP-Adress-Änderung?
Last modified: 2018-04-14 13:43:51 CEST
Nach einstecken des kabelgebundenen Ethernets und abschalten des WLANs hing der konsole-Prozeß und alle darin laufenden Shell-Sitzungen waren nicht mehr nutzbar (X11-Fenster wurde nicht mehr neu gezeichnet). Gewissen Ähnlichkeiten zu Bug #25246 sind erkennbar, auch wenn der UCS-3.0 betrifft. $ strace -f -p 386 Process 393 attached with 2 threads - interrupt to quit [pid 393] select(7, [6], NULL, NULL, NULL <unfinished ...> [pid 386] restart_syscall(<... resuming interrupted call ...>^C <unfinished ...> Process 386 detached Process 393 detached $ gdb -p 386 (gdb) thread 2 [Switching to thread 2 (Thread 0xb3d6bb90 (LWP 393))]#0 0xb7890424 in __kernel_vsyscall () (gdb) bt #0 0xb7890424 in __kernel_vsyscall () #1 0xb77e3bf1 in select () from /lib/i686/cmov/libc.so.6 #2 0xb6ed0a9e in ?? () from /usr/lib/libQtCore.so.4 #3 0xb6df499e in ?? () from /usr/lib/libQtCore.so.4 #4 0xb5adc4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #5 0xb77eb84e in clone () from /lib/i686/cmov/libc.so.6 (gdb) thread 1 [Switching to thread 1 (Thread 0xb54806c0 (LWP 386))]#0 0xb7890424 in __kernel_vsyscall () (gdb) bt #0 0xb7890424 in __kernel_vsyscall () #1 0xb77e0fa7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xb2e6a555 in ldap_int_select () from /usr/lib/libldap_r-2.4.so.2 #3 0xb2e53856 in ldap_result () from /usr/lib/libldap_r-2.4.so.2 #4 0xb2e5692a in ldap_search_st () from /usr/lib/libldap_r-2.4.so.2 #5 0xb2e9094b in ?? () from /lib/libnss_ldap.so.2 #6 0x095251c8 in ?? () #7 0xb2e9c8b5 in ?? () from /lib/libnss_ldap.so.2 #8 0x00000002 in ?? () #9 0xbfc51dbc in ?? () #10 0xb2e9d640 in ?? () from /lib/libnss_ldap.so.2 #11 0x00000000 in ?? () (gdb) $ lsof -p 386 ... konsole 386 phahn 6r FIFO 0,8 11836022 pipe konsole 386 phahn 7w FIFO 0,8 11836022 pipe ... Das sieht nach dem Self-Pipe-Trick aus, um zwischen Threads Events per select() zu handhaben. Heute (nach 16 Stunden im Suspend-to-RAM) ist der Prozeß dann übrigens wieder aufgewacht, genau so wie eine gestern versucht zu startende 2. Konsole dann eben erschien. Sieht nach einem Timeout-Problem aus, wenn sich die IP-Adresse ändert.
Das Problem scheint zu sein, daß auf meinen Notebook der nscd nicht mehr lief. Prozesse, die den NSS benutzen, öffnen dann alle selbständige eine eigene Verbindung zum LDAP-Server. Durch das Umschalten der von WLAN auf Ethernet ändert sich dann die IP-Adresse, so daß die TCP-Verbindungen ungültig werden und erstmal in ein Timeout laufen. Solange hängen die Prozesse. <http://keymon.wordpress.com/2010/08/19/linux-nss-libnss-and-nss_ldap-problems-and-possible-solutions/> beschreibt das Problem recht gut und nennt auch ein paar Alternativen: nss-pam-ldapd, unscd, nsscache
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.
Fixed by Bug #40968?