infinite loop on start if misconfigured

Thank you for taking the time to report this bug and helping to make Ubuntu
better.

This bug is present in Debian as well and Ubuntu currently does not make any
changes to the Debian package. Therefore, this bug would be best fixed
directly in Debian, and then Ubuntu will pick up the fix automatically.

Would you mind filing a bug with Debian please?

----

Debian uses a bug tracker a little different than Launchpad. As an example,
assuming the source package we are interested in is 'vim', you can find
the Debian bug tracker for vim here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=vim

You can file a bug via email by sending mail to: <email address hidden>
The body of the email needs to contain everything between the --- below:
---
Package: vim
Version: your_version_here

Your details, explanation, and steps to reproduce go below those two lines,
Package and Version, which are required.
---

You can read more here about filing bugs in Debian here:
https://www.debian.org/Bugs/Reporting

Hope that helps!

I have the same problem in Groovy Gorrillaa

Is it really an "infinite" loop? Afaik this is caused by "Restart=on-failure" in the [Service] section of sssd.service, and systemd will eventually backoff and give up on the restarts.

Alternatively, I wonder if it's an effect of the socket activation. nss calls on the system keep waking up the service, which tries to start, and fails. @timo, any opinion?

Ian, can you try disabling the sockets? Something like "systemctl disable sssd-nss.socket sssd-pam.socket" and so on for all *.socket services, leave just "sssd.service" (note .service) enabled, and add "services = nss,pam" to /etc/sssd/sssd.conf in the global section? That will tell sssd to start these backend services by itself.

I can confirm this bug for me on 20.04 and confirm an infinite loop. Even if sssd service is not working it should be skipped and at least local users should be able to login!

Wow at least I wasn't doing anything on a production machine. Been a while since something as catastrophic as not being able to login has affected one of my machines. In fact all I think I did was "realm leave" which produced no errors. I rebooted to a borked machine. Awesome.

Same here with Groovy Gorilla (20.10), with all the latest bells'n'whistles. On boot-up, I get multiple failures on SSSD services, 'sudo systemctl restart sssd' doesn't help either, 'journalctl -xe' says:

-------------------------
░░ A start job for unit sssd-nss.socket has finished with a failure.
░░
░░ The job identifier is 8989 and the job result is dependency.
Nov 12 19:40:11 mymachine systemd[1]: sssd-nss.socket: Job sssd-nss.socket/start failed with result 'dependency'.
Nov 12 19:40:11 mymachine systemd[1]: Dependency failed for SSSD AutoFS Service responder socket.
░░ Subject: A start job for unit sssd-autofs.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-autofs.socket has finished with a failure.
░░
░░ The job identifier is 8913 and the job result is dependency.
Nov 12 19:40:11 mymachine systemd[1]: sssd-autofs.socket: Job sssd-autofs.socket/start failed with result 'dependency'.
Nov 12 19:40:11 mymachine systemd[1]: Dependency failed for SSSD PAC Service responder socket.
░░ Subject: A start job for unit sssd-pac.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-pac.socket has finished with a failure.
░░
░░ The job identifier is 8995 and the job result is dependency.
Nov 12 19:40:11 mymachine systemd[1]: sssd-pac.socket: Job sssd-pac.socket/start failed with result 'dependency'.
Nov 12 19:40:11 mymachine systemd[1]: Dependency failed for SSSD Sudo Service responder socket.
░░ Subject: A start job for unit sssd-sudo.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-sudo.socket has finished with a failure.
░░
░░ The job identifier is 8992 and the job result is dependency.
Nov 12 19:40:11 mymachine systemd[1]: sssd-sudo.socket: Job sssd-sudo.socket/start failed with result 'dependency'.
Nov 12 19:40:11 mymachine systemd[1]: Dependency failed for SSSD PAM Service responder socket.
░░ Subject: A start job for unit sssd-pam.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-pam.socket has finished with a failure.
░░
░░ The job identifier is 8990 and the job result is dependency.
Nov 12 19:40:11 mymachine systemd[1]: Dependency failed for SSSD PAM Service responder private socket.
░░ Subject: A start job for unit sssd-pam-priv.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-pam-priv.socket has finished with a failure.
░░
░░ The job identifier is 8991 and the job result is dependency.
-------------------------

... And so forth. What a quagmire, once more! :)

I experience the infinite loop on boot about half the time. The OP speaks of "misconfiguration because of user error", yet I'm not the type to twittle with the system when it's not broken, so I'm not sure how this misconfiguration happened.

Does anyone know of a workaround?

When the machine does boot I can get this error message from sssd.service:

=> systemctl status sssd.service
● sssd.service - System Security Services Daemon
     Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2021-01-20 14:19:18 CET; 16min ago
    Process: 5550 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4)
   Main PID: 5550 (code=exited, status=4)

Jan 20 14:19:18 praxis systemd[1]: Failed to start System Security Services Daemon.
Jan 20 14:19:18 praxis systemd[1]: sssd.service: Scheduled restart job, restart counter is at 5.
Jan 20 14:19:18 praxis systemd[1]: Stopped System Security Services Daemon.
Jan 20 14:19:18 praxis systemd[1]: sssd.service: Start request repeated too quickly.
Jan 20 14:19:18 praxis systemd[1]: sssd.service: Failed with result 'exit-code'.
Jan 20 14:19:18 praxis systemd[1]: Failed to start System Security Services Daemon.

Hi,

I think that part of the comments here are actually related to LP: #1900642, which is now fixed in groovy-updates and hirsute. However initial bug description from Ian Collier specifies that this bug report is about the case where a valid sssd.conf exists, but sssd fails to start due to a different issue. This is not a case covered in LP: #1900642.

@Ian: do you agree with this analysis? Did you try disabling the sockets as Andreas suggested? The problem could be indeed with the socket activation of sssd, which doesn't seem to have a backoff.

Some more detailed steps to reproduce the issue from scratch (e.g. in a clean LXD container) would greatly help debugging.

Waiting for further information I'm setting the status of this bug report to Incomplete.

[Expired for sssd (Ubuntu) because there has been no activity for 60 days.]

I have been able to reproduce this issue twice by installing fuse (sudo apt install fuse) and then rebooting. The system is then permanently stuck in an unbootable state with the aforementioned errors.

Hi Nathan,

Thanks for commenting here then.

Could you provide more details on the issue? What Ubuntu series are you installing it in? Are those clean installations? Does that happen with specific configuration in place?