UnrealIRCd Bug Tracker - unreal
View Issue Details
0003230unrealircdpublic2007-02-08 13:042009-01-24 15:22
Assigned Tosyzop 
Platform*OS*OS Version*
Product Version3.2.6 
Target VersionFixed in Version3.2.8 
3rd party modules
Summary0003230: TSCTL Offset Freeze
DescriptionWhen the TSCTL offset if changed in a certain direction (forget which), Unreal freezes to catch up. I was once told this was due to the fakelag and possibly other timed events needing to catch up with the time.

How hard would it be to just update the times for these events and just have them process? I understand if a such thing happens during a flood, Unreal may crash. I personally have never seen an IRCd crash from sending/receiving too much data. If Unreal has the potential to crash, I guess that is what users deserve for having such large time differences.
TagsNo tags attached.
Attached Files

2007-02-08 13:55   
-> Happens when you subtract time
-> Does not affect new connections
2007-02-11 07:48   
it would not be hard to update all the times, you'd just need to make sure to get all of them.

i think this _should_ be implemented as freezing of everything would not be good
2007-02-11 16:17   
Well, ideally you wouldn't have to turn back the clock so much in the first place. There's the whole usual "run ntpd" or "use the builtin timesynch" stuff, after all.

I would say, if fakelag timers are updated, it's done regardless of if you go forward or backward.
2007-03-08 09:36   
It's not possible to fix every timestamp, by definition (you don't know for example which channel TS is wrong, and which one is right. Same for TKL, and many more).
I also plan to update as few as possible.. only the ones causing a lot of trouble. I'm sure this will get out of hand otherwise...

I'll make it so that:
1. Unreal detects any time changes, either done via TSCTL or when the system time is changed.
2. whenever the timechange is too much, like >15s, Unreal will print out a warning to all ircops about this BAD THING. (reminds me off eggdrop w/timer drift). Possibly repeating this every 5m until the offset has been corrected (eg: an hour offset change will result in every 5m a message regarding this until the hour is done). This might be annoying, but that's by design :)
3. Unreal will update event timers, flush throttling, reset all client anti flood thingies.

So basically, it's about trying to prevent worst case stuff. We, by NO means, pretend to fix everything. Changing the time offset so much is a bad thing. Correct time is important. People must use NTP or built-in timesynch. This is stressed so often. I just want to make it that it doesn't freeze up the entire ircd and make it so people are still able to connect (throttling). Oh and, I like the warning as well :).

Someone (tabrisnet? aqua?) also suggested having some option which rejects servers linking in which time is to much off, I'd like to see that implemented as well.

EDIT: clarified last sentence

2007-03-08 18:32   
[quote]Someone (tabrisnet? aqua?) also suggested having some option which rejects servers linking in which time is to much off, I'd like to see that implemented as well.[/quote]

I think I had mentioned it once or something, but I see one slight problem: server timestamp is sent in NETINFO - long after the damage is done-*cough* I mean, NICKs and SJOINs are sent. As I see it, there are two options: hold NICK/SJOIN/maybe-everything-else in some kind of "synch buffer" until NETINFO is seen, then dump buffer and disconnect if time is off, or send either entire NETINFO earlier (ick) or just the timestamp, perhaps in SERVER along with protover-flags-numeric, so eg, protover-flags-numeric-time (yikes).
2007-03-14 01:18   
aquanight, I like the second (putting it in SERVER). sure, it's not the nicest, but putting it early is good. sync buffer would a) eat memory b) give new definition to pain.

and as to the whole "don't sync if too much difference" isn't my idea (tho I did mention it), many other IRCds do this, as IRC really is reliant on correct time.

also, as to NTP, I agree we should. but too many shell hosts don't (many colos don't provide NTP servers either [waveform.net does tho!]). meanwhile, adding an NTP/SNTP client into the ircd at least will catch more. hell, just have an SNTP function run hourly, and if drift is over X (say 5) sec/hour then yell scream and holler. Would be simpler than adding a whole NTP client ( which btw, really should not be done waiting on a select() )
2009-01-24 15:22   
- Added some big warnings regarding big timeshifts.
  In the IRCd world correct time is very important. This means that time
  should be correct when the IRCd is booted, either by running ntpd/ntpdate
  on the system or some other synchronization software, or by using the
  built-in timesync feature.
  Whenever the clock is adjusted for more than a few seconds AFTER the IRCd
  has booted, it can lead to dangerous effects ranging from unfair timestamps
  for nicks and channels (and hence the possibility to takeover channels),
  to even completely stalling the IRCd (negative timeshift) or making it so
  nobody can connect anymore due to throttling (positive timeshift).
  We now try to 'fix' the worst effects such as the IRCd freeze and
  throttling. This does not fix the whole problem, so I've added some big
  warnings when the clock is adjusted, including an annoying one every 5
  minutes if the clock was set backwards, until the time is OK again
  (catches up with the original time).
  This fixes 0003230 reported by Stealth, and 0002521 reported by durrie.

Issue History
2007-02-08 13:04StealthNew Issue
2007-02-08 13:55StealthNote Added: 0013204
2007-02-11 07:48djGrrrNote Added: 0013208
2007-02-11 16:17aquanightNote Added: 0013210
2007-03-08 09:36syzopNote Added: 0013288
2007-03-08 09:36syzopNote Edited: 0013288
2007-03-08 18:32aquanightNote Added: 0013292
2007-03-14 01:18tabrisnetNote Added: 0013309
2007-04-19 03:25stskeepsStatusnew => acknowledged
2009-01-24 15:22syzopQA => Not touched yet by developer
2009-01-24 15:22syzopU4: Need for upstream patch => No need for upstream InspIRCd patch
2009-01-24 15:22syzopStatusacknowledged => resolved
2009-01-24 15:22syzopFixed in Version => 3.2.8
2009-01-24 15:22syzopResolutionopen => fixed
2009-01-24 15:22syzopAssigned To => syzop
2009-01-24 15:22syzopNote Added: 0015707