Last modified: 2011-07-24 11:39:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T23899, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21899 - Block timing messed up on enwiktionary
Block timing messed up on enwiktionary
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-19 21:19 UTC by Conrad Irwin
Modified: 2011-07-24 11:39 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Conrad Irwin 2009-12-19 21:19:09 UTC
On en.wiktionary,

Special:Block says:  20:51, 18 December 2009 Opiaterein (Talk | contribs | block) blocked Razorflame (Talk | contribs) with an expiry time of 1 day (account creation disabled) ‎ (Already breaking a promise he made yesterday.) (unblock | change block) 

Special:BlockList says: 
# 20:51, 18 December 2009, Opiaterein (Talk | contribs | block) blocked Razorflame (Talk | contribs) (expires on 20 December 2009 at 03:51, account creation blocked)  (Already breaking a promise he made yesterday.) (unblock | change block)

# 04:13, 19 December 2009, Opiaterein (Talk | contribs | block) blocked #53916 (expires on 20 December 2009 at 04:13, account creation blocked) (Autoblocked because your IP address has been recently used by "Razorflame". The reason given for Razorflame's block is: "'''Already breaking a promise he made yesterday.'''") (unblock)

Opiaterein has apparently set his timezone to utc-5
Razorflame has apparently set his timezone to utc-6
My timezone setting is unchanged "server default".

The actual block was manually removed shortly after 20:51 on the 19th, and the autoblock was manually removed soon after.

# Why was the block extended?
# Why was the autoblock hours late?
# Why didn't the autoblock get removed when we unblocked the user?
Comment 1 Roan Kattouw 2009-12-19 21:32:29 UTC
Updated summary.

One possibility I can think of is that one of the servers' clocks was off by about 7.5 hours, which means the autoblock would have happened within the correct timeframe (between 20:51 and the removal of the block) but logged with a different timestamp and expiry.
Comment 2 Conrad Irwin 2009-12-19 21:37:44 UTC
Well, that would explain the autoblock appearing to be 7hours and 22minutes late, but it doesn't explain why the block expiry was increased by 7 hours. (Also, the autoblock actually happened during the actual block).
Comment 3 Roan Kattouw 2009-12-20 13:52:22 UTC
(In reply to comment #2)
> Well, that would explain the autoblock appearing to be 7hours and 22minutes
> late, but it doesn't explain why the block expiry was increased by 7 hours.
> (Also, the autoblock actually happened during the actual block).
> 

It would explain that perfectly: the ipblocks table stores the timestamp at which the block expires, not a duration. This timestamp is calculated by the server by adding the requested amount of time to the current time, so if the server believed it was 04:13 at the time it made the autoblock, it would set it to expire at 04:13 the next day.
Comment 4 John Mark Vandenberg 2011-04-28 15:12:25 UTC
Has it happened again?  Should the existing data be fixed and bug closed..?
Comment 5 Platonides 2011-04-28 15:17:34 UTC
I think that if we tell nagios to check the servers clock we can close this as "won't happen again".
Comment 6 Sam Reed (reedy) 2011-07-01 18:23:13 UTC
Nagios does monitor NTP/clock drift

Closing as it's 2 years old

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links