On Mon, 2016-10-10 at 10:42 +0200, Jakub Hrozek wrote: > On Mon, Oct 10, 2016 at 10:04:30AM +0200, Victor Tapia wrote: > > Hi list, > > > > I've faced a race condition when SSSD boots in a machine with a big > > clock drift. This is what I see: > > > > 1. SSSD starts before the network is up, queries the LDAP server without > > success and sets a retry timer (~60 secs) > > 2. NTP starts and corrects the clock, 1 hour back for example. > > 3. SSSD takes ~60 secs + the drift correction (1 hour) to retry the > > connection. > > > > In this particular scenario the credentials cache is disabled, so the > > wait time to login is noticeable. How feasible would it be to use a > > monotonic clock for this kind of timed events? > > I really have not tried this and I guess I don't know tevent internals > well enough if this works, but I wonder if just using: > clock_getime()
With a CLOCK_MONOTONIC I presume? I think that's what has been suggested. > and constructing struct timeval > in place of: > tevent_timeval_current_ofs() > could solve this particular issue. > > On the other hand, this is a pattern we use in SSSD all through the code > for timed events and we're just not well equipped to handle time drifts. > Did you investigate why doesn't sssd detect the networking change from > libnl messages or from resolv.conf being touched? I had a patch series contributed to autofs recently that changed to use CLOCK_MONOTONIC for the same type of problem. However, the man page says of CLOCK_MONOTONIC: "Clock that cannot be set and represents monotonic time since some unspecified starting point. This clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by the incremental adjustments performed by adjtime(3) and NTP." So perhaps this won't actually help when NTP adjusts the clock (although NTP should adjust the clock, perhaps, slowly enough), I didn't catch that when I reviewed the autofs patch series .... mmm. Ian _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
