Re: ldap problem
On Fri, Jun 24, 2005 at 09:00:03AM +0200, Niklas gren wrote:
> >I've uninstalled nscd altogether, but that doesn't seem to be the
> >problem. I've also compiled the latest ssh. It hangs in the same
> >place, which only makes me believe that its pam even more.
> >
> >I forgot to mention that it hangs, but doesn't die. After about an
> >hour or so, the session completes and the user is logged in normally.
> >It must be a timeout issue of some sort, but I have no idea what it's
> >hanging on.
>
> Run the process that hangs (sshd?) in gdb, and do a backtrace. May give
> some clues. Maybe you need the source to sshd and pam, and maybe you need
> to recompile for that.. but it's easy to do this step by step.
Hi,
Here's the backtrace when connecting via ssh:
(gdb) bt
#0 0x00002aaaab6466c2 in read () from /lib/libc.so.6
#1 0x00002aaaabb29b4b in ber_int_sb_write () from /usr/lib/liblber.so.2
#2 0x00002aaaabb2a2d6 in ber_int_sb_write () from /usr/lib/liblber.so.2
#3 0x00002aaaaba0f681 in ldap_pvt_tls_init_def_ctx () from /usr/lib/libldap_r.so.2
#4 0x00002aaaabd65d25 in _gnutls_handshake_buffer_clear () from /usr/lib/libgnutls.so.11
#5 0x00002aaaabd6492c in _gnutls_io_read_buffered () from /usr/lib/libgnutls.so.11
#6 0x00002aaaabd628eb in _gnutls_recv_int () from /usr/lib/libgnutls.so.11
#7 0x00002aaaabd6232f in gnutls_bye () from /usr/lib/libgnutls.so.11
#8 0x00002aaaaba11949 in gnutls_SSL_shutdown () from /usr/lib/libldap_r.so.2
#9 0x00002aaaaba0f33a in ldap_pvt_tls_init_def_ctx () from /usr/lib/libldap_r.so.2
#10 0x00002aaaabb29874 in ber_int_sb_close () from /usr/lib/liblber.so.2
#11 0x00002aaaabb29114 in ber_sockbuf_free () from /usr/lib/liblber.so.2
#12 0x00002aaaab9fbf18 in ldap_ld_free () from /usr/lib/libldap_r.so.2
#13 0x00002aaaab8cd9c5 in do_close_no_unbind () at ldap-nss.c:912
#14 0x00002aaaab8cd669 in do_atfork_child () at ldap-nss.c:513
#15 0x00002aaaab62b4e6 in fork () from /lib/libc.so.6
#16 0x0000000000410719 in do_exec_pty (s=0x557a60, command=0x0) at session.c:548
#17 0x0000000000410971 in do_exec (s=0x557a60, command=0x0) at session.c:681
#18 0x00000000004123db in session_shell_req (s=0x557a60) at session.c:1857
#19 0x00000000004127f4 in session_input_channel_req (c=0x5b05e0, rtype=0x596180 "shell") at session.c:1956
#20 0x000000000040dac1 in server_input_channel_req (type=4, seq=5968160, ctxt=0x5) at serverloop.c:1033
#21 0x000000000042dd97 in dispatch_run (mode=1, done=0x0, ctxt=0x55c520) at dispatch.c:93
#22 0x000000000040d2f9 in server_loop2 (authctxt=0x4) at serverloop.c:760
#23 0x000000000041013e in do_authenticated (authctxt=0x55c4a0) at session.c:225
#24 0x0000000000407a1f in main (ac=0, av=0x1) at sshd.c:1723
This might actually point to our directory server. I'll see about
patching it to see if that helps anything.
--
Sincerely,
Matt Dunford
Unix Systems Administrator
DOE Joint Genome Institute
url: http://www.jgi.doe.gov
email: madunford@lbl.gov
phone: 925-296-5844
Reply to: