Monotonic clock for timed events
by Victor Tapia
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
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?
6 years, 7 months
by Jakub Hrozek
for better or worse, our milestone and release planning is not great. We
normally decide on what we want to work on for the next release and release
new versions based on Fedora or RHEL releases (mostly because there is
normally no other driver..if there are other projects or distributions
who would like us to release on a different schedule, please just speak up!).
The result is that our milestones don't really reflect the reality -- we
have a huge milestone called "1.16" that is not really going to become
1.16, it's rather a set of tickets we'd like to work on "sometimes in
the future". In addition, we have milestones that track bug fixing in
released versions, currently 1.13.5 and 1.14.2 and the version currently
under development, which is 1.15 at the moment.
What I propose to make it clearer to outsiders what the expectations are
is simply the following:
- rename the current 1.16 bucket to "Future releases", maybe with a
more explanatory note, like "Future releases - not planned for a
- triage the milestones like 1.17 or 2.0, move tickets from there
either to deferred or just close them
- rename the "Deferred" milestone to "Patches welcome".
I think this would make it clearer a bit in terms of what the sssd
upstream is working on now and what we are working on next..
6 years, 7 months