Learn more about these different git repos.
Other Git URLs
Ubuntu 18.04.2 sssd version 1.16.1
If sssd starts before the networking is ready, the network related sssd backends never come online. I believe the reason is that sssd fails to monitor /etc/resolv.conf if it is a broken symlink.
/etc/resolv.conf
This can happen with systemd-networkd if the network takes some time to come up. In these situations, /etc/resolv.conf is a (broken) symlink to /run/systemd/resolve/stub-resolv.conf . I believe NetworkManager works in a similar way
According to the man page for inotify_add_watch , a broken symlink will return an error of
ENOENT A directory component in pathname does not exist or is a dangling symbolic link.
SSSD ignores this error at line 462 https://pagure.io/SSSD/sssd/blob/master/f/src/util/inotify.c#_462
If using the setting try_inotify = false sssd complains about the missing file and turns off monitoring with the log [sssd] [monitor_config_file_fallback] (0x0080): file [/etc/resolv.conf] is missing. Will not update online status based on watching the file
try_inotify = false
[sssd] [monitor_config_file_fallback] (0x0080): file [/etc/resolv.conf] is missing. Will not update online status based on watching the file
These steps recreate a scenario where a network backend never comes online. This uses a patched Ubuntu 18.04.2 server using systemd-networkd. All steps run as root
systemd-networkd
apt-get install sssd sssd-tools touch /etc/sssd/sssd.conf chmod 0600 /etc/sssd/sssd.conf cat > /etc/sssd/sssd.conf <<EOF [sssd] #try_inotify = false debug_level = 10 config_file_version = 2 domains = MYDOMAIN services = nss, pam, sudo, ifp [nss] [pam] [domain/MYDOMAIN] debug_level = 10 timeout = 10 enumerate = false ignore_group_members = true # providers id_provider = ldap access_provider = none auth_provider = none chpass_provider = none sudo_provider = none # id settings # these settings don't really matter, we just want to show the lack of connection to the server at all # this is just some public ldap server for testing detailed at https://www.forumsys.com/tutorials/integration-how-to/ldap/online-ldap-test-server/ ldap_id_mapping = False ldap_default_bind_dn = cn=read-only-admin,dc=example,dc=com ldap_default_authtok = password ldap_schema = ad ldap_uri = ldap://ldap.forumsys.com ldap_referrals = false ldap_user_object_class = user EOF systemctl start sssd
Confirm the backend is Online
sssctl domain-status MYDOMAIN
Simulate a slow network startup and reboot
mkdir /etc/systemd/system/systemd-networkd.service.d/ cat > /etc/systemd/system/systemd-networkd.service.d/override.conf <<EOF [Service] # artificially slow networking setup ExecStartPre=/bin/sleep 8 EOF reboot
After the reboot, the domain will be Offline and will remain so until sssd is restarted
There are several ways to make sssd wait for networking, which will avoid the broken symlink. This is what I've done
mkdir /etc/systemd/system/sssd.service.d cat > /etc/systemd/system/sssd.service.d/override.conf <<EOF [Unit] Requires=network-online.target After=network-online.target EOF
It seems strange that the resolv.conf missing would be the issue, because later in the code you referenced the /etc directory is watched for changes as well: https://pagure.io/SSSD/sssd/blob/master/f/src/util/inotify.c#_471
Do you have sssd debug logs that capture the issue? It would be best to pair them with journal or syslog entries to be able to see when was network up and what was sssd doing at the same time.
See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
btw I tried to reproduce the issue locally on Fedora with networkManager and everything worked. First sssd started offline:
Mar 14 00:44:53 localhost systemd[1]: Starting System Security Services Daemon... Mar 14 00:44:53 localhost sssd[709]: Starting up Mar 14 00:44:53 localhost sssd[be[redhat.com]][726]: Starting up Mar 14 00:44:53 localhost sssd[be[implicit_files]][725]: Starting up Mar 14 00:44:53 localhost sssd[nss][727]: Starting up Mar 14 00:44:53 localhost systemd[1]: Started System Security Services Daemon.
but later switched to online mode:
Mar 14 00:45:02 vm-171-159.abc.idm.lab.eng.brq.redhat.com sssd[be[redhat.com]][726]: Backend is online
This time correlates wit the time NM connected:
Mar 14 00:45:01 localhost NetworkManager[736]: <info> [1552520701.4740] manager: NetworkManager state is now CONNECTED_GLOBAL
There was a similar issue in RHEL that @thalman was looking into where the go-online message came too soon before sssd could connect and then it was never retried. It would be nice to see the debug logs to see exactly what is happening in your setup.
I've attached the journalctl -b output and the /var/log/sssd contents.
journalctl -b
/var/log/sssd
I'm not sure if inotify will detect if /etc/resolv.conf goes from a broken symlink to a working symlink. I'll see if I can setup a Fedora machine, but this is how the Ubuntu system is sets up the resolv.conf file as a symlink. This is done when the package is installed, not during boot. That stub-resolv.conf file does not exist until the network is up
resolv.conf
stub-resolv.conf
root@bionic:~# ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 39 Jun 12 2018 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
From the log files, the main thing the journalctl logs will show is that the backend is offline
Mar 22 16:19:29 bionic sssd[be[521]: Backend is offline
The logs from sssd_MYDOMAIN.log will continuously cycle through checks to go online, but fails to resolve the host from the ldap_uri setting
sssd_MYDOMAIN.log
ldap_uri
(Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [check_if_online] (0x2000): Trying to go back online! (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_reset_services] (0x1000): Resetting all servers in all services (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'name not resolved' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ldap.forumsys.com' as 'neutral' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'ldap.forumsys.com' as 'neutral' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [dp_attach_req] (0x0400): DP Request [Online Check #22]: New request. Flags [0000]. (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'name not resolved' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [get_port_status] (0x1000): Port status of port 389 for server 'ldap.forumsys.com' is 'neutral' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'name not resolved' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_is_address] (0x4000): [ldap.forumsys.com] does not look like an IP address (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap.forumsys.com' in files (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'resolving name' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ldap.forumsys.com' in files (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [be_ptask_done] (0x0400): Task [Check if online (periodic)]: finished successfully (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 261 seconds from last execution time [1553272099] (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ldap.forumsys.com' in DNS (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'ldap.forumsys.com': Could not contact DNS servers (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'not working' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (ldap.forumsys.com), resolver returned [5]: Input/output error (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [be_resolve_server_process] (0x1000): Trying with the next one! (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'not working' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'not working' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [dp_req_done] (0x0400): DP Request [Online Check #22]: Request handler finished [0]: Success (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [_dp_req_recv] (0x0400): DP Request [Online Check #22]: Receiving request data. (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [dp_req_destructor] (0x0400): DP Request [Online Check #22]: Request removed. (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Fri Mar 22 16:23:58 2019) [sssd[be[MYDOMAIN]]] [be_check_online_done] (0x0400): Backend is offline
<img alt="journalctl_b.txt" src="/SSSD/sssd/issue/raw/files/8448ff258e5b6ae8134dfcf8e11ccf7984ecd10b17a2055477c73cb6e1f91ef7-journalctl_b.txt" /><img alt="sssd.tgz" src="/SSSD/sssd/issue/raw/files/8986cdac5104904ec087cba7df817e745fdbf4b3001f72c41ead74f34960221f-sssd.tgz" />
This issue happens also on Fedora 31, when NetworkManager is used with stateless IPv6 autoconfiguration. /etc/resolv.conf is a broken symlink until network is online. I cannot add a dependency to network-online.target because the system needs to work offline as well. Using a regular static resolv.conf instead of symlink works in my case as a workaround.
Hi,
there is a chance that https://github.com/SSSD/sssd/pull/864 fixes the issue. Those patches are currently not included in the latest Fedora build but should be in the next.
bye, Sumit
SSSD 2.2.3 has made it into the upcoming Ubuntu 20.04 (Focal) release. I downloaded the daily build iso and tested it. It does appear the issue is fixed.
This is some of sssd_MYDOMAIN.log as SSSD starts and the network has not yet been brought up
(Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [sss_domain_get_state] (0x1000): Domain MYDOMAIN is Active (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'name not resolved' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [get_port_status] (0x1000): Port status of port 389 for server 'ldap.forumsys.com' is 'neutral' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'name not resolved' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_is_address] (0x4000): [ldap.forumsys.com] does not look like an IP address (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap.forumsys.com' in files (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'resolving name' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ldap.forumsys.com' in files (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ldap.forumsys.com' in DNS (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 3 seconds (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'ldap.forumsys.com': Could not contact DNS servers (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'not working' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (ldap.forumsys.com), resolver returned [5]: Input/output error (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_resolve_server_process] (0x1000): Trying with the next one! (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'not working' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'not working' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_mark_offline] (0x2000): Going offline! (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_mark_offline] (0x2000): Initialize check_if_online_ptask. ... (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_ptask_create] (0x0400): Periodic task [Check if online (periodic)] was created (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 73 seconds from now [1582913749] (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Fri Feb 28 13:14:36 2020) [sssd[be[MYDOMAIN]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 ... (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_issue_request_done] (0x0040): sssd.dataprovider.getAccountInfo: Error [1432158212]: SSSD is offline (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.service.resetOffline on /sssd (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.monitor] (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.service.resetOffline on /sssd (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.monitor] (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_requests_add] (0x4000): Chaining request: -:0:org.freedesktop.DBus.GetConnectionUnixUser:/org/freedesktop/DBus:sssd.monitor (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.monitor] (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_senders_add] (0x2000): Inserting identity of sender [sssd.monitor]: 0 (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.monitor] (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [check_if_online] (0x2000): Schedule check_if_online_delayed in 1s. (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_issue_request_done] (0x0400): sssd.service.resetOffline: Success (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [check_if_online] (0x2000): There is an online check already running. (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_issue_request_done] (0x0400): sssd.service.resetOffline: Success (Fri Feb 28 13:14:37 2020) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching.
This is some of sssd_MYDOMAIN.log after the network has come up
(Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [check_if_online_delayed] (0x2000): Trying to go back online! (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [fo_reset_services] (0x1000): Resetting all servers in all services (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'name not resolved' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ldap.forumsys.com' as 'neutral' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'ldap.forumsys.com' as 'neutral' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [dp_attach_req] (0x0400): DP Request [Online Check #6]: New request. Flags [0000]. (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'name not resolved' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [get_port_status] (0x1000): Port status of port 389 for server 'ldap.forumsys.com' is 'neutral' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [get_server_status] (0x1000): Status of server 'ldap.forumsys.com' is 'name not resolved' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_is_address] (0x4000): [ldap.forumsys.com] does not look like an IP address (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap.forumsys.com' in files (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'resolving name' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [check_if_online_delayed] (0x2000): Check online req created. (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ldap.forumsys.com' in files (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ldap.forumsys.com' in DNS (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 3 seconds (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sbus_dispatch] (0x4000): Dispatching. (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.service.resetOffline on /sssd (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.monitor] (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [check_if_online] (0x2000): There is an online check already running. (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sbus_issue_request_done] (0x0400): sssd.service.resetOffline: Success (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [set_server_common_status] (0x0100): Marking server 'ldap.forumsys.com' as 'name resolved' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [be_resolve_server_process] (0x0200): Found address for server ldap.forumsys.com: [52.87.186.93] TTL 3600 (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sdap_uri_callback] (0x0400): Constructed uri 'ldap://ldap.forumsys.com' (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [24] for the connection. (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ldap.forumsys.com:389/??base] with fd [24]. (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Fri Feb 28 13:14:38 2020) [sssd[be[MYDOMAIN]]] [sdap_print_server] (0x2000): Searching 52.87.186.93:389
thank you for the feedback, so it looks like https://github.com/SSSD/sssd/pull/864 really fixed this issue.
I'll close this ticket, feel free to reopen this ticket or create a new one if the issue is still present with a recent version of SSSD.
Metadata Update from @sbose: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4954
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.