Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"STAT time" drifts when computer is put to sleep #278

Closed
bitcity opened this issue May 30, 2017 · 1 comment

Comments

@bitcity
Copy link

commented May 30, 2017

When I restart memcached, the server's clock is in sync with system time. (I'm checking the clock by reading "STAT time" from the command below).

echo 'stats' | nc localhost 11211 | grep "STAT time "

If I put the computer to sleep, the clock doesn't advance until the system resumes. As a result, the clock drifts w.r.t system clock. If I check the entries in memcached (with cachedump), the timestamp for expiration of an entry stays the same even after sleep.

Consider an example :
After restart, an object is stored (at 1 AM UTC) with expiration of 1 hour from now

Computer time : 01:00:00 UTC
Memcached time : 01:00:00 UTC
Expiration timestamp : 1496109600 [02:00:00 UTC]

Computer sleeps for 30 minutes & resumes

Computer time : 01:30:00 UTC
Memcached time : 01:00:00 UTC -> drifts by 30 minutes
Expiration timestamp : 1496109600 [02:00:00 UTC] -> stays same

Expiration timestamp is still 2 AM UTC, but memcached's clock is 30 minutes behind the computer clock. As a result, the object would expire at 2:30 AM (as opposed to 2:00 AM, the intended time).

Is this a memcached bug or is my understanding incorrect ? I've experimented this by setting an actual object and I found that the expiration time drifts by the time the computer is put to sleep.

@dormando

This comment has been minimized.

Copy link
Member

commented May 30, 2017

That's intentional, unfortunately. Memcached implements a monotonic clock to ensure it always goes forward generally when time goes forward for the computer. When a computer is asleep time isn't going forward.

Without the monotonic clock NTP can jump time both forward and backwards; and if time goes backwards then forwards again you can create immortal objects with underflowed expiration times. Or if time goes forward then backward an object which was supposed to expire in 5 minutes could take hours or days (or years, if the clock is pretty screwed up on boot).

@dormando dormando closed this Jun 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.