http://bugzilla.opensuse.org/show_bug.cgi?id=1141925 Bug ID: 1141925 Summary: sssd ldap be goes into the "Backend is offline" state at boot, because dhcp hasn't gotten an ip address yet, and never recovers Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening@forge.provo.novell.com Reporter: tabmcleo@cs.ubc.ca QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 OPR/62.0.3331.43 Build Identifier: Opened this problem in the support forum: https://forums.opensuse.org/showthread.php/536482-sssd-ldap-be-goes-into-quo... The two responses to this problem in the support forum were to open a bug report. The following is cut and pasted from the problem posted in the support forum: Hello, My department has run into a problem with openSuSE Leap 15.1, LDAP and sssd. In short, it appears that sssd starts prior to DHCP obtaining an IP address for the network interface. At that point, sssd ldap be goes into the "Backend is offline" state and never recovers. It appears to never recover, because it is never informed by inotify when a DHCP address is obtained and resolv.conf is updated. Consequently, a console login followed by a "systemctl restart sssd.service" is required or a reboot before non-local users can login. Some Ubuntu users have run into the same problem: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350 I've modified our sssd.service file and placed it in /etc/systemd/system to override the default file in /usr/lib/systemd/system: [Unit] Description=System Security Services Daemon # SSSD must be running before we permit user sessions After=network-online.target <================================================ Added this line Before=systemd-user-sessions.service nss-user-lookup.target Wants=nss-user-lookup.target network-online.target <======================== Added "network-online.target" PartOf=network-online.target <=============================================== Added this line [Service] Environment=DEBUG_LOGGER=--logger=files EnvironmentFile=-/etc/sysconfig/sssd ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} Type=notify NotifyAccess=main PIDFile=/var/run/sssd.pid [Install] WantedBy=multi-user.target Note that this is a workaround and not a fix. It is my belief that sssd should recover once DHCP provides an IP address. We are using wicked. So far, this is reproducible with desktop computers running openSuSE 15.1 using DHCP, sssd and an LDAP backend for authentication. I've followed the methodology in the Ubuntu bug report. In a nutshell, it appears that sssd never recovers because /etc/resolv.conf is a symlink. Inotify reports when the file pointed to is changed, but not on the symlink itself. Reproducible: Always Steps to Reproduce: 1.Boot the computer 2.Only local logins work, e.g. root 3."systemctl status sssd.service" reveals sssd ldap be is "offline" 4."systemctl restart sssd.service" resolves the problem Actual Results: At boot time, sssd ldap be goes into an offline state because DHCP hasn't yet acquired an IP address. When an IP address is acquired, sssd ldap be stays in the offline state unless an "systemctl restart sssd.service" is performed. Expected Results: After booting the computer, non-local users should be able to login. Even though sssd is started prior to DHCP obtaining an IP address, and goes into an "offline" state, it should recover once an IP address is obtained and /etc/resolv.conf contains an entry (or entries) for a DNS. -- You are receiving this mail because: You are on the CC list for the bug.