On (14/05/13 23:42), steve wrote:
>On 14/05/13 23:11, Lukas Slebodnik wrote:
>>On (14/05/13 23:00), steve wrote:
>>>Hi
>>>with id_provider=ad, sssd exits after e.g. issuing d <user>
>>>It works fine with id_provider=ldap
>>>
>>>here are te errors with the ad:
>>>
>>>(Tue May 14 22:55:31 2013) [sssd[pam]] [sbus_reconnect] (0x0080):
>>>Making reconnection attempt 3 to
>>>[unix:path=/usr/local/var/lib/sss/pipes/private/sbus-dp_default]
>>>(Tue May 14 22:55:31 2013) [sssd[pam]] [sbus_reconnect] (0x0080):
>>>Reconnected to
>>>[unix:path=/usr/local/var/lib/sss/pipes/private/sbus-dp_default]
>>>(Tue May 14 22:55:31 2013) [sssd[pam]] [pam_dp_reconnect_init]
>>>(0x0020): Reconnected to the Data Provider.
>>>(Tue May 14 22:55:31 2013) [sssd[nss]] [sbus_reconnect] (0x0080):
>>>Making reconnection attempt 3 to
>>>[unix:path=/usr/local/var/lib/sss/pipes/private/sbus-dp_default]
>>>(Tue May 14 22:55:31 2013) [sssd[nss]] [sbus_reconnect] (0x0080):
>>>Reconnected to
>>>[unix:path=/usr/local/var/lib/sss/pipes/private/sbus-dp_default]
>>>(Tue May 14 22:55:31 2013) [sssd[nss]] [nss_dp_reconnect_init]
>>>(0x0020): Reconnected to the Data Provider.
>>>(Tue May 14 22:55:31 2013) [sssd[nss]] [nss_cmd_getby_dp_callback]
>>>(0x0040): Unable to get information from Data Provider
>>>Error: 3, 5, (null)
>>>Will try to return what we have in cache
>>>(Tue May 14 22:55:31 2013) [sssd[be[default]]] [be_run_online_cb]
>>>(0x0080): Going online. Running callbacks.
>>>(Tue May 14 22:55:32 2013) [sssd] [sbus_dispatch] (0x0080):
>>>Connection is not open for dispatching.
>>>(Tue May 14 22:55:32 2013) [sssd[pam]] [sbus_dispatch] (0x0020):
>>>Performing auto-reconnect
>>>(Tue May 14 22:55:32 2013) [sssd[nss]] [sbus_dispatch] (0x0020):
>>>Performing auto-reconnect
>>>(Tue May 14 22:55:32 2013) [sssd] [mt_svc_exit_handler] (0x0040):
>>>Child [default] terminated with signal [11]
>
>>Signal 11 is SIGSEGV and it is bad.
>>Could you generate a backtrace?
>
>(gdb) bt full
>#0  0xb7fdd416 in __kernel_vsyscall ()
>No symbol table info available.
>#1  0xb7d95f18 in epoll_wait () from /lib/i386-linux-gnu/libc.so.6
>No symbol table info available.
>#2  0xb7ee1a8a in ?? () from /usr/lib/i386-linux-gnu/libtevent.so.0
>No symbol table info available.
>#3  0xb7eddef8 in _tevent_loop_once ()
>   from /usr/lib/i386-linux-gnu/libtevent.so.0
>No symbol table info available.
>#4  0xb7ede0cc in tevent_common_loop_wait ()
>   from /usr/lib/i386-linux-gnu/libtevent.so.0
>No symbol table info available.
>#5  0xb7ede167 in _tevent_loop_wait ()
>   from /usr/lib/i386-linux-gnu/libtevent.so.0
>No symbol table info available.
>#6  0xb7f525de in server_loop (main_ctx=0x8070490) at src/util/server.c:602
>No locales.
>#7  0x0804bd65 in main (argc=3, argv=0xbffff804) at
>src/monitor/monitor.c:2801
>        opt = <optimized out>
>        pc = <optimized out>
>        opt_daemon = 0
>        opt_interactive = 1
>        opt_version = 0
>
>How do I build to get the debugging?
>
You have debug symbols in sssd (frame #7,#6), but you don't have debug symbols
in library libtevent (frame #5-#2) and glibc (frame #1,#0)

It seems that either you found bug in libteven or you did not properly generate
backtrace. It is litle bit tricky to debug multi process application.

The best way, how to obtain backtrace is from core dump file.

Core file is not generated by default. You can allow it with command:

sh4.2# ulimit -c unlimited
//then you have to run sssd from the same terminal, debug level is optional in
//this case
sh4.2# sssd -i -d7
//perform action to reproduce bug (segfault)
//New file(core) should be created in current directory
//It is very likely, that core will be generated from sssd_be (I guess)
//You can check it by calling command
sh4.2# file ./core
//you can see similar output from file command
//./core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 
'xterm'
                                                                             
^^^^^^^^
                                                  This information is important
                                                  name_of_segfaulted_process

//run gdb
sh4.2# gdb <name_of_segfaulted_proces> ./core
(gdb) bt full

LS
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to