Petr, do you already have an idea of what the alternative for us might be?

cc: => pspacek@redhat.com

Jakube, could you explain to me why you need to watch resolv.conf? I will not able to advise you anything without more details.

As you know, SSSD is stateful, iow we maintain online/offline status. Therefore, we care about external conditions changes that might indicate to SSSD it's time to reconsider its offline status and attempt a reconnection.

Watching resolv.conf with inotify is one of those mechanisms. The others are networking changes (such as IP address changes, routing table changes) as reported by libnl and lastly a periodical check.

One use-case where watching resolv.conf is useful is VPN, as NM or other VPN software would update resolv.conf with internal DNS servers. We use that as a signal that it's time to go online.

Okay, got it. I would say that this mechanism works for you just accidentaly.

NM can put 127.0.0.1 into resolv.conf even today - mainly in cases where it is configured to use dnsmasq as DNS backend.

My recommendation is to use proper NM or Kernel APIs to watch for network changes. Maybe this should be somehow plugable so SSSD can work on BSD/other systems?

Replying to [comment:4 pspacek]:

Okay, got it. I would say that this mechanism works for you just accidentaly.

NM can put 127.0.0.1 into resolv.conf even today - mainly in cases where it is configured to use dnsmasq as DNS backend.

The default is still to change resolv.conf (my laptop is using mostly defaults)

My recommendation is to use proper NM or Kernel APIs to watch for network changes. Maybe this should be somehow plugable so SSSD can work on BSD/other systems?

hmm, perhaps. I think we'd need to test several scenarios, but in general I dislike breaking the default..

Bu you're right that while we're talking about defaults, we should take into account also NM APIs. I think back in the day when the inotify watch was developed, NM was nowhere near as mature as now. Ditto for systemd-networkd APIs, if there are any.

Since we have no idea if the system we're running on is running a local DNS server or not, we might just let the inotify watch in place for older systems and think about other mechanisms, such as NM or systemd-networkd in the scope of the ticket.

Replying to [comment:5 jhrozek]:

Since we have no idea if the system we're running on is running a local DNS server or not, we might just let the inotify watch in place for older systems and think about other mechanisms, such as NM or systemd-networkd in the scope of the ticket.

That's a good idea. I can't think of a case where it would break something.

Just a reminder.
We already check network changes via libnl, the reason why we also added a check for resolv.conf is that there is a race between the time a vpn network interface is brought up and the new DNS service is reachable, so we decided to also listen for resolv.conf as a cheap way to detyect that occurrence.

We can also change the code to do away with checking resolv.conf and instead attempt to go online a few times after a network iface change with a backoout algorithm.

I.E: after iface change try immediately, then try again after 5 seconds then try again after 15, 30, 60, 120, stop

This will work whatever mechanism for resolving names or routing packets and race conditions may happen.

IMHO retry with back-off can be also a nice completent to inotify on resolv.conf.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta
priority: major => critical

This ticket shouldn't be critical, doing nothing would not have too bad effect. We might want to implement Simo's and Petr's suggestions in comments #7 and #8.

priority: critical => major

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => critical

Re-setting priority of 1.13 backlog tickets used for planning.

priority: critical => major

Fields changed

rhbz: => todo

Still makes sense for 1.14, but there are more urgent tickets..

milestone: SSSD 1.13 backlog => SSSD 1.14 beta
sensitive: => 0

With resolved we shouldn't postpone this work much longer, but we won't make 1.14.0. Marking as critical and moving to 1.14 backlog in the hope we would fix this for 1.14.1 and make downstreams that use resolved happier.

milestone: SSSD 1.14 beta => SSSD 1.14 backlog

Since the 1.14 branch is transitioning into maintenance mode and new functionality is being developed in master which will become 1.15 eventually, I'm mass-moving tickets from the 1.14 backlog milestone to the "Future releases" milestone.

milestone: SSSD 1.14 backlog => SSSD Future releases (no date set yet)

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

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/3597

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.