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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users