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: [EMAIL PROTECTED] phone: 925-296-5844 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
