On Wed, 2016-10-12 at 10:52 +0200, Pavel Březina wrote:
> 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.

Well I do care if sssd kills all children just because I suspended the
laptop for a while :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to