Last modified: 2011-07-24 11:39:46 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?
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.
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).
(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.
Has it happened again? Should the existing data be fixed and bug closed..?
I think that if we tell nagios to check the servers clock we can close this as "won't happen again".
Nagios does monitor NTP/clock drift Closing as it's 2 years old