On 10/11/2016 03:26 PM, Simo Sorce wrote:
On Mon, 2016-10-10 at 14:04 +0200, Pavel Březina wrote:
On 10/10/2016 10:09 AM, Fabiano Fidêncio wrote:
Victor,
On Mon, Oct 10, 2016 at 10:04 AM, Victor Tapia
<victor.ta...@canonical.com> 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?
Are you running git master? This issue is supposed to be already
solved by
https://github.com/SSSD/sssd/commit/b8ceaeb80cffb00c26390913ea959b77f7e848b9
This patch fix the issue only in watchdog which would result in
terminating sssd otherwise. Fixing it across whole sssd would be
difficult. The fix should go to tevent.
It also seem to fix the issue only if the time jumps backwards, not if
it jumps forward, in that case if I read the code right, we'd still end
up killing sssd.
Yes, we don't need0 to care about forward jump since that means all
tevent timers that are within this time shift are fired anyway.
Simo.
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
