View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003230 | unreal | ircd | public | 2007-02-08 13:04 | 2009-01-24 15:22 |
| Reporter | Stealth | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | * | OS | * | OS Version | * |
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.2.8 | ||||
| Summary | 0003230: TSCTL Offset Freeze | ||||
| Description | When 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. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
-> Happens when you subtract time -> Does not affect new connections |
|
|
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 |
|
|
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. |
|
|
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 |
|
|
[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). |
|
|
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() ) |
|
|
- 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-02-08 13:04 | Stealth | New Issue | |
| 2007-02-08 13:55 | Stealth | Note Added: 0013204 | |
| 2007-02-11 07:48 | djGrrr | Note Added: 0013208 | |
| 2007-02-11 16:17 | aquanight | Note Added: 0013210 | |
| 2007-03-08 09:36 | syzop | Note Added: 0013288 | |
| 2007-03-08 09:36 | syzop | Note Edited: 0013288 | |
| 2007-03-08 18:32 | aquanight | Note Added: 0013292 | |
| 2007-03-14 01:18 | tabrisnet | Note Added: 0013309 | |
| 2007-04-19 03:25 |
|
Status | new => acknowledged |
| 2009-01-24 15:22 | syzop | QA | => Not touched yet by developer |
| 2009-01-24 15:22 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2009-01-24 15:22 | syzop | Status | acknowledged => resolved |
| 2009-01-24 15:22 | syzop | Fixed in Version | => 3.2.8 |
| 2009-01-24 15:22 | syzop | Resolution | open => fixed |
| 2009-01-24 15:22 | syzop | Assigned To | => syzop |
| 2009-01-24 15:22 | syzop | Note Added: 0015707 |
