El 10/10/16 a las 10:56, Ian Kent escribió: > 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. >
I was thinking about using CLOCK_MONOTONIC_RAW: CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific) Similar to CLOCK_MONOTONIC, but provides access to a raw hardware-based time that is not subject to NTP adjustments or the incremental adjustments performed by adjtime(3). >> 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 didn't dig much into it yet (I just checked tevent to confirm it uses gettimeofday()), so I'll take this as my next step. Thanks, Victor _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
