Sssd not starting- failed

Hi,

I am unable to start sssd as its getting failed with below error.

OS: SLES 11
Version: 3

# uname -r
2.6.32.59-0.7-default
# sssd -d4
ldb: unable to dlopen /usr/lib64/ldb/tdb.so : /usr/lib64/ldb/tdb.so: undefined symbol: tdb_transaction_prepare_commit
# /etc/init.d/sssd restart
Shutting down sssd done
Starting sssd failed
# rpm -qf /usr/lib64/ldb/tdb.so
libldb1-3.6.3-64.1
# rpm -Vv libldb1-3.6.3-64.1
........ /usr/lib64/ldb
........ /usr/lib64/ldb/asq.so
........ /usr/lib64/ldb/ldap.so
........ /usr/lib64/ldb/libldb-cmdline.so
........ /usr/lib64/ldb/paged_results.so
........ /usr/lib64/ldb/paged_searches.so
........ /usr/lib64/ldb/rdn_name.so
........ /usr/lib64/ldb/sample.so
........ /usr/lib64/ldb/server_sort.so
........ /usr/lib64/ldb/skel.so
........ /usr/lib64/ldb/tdb.so
........ /usr/lib64/libldb.so.1
........ /usr/lib64/libldb.so.1.0.2
........ /usr/lib64/libpyldb-util.so.1
........ /usr/lib64/libpyldb-util.so.1.0.2
~:/var/lib #

Could anyone help on this?

Regards,
Sridaran G

Hi,

I would start by looking at the install of SSSD itself. This seems to imply that there is some kind of version mismatch between the functionaltiy that tdb.so is able to provide, and the functionality that your SSSD installation expects it to provide.

How was SSSD installed ? Are you sure the packages are absolutely correct for your version of SLES and libldb ? If you run the ld command on the sssd binary, what output do you get ? My suspicion is that the package or source you've installed SSSD from doesn't quite match the versions of the pre-requisites that are in fact installed on your system.

1 Like

ld or ldd ? I think ldd might be more useful to list expected shared library versions.

2 Likes

Hi,

Sorry, yes - quite right. I'm not having a good day today !

Hello,

Thanks alot for the reply.
Even I was checking for the respective kernel version package and tried installing different sssd version but no luck.

# rpm -qa |grep -i sssd
python-sssd-config-1.9.4-0.26.1
sssd-32bit-1.9.4-0.26.1
sssd-tools-1.9.4-0.26.1
sssd-1.9.4-0.26.1

ldd output:

# ldd /usr/sbin/sssd
        linux-vdso.so.1 =>  (0x00007fff612a5000)
        libnl.so.1 => /lib64/libnl.so.1 (0x00007f3c7b52a000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f3c7b327000)
        libtevent.so.0 => /usr/lib64/libtevent.so.0 (0x00007f3c7b11a000)
        libtalloc.so.2 => /usr/lib64/libtalloc.so.2 (0x00007f3c7af0f000)
        libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f3c7ad06000)
        libldb.so.1 => /usr/lib64/libldb.so.1 (0x00007f3c7aadb000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f3c7a89d000)
        libpcre.so.0 => /usr/lib64/libpcre.so.0 (0x00007f3c7a66d000)
        libini_config.so.2 => /usr/lib64/libini_config.so.2 (0x00007f3c7a463000)
        libcollection.so.2 => /usr/lib64/libcollection.so.2 (0x00007f3c7a257000)
        libdhash.so.1 => /usr/lib64/libdhash.so.1 (0x00007f3c7a053000)
        liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f3c79e43000)
        libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f3c79bfa000)
        libtdb.so.1 => /usr/lib64/libtdb.so.1 (0x00007f3c799ec000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f3c79725000)
        libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007f3c79386000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f3c79182000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f3c78f6b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3c78c0d000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f3c789b7000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f3c787ad000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f3c78572000)
        libpath_utils.so.1 => /usr/lib64/libpath_utils.so.1 (0x00007f3c7836e000)
        libref_array.so.1 => /usr/lib64/libref_array.so.1 (0x00007f3c7816a000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3c77f53000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f3c77d38000)
        libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007f3c77ae1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3c7b7b1000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3c778c4000)

Regards,
Sridaran

Hi,

The major version numbers of your packages seem to be what they should be for SLES 11 SP3, from what I can tell by looking at the relevant Web pages. Could you try completely un-installing all SSSD-related packages, and reinstalling them again from the main SLES package repo for SLES 11 SP3 ?

1 Like

Yes I have tried removing all the sssd packages below and tried reinstalling the grater version and lowerversion but still no luck.....
:confused:
I guess as you mentioned we have to find the relevant version of sssd with respect to libldb1 version.

sssd-32bit-1.9.4-0.26.1
sssd-tools-1.9.4-0.26.1
sssd-1.9.4-0.26.1
libsss

Hi,

You shouldn't really need to try different versions of things, that's what's odd. Whatever comes as standard in the default SLES 11 SP3 repo should work. SSSD and its dependencies certainly seem to be part of the package repository from what I can see. Whatever YaST/zypper gives you should be correct for your distro, as long as you've not done anything non-standard to your configured software repos. Are you just using the default repos for your exact release of SLES, or have you customised them in any way ?

Yes there is a centralized repo server which is updated w.r.t to kernel version 3.0.101, Its not connected to SUSE. I have compared the existing glibc libraries which is lesser version compared with centralized repo.

Also, I tried below:

zypper in -f *sssd*
zypper in -f libldb1
Zypper rm *sssd* -y
zypper rm libldb1
zypper in libldb1
zypper in *sssd* -y

Still same error message.

Hi,

Just to make sure I understand you correctly then, is it the case that your system is running different versions of the kernel and glibc compared to a default SLES 11 SP3 install ?

Repo is with recently available kernel version 3.0.101-0.47.90 but the server is with older kernel which might be causing the issue?

The kernel version are available in SUSE site:
Support | Table of Kernel Versions for SUSE Linux Enterprise Server

Hi,

I don't think the kernel is likely to be suspect here, due to the nature of the error messages you're getting. Still, you could always do an update on the system to bring all packages up to the latest available version and see if that helps.

Fundamentally, some package somewhere in the chain must not be from the same source as the others. If everything was the default SUSE packages, then you wouldn't be getting very unusual messages like this, as they're all designed to work together.

Have you upgraded or replaced any other packages on which these ones depend ? Do you have multiple instances of the same libraries on the system, maybe ? Any funny entries in /etc/ld.so.conf ? Somewhere in the dependency chain or set of packages on your system is something that doesn't belong, and it's causing issues with other things further up the chain, so to speak.

If it comes to it I suppose you could always build SSSD from source, but that would really be a solution of absolute last resort.

1 Like

Hi,

No upgrade has been done on other packages as far as I could see.
ld.so.conf output:

# cat /etc/ld.so.conf
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib64
/usr/lib64/Xaw3d
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/lib/Xaw3d
/usr/x86_64-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/opt/kde3/lib64
include /etc/ld.so.conf.d/*.conf

Also,

# rpm -qR sssd-1.9.4-0.26.1
pam-config
/sbin/ldconfig
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
/bin/sh
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.8)(64bit)
libcares.so.2()(64bit)
libcollection.so.2()(64bit)
libcom_err.so.2()(64bit)
libcrypto.so.0.9.8()(64bit)
libdbus-1.so.3()(64bit)
libdhash.so.1()(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libglib-2.0.so.0()(64bit)
libini_config.so.2()(64bit)
libk5crypto.so.3()(64bit)
libkeyutils.so.1()(64bit)
libkeyutils.so.1(KEYUTILS_0.3)(64bit)
libkrb5.so.3()(64bit)
libkrb5.so.3(krb5_3_MIT)(64bit)
liblber-2.4.so.2()(64bit)
libldap-2.4.so.2()(64bit)
libldb.so.1()(64bit)
libnl.so.1()(64bit)
libpam.so.0()(64bit)
libpam.so.0(LIBPAM_1.0)(64bit)
libpam.so.0(LIBPAM_EXTENSION_1.0)(64bit)
libpam.so.0(LIBPAM_MODUTIL_1.0)(64bit)
libpcre.so.0()(64bit)
libpopt.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.4)(64bit)
libresolv.so.2()(64bit)
libsss_idmap.so.0()(64bit)
libtalloc.so.2()(64bit)
libtdb.so.1()(64bit)
libtevent.so.0()(64bit)
libz.so.1()(64bit)
rpmlib(PayloadIsLzma) <= 4.4.6-1

strace output:

--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7fffe42dad64, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffffffffffff)        = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7f05893529e0}, {0x4356f0, [], SA_RESTORER|SA_RESTART, 0x7f05893529e0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
fcntl(1, F_GETFD)                       = 0
fcntl(1, F_DUPFD, 10)                   = 10
fcntl(1, F_GETFD)                       = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
close(1)                                = 0
dup2(2, 1)                              = 1
fcntl(2, F_GETFD)                       = 0
write(1, "\0337\33[?25l\r\33[155C\33[10D\33[1;31mfaile"..., 46                                                                                  failed
) = 46
close(1)                                = 0
dup2(10, 1)                             = 1
fcntl(10, F_GETFD)                      = 0x1 (flags FD_CLOEXEC)
close(10)                               = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(255, "rc_exit\n\n", 1785)          = 9
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(7)                           = ?

So, better to update the packages excluding kernel?

I am by no means a SuSE-expert but this:

seems not to align all too well with this:

Might it be that there is a 32-bit/64-bit mismatch in oyur libraries and application programs?

I hope this helps.

bakunin

1 Like

Hello,

Thanks for the response!
Actually we have both 32 and 64 as well.

The other package is for 64:

sssd-1.9.4-0.26.1
# rpm -ql sssd-1.9.4-0.26.1|grep -i 64
/lib64/libnss_sss.so.2
/lib64/security/pam_sss.so
/usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so
/usr/lib64/ldb
/usr/lib64/ldb/memberof.so
/usr/lib64/libsss_sudo.so
/usr/lib64/sssd
/usr/lib64/sssd/krb5_child
/usr/lib64/sssd/ldap_child
/usr/lib64/sssd/libsss_krb5.so
/usr/lib64/sssd/libsss_ldap.so
/usr/lib64/sssd/libsss_proxy.so
/usr/lib64/sssd/libsss_simple.so
/usr/lib64/sssd/modules
/usr/lib64/sssd/modules/libsss_autofs.la
/usr/lib64/sssd/modules/libsss_autofs.so
/usr/lib64/sssd/proxy_child
/usr/lib64/sssd/sssd_autofs
/usr/lib64/sssd/sssd_be
/usr/lib64/sssd/sssd_nss
/usr/lib64/sssd/sssd_pam
/usr/lib64/sssd/sssd_ssh
/usr/lib64/sssd/sssd_sudo

I tried by removing 32bit sssd package and re-install 64 only but still same error message.

---------- Post updated at 07:56 PM ---------- Previous update was at 10:01 AM ----------

Hello Guys,

As verified on SUSE portal below SLES 11.3 starts with kernel version 3.0*...... I did not dig deep to check why it has lesser kernel version :frowning:

SUSE/SLES/Kernel versions - MicroFocusInternationalWiki

As far as I know sssd version with 1.5 itself has few bug's and will not start sometime, hence I dropped configuring sssd instead I configured in below steps which worked:

1>install:

zypper in nss_ldap
zypper in pam_ldap
zypper in nscd

2>update nscd (cache) with passwd group and hosts on

/etc/nscd.conf

3>updated

/etc/ldap.con and /etc/openldap/ldap.conf

4> updated

/etc/nsswitch.conf

file with

"files ldap"

in passwd and group

5> updated pam.d common-auth,common-account,common-password and common-session

ldapsearch -x uid=userid and getent passwd userid worked also login worked with LDAP integrated credentails.

Thank you very much for responding/checking on this.