#3982 sssd doesn't monitor /etc/resolv.conf if the file is a broken symlink when sssd is started
Closed: Fixed 4 years ago by sbose. Opened 5 years ago by andychandy.

System

Ubuntu 18.04.2
sssd version 1.16.1

Related bugs

Description

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.

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

Duplicating

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

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

sssctl domain-status MYDOMAIN

Workaround

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.

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

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

(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

journalctl_b.txtsssd.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

Hi,

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.

bye,
Sumit

Metadata Update from @sbose:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata
Attachments 1
Attached 5 years ago View Comment