[SSSD-users] Startup segfault loop of domain_be on Ubuntu 14.04

Chris Hartman qrstuv at gmail.com
Fri Aug 8 18:48:12 UTC 2014


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.


-Chris


On Fri, Aug 8, 2014 at 1:16 PM, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Fri, Aug 08, 2014 at 06:49:56PM +0200, Lukas Slebodnik wrote:
> > On (07/08/14 14:57), Chris Hartman wrote:
> > >Sorry it's been so long since my original email. Life happens
> sometimes. At
> > >any rate, I'm able to continue with debugging now.
> > >
> > >First off, thanks to Timo and Lukas for their help! I was able to
> generate
> > >the backtrace and core dump file as Jakub suggested. Since it may
> contain
> > >sensitive data, I will email him the files directly.
> > >
> > >Jakub, look for an email from my momentarily. Thanks for taking the
> time to
> > >help me out!
> > >
> >
> > [New LWP 32083]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> > Core was generated by `/usr/lib/i386-linux-gnu/sssd/sssd_be'.
> > #0  0xb775d424 in __kernel_vsyscall ()
> > (gdb) bt
> > #0  0xb775d424 in __kernel_vsyscall ()
> > #1  0xb7520d7c in __fdatasync_nocancel () at
> ../sysdeps/unix/syscall-template.S:81
> > #2  0xb6af2be5 in transaction_sync (tdb=0x8b2a138, offset=53268,
> length=4) at ../common/transaction.c:548
> > #3  0xb6af2d9e in _tdb_transaction_cancel (tdb=0x8b2a138) at
> ../common/transaction.c:603
> > #4  0xb6af3c95 in tdb_transaction_commit (tdb=0x8b2a138) at
> ../common/transaction.c:1161
> > #5  0xb6b172d5 in ltdb_end_trans (module=0x8b2b9b0) at
> ../ldb_tdb/ldb_tdb.c:1141
> > #6  0xb770aedf in ldb_transaction_commit (ldb=ldb at entry=0x8b20a78) at
> ../common/ldb.c:467
> > #7  0xb770be49 in ldb_autotransaction_request (ldb=0x8b20a78,
> req=0x8b38500) at ../common/ldb.c:563
> > #8  0xb770ca43 in ldb_modify (ldb=0x8b20a78, message=message at entry=0x8b49380)
> at ../common/ldb.c:1641
> >
> > I am not really sure why but crash is in syscall fdatasync.
> > As you can see, top 9 frames are from libraries libldb and libtdb.
> > 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.
> >
> > tmpfs   /var/lib/sss/db/ tmpfs
>  size=300M,mode=0700,noauto 0 0
> >
>
> Thanks for looking into this!
>
> Did you notice anything strange about the ldb_message in frame 8? That's
> the only thing I can think of that we might influence.
>
> Do you know if Ubuntu uses the latest tdb and ldb versions?
> _______________________________________________
> sssd-users mailing list
> sssd-users at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20140808/030d753a/attachment-0001.html>


More information about the sssd-users mailing list