Greetings,

Could you send me more coredumps privately with fuly updated ubuntu 14.04?
Because it really strange that sssd crashed in syscal fdatasync.
Lukas, not a problem. Stand by for an email with a 7zip archive of a core dump and back trace. The debugging symbols for lib{tdb,ldb}1 were installed for this.

I have another idea which could help us to to find a problem.
We can try to run sssd_be with valgrind.
1) we need to find out arguments for process sssd_be
sh-4.2$ pgrep -af sssd_be
1191 /usr/libexec/sssd/sssd_be --domain idm.example.com --debug-to-files
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     this output will be used in sssd.conf
2) add new option to domain section in sssd.conf
command = valgrind -v --show-reachable=yes --log-file=/var/log/sssd/valgrind_idm.example.com.log /usr/libexec/sssd/sssd_be --domain idm.example.com --debug-to-files
    # do not forget to replace output from previous step.

3) It would be good to install debug symbols for libraries libtdb1 and libldb1
4) reproduce problem
    some interesting output can be in log file from valgrind.
 I did this with interesting(?) results. The sssd_be process never actually crashed but there is some erroneous output in the valgrind log. Removing the special command option results in a crash as expected. I've sanitized and attached the log to this email. Let me know if that reveals anything.


-Chris


On Tue, Aug 12, 2014 at 9:29 AM, Lukas Slebodnik <lslebodn@redhat.com> wrote:
On (08/08/14 14:48), Chris Hartman wrote:
>Hi guys,
>
>If it is a easy to reproduce could you try to mount tmpfs to the directory
>> /var/lib/sss/db/. It can be filesystem issue.
>
>Mounting with a tmpfs has no effect on the crash.
>
>Do you know if Ubuntu uses the latest tdb and ldb versions?
>
>libtdb1 version in Ubuntu 14.04: 1.2.12-1
>libldb1 version in Ubuntu 14.04: 1.1.16-1
>
>According to http://www.samba.org/ftp/tdb/ the latest tbd version is 1.3.0
>and http://www.samba.org/ftp/ldb/ says the latest ldb version is 1.1.17
>
>For full disclosure, I already told this to Jakub in case it matters:
>
>I ran into a little trouble because the sssd_be was the binary that was
>> actually crashing, but it was spawned automatically by the root sssd
>> process. In order to generate the coredump and backtrace, I came up with
>> this inelegant solution:
>>
>> service sssd start; sleep 3; gdb -p $(ps ax|grep sssd_be|grep -v grep|cut
>> -f1 -d" ") -ex generate-core-file
>>
>
>Hope this helps.
>
I have another idea which could help us to to find a problem.
We can try to run sssd_be with valgrind.

1) we need to find out arguments for process sssd_be
sh-4.2$ pgrep -af sssd_be
1191 /usr/libexec/sssd/sssd_be --domain idm.example.com --debug-to-files
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     this output will be used in sssd.conf

2) add new option to domain section in sssd.conf
command = valgrind -v --show-reachable=yes --log-file=/var/log/sssd/valgrind_idm.example.com.log /usr/libexec/sssd/sssd_be --domain idm.example.com --debug-to-files

    # do not forget to replace output from previous step.


3) It would be good to install debug symbols for libraries libtdb1 and libldb1

4) reproduce problem
    some interesting output can be in log file from valgrind.

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