sssd will not start since upgrade, but crashes instead

English Install/Boot/Login
1

Hostname replaced with localhost:

localhost:/home/oper # systemctl start sssd
Job for sssd.service failed because the control process exited with error code.
See “systemctl status sssd.service” and “journalctl -xe” for details.
localhost:/home/oper # systemctl status sssd.service
● sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2018-10-11 09:43:52 EDT; 14s ago
Process: 4224 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=1/FAILURE)

Oct 11 09:43:48 localhost sssd[be[4239]: Starting up
Oct 11 09:43:51 localhost sssd[4245]: Starting up
Oct 11 09:43:51 localhost sssd[4246]: Starting up
Oct 11 09:43:51 localhost sssd[4248]: Starting up
Oct 11 09:43:51 localhost sssd[4249]: Starting up
Oct 11 09:43:52 localhost sssd[be[4250]: Starting up
Oct 11 09:43:52 localhost sssd[4225]: Exiting the SSSD. Could not restart critical service [4ccompany].
Oct 11 09:43:52 localhost systemd[1]: sssd.service: Control process exited, code=exited status=1
Oct 11 09:43:52 localhost systemd[1]: sssd.service: Failed with result ‘exit-code’.
Oct 11 09:43:52 localhost systemd[1]: Failed to start System Security Services Daemon.
localhost:/home/oper # journalctl -xe
Oct 11 09:43:51 localhost sssd[4246]: Starting up
Oct 11 09:43:51 localhost sssd[4248]: Starting up
Oct 11 09:43:51 localhost sssd[4249]: Starting up
Oct 11 09:43:52 localhost sssd[be[4250]: Starting up
Oct 11 09:43:52 localhost systemd[1]: Started Process Core Dump (PID 4251/UID 0).
– Subject: Unit systemd-coredump@13-4251-0.service has finished start-up
– Defined-By: systemd
– Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

– Unit systemd-coredump@13-4251-0.service has finished starting up.

– The start-up result is RESULT.
Oct 11 09:43:52 localhost sssd[4225]: Exiting the SSSD. Could not restart critical service [4ccompany].
Oct 11 09:43:52 localhost systemd[1]: sssd.service: Control process exited, code=exited status=1
Oct 11 09:43:52 localhost systemd[1]: sssd.service: Failed with result ‘exit-code’.
Oct 11 09:43:52 localhost systemd[1]: Failed to start System Security Services Daemon.
– Subject: Unit sssd.service has failed
– Defined-By: systemd
– Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel

– Unit sssd.service has failed.

– The result is RESULT.
Oct 11 09:43:52 localhost systemd-coredump[4252]: Process 4250 (sssd_be) of user 0 dumped core.
– Subject: Process 4250 (sssd_be) dumped core
– Defined-By: systemd
– Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
– Documentation: man:core(5)

– Process 4250 (sssd_be) crashed and dumped core.

– This usually indicates a programming error in the crashing program and
– should be reported to its vendor as a bug.

2

Additionally, because sssd is unavailable, I tried going back to basic LDAP authentication, but the pam-ldap package is not available, so that isn’t an option.

3

jona2402,
This is unusual as the daemon is quite stable.

Please forgive the request a basic check.

The permissions on the /etc/sssd/sssd.conf are 0600?

Aside from that:

  • Delete all files from the /var/lib/sss/db and /var/log/sssd directories.
  • Add the “debug_level = 7” directive to the domain stanza(s) in the sssd.conf file.
  • Attempt to start the daemon and review all logs.

Generally the best info will be at the end of the log, hopefully you won’t have to parse the entire log for meaningful information (but you might).

Could you also post a sanitised version of your sssd.conf file?

– lawrence

4

Hi,

That information can be found here: https://bugzilla.opensuse.org/show_bug.cgi?id=1112047
in the attachment.

I had tried clearing the cache etc and running at debug level 9.

Unfortunately, it is too large to paste into a forum reply…

Thanks!

5

You can use paste.opensuse.org and post the resulting link here.

6

http://paste.opensuse.org/45114976

7

jona2402,
Looking at the info you posted my first thought is that perhaps there is a TLS issue, or possibly even a certificate issue.

You can test your certificate using the ldapsearch utility to perform a SSL, and TLS based searches against your back end (the -ZZZ argument will force a TLS connection). The daemon should default to attempting to make a TLS connection, but fallback to SSL if unsuccessful. However without specifying a ldaps:// URI that too will likely fail as the ldap:// URI will require a TLS connection (the default value for the “ldap_id_use_start_tls” directive is “false”).

Perhaps the next steps should be to assess if there is a certificate issue and resolve it, or resolve the TLS issue, or explicitly specify a SSL connection.

– lawrence

8

Hi,

Thanks for this, however, the configuration worked perfectly with TLS prior to the installing the update. Additionally, sssd crashes on start up and it shouldn’t even notice that there is a comms problem until the first authentication type request is posted.

Given that the next update blew even more services out of the water, I have, for the time being, switched the machine to Leap.

–
/jona.