UnrealIRCd Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002521unrealircdpublic2005-05-10 05:442009-01-24 15:20
Reporterdurrie 
Assigned Tosyzop 
PrioritynormalSeveritymajorReproducibilityrandom
StatusresolvedResolutionunable to reproduce 
PlatformbsdOSfreebsdOS Version4.10
Product Version3.2.3 
Target VersionFixed in Version3.2.8 
Summary0002521: User throttled for no reason
DescriptionFor no reason out of nowhere some users become throttled and are unable to connect no matter how long they wait between connections, only way to solve the problem at the moment is to restart the server.
Steps To Reproducenone, completely random.
TagsNo tags attached.
3rd party modules
Attached Filesgz file icon TDebug.tar.gz [^] (2,374 bytes) 2005-05-10 19:00

- Relationships
related to 0003252closed New version of openssl breaks connection throttle... 

-  Notes
(0009920)
sin-x (reporter)
2005-05-10 06:08
edited on: 2005-05-10 06:09

have you made heavy use of svskill? do you have your timestamps all sync'ed?
Ive noticed if I've used svskill alot, i get odd errors, and if timestamps arnt sync'ed all sorts of crap goes wrong, like throttling, netsplits, glines expiring early, so best bet is to make sure to keep em as close as possible, and not use svskill

(0009921)
durrie (reporter)
2005-05-10 06:14

nope, svskill is never used, and everything is sync'ed far as I know
(0009923)
sin-x (reporter)
2005-05-10 06:20

hmmm, well just for giggles could you drop an alltime output?
/tsctl alltime
(0009924)
durrie (reporter)
2005-05-10 06:22

-
[03:09] -irc.carbonblue.net- *** Server=irc.carbonblue.net TStime=1115719776 time()=1115719779 TSoffset=0
-
(0009926)
sin-x (reporter)
2005-05-10 06:26

just one server? hmmm well yeah then its not gonna be timestamps :P
does he have more than one connection trying at a time (clones, relitives, roomates, forgotten clients)?
(running outta ideas fast)
(0009927)
durrie (reporter)
2005-05-10 06:29

Nope none, and this happens to several people, last week I had about 10 people unable to connect all being throttled. I had one guy wait almost 2 days, and he was still throttled, and no it's doing it to my eggdrops out of nowhere, I restarted the server and the problem is fixed..but i dont want to have to restart the server everytime ya know what I mean.
(0009928)
sin-x (reporter)
2005-05-10 06:34

then sorry i couldnt help, im outta ideas. maybe someone else has an idea :/
(0009929)
durrie (reporter)
2005-05-10 06:37

I hope because next time this happens someone or something is getting hurt, thanks for trying though
(0009931)
syzop (administrator)
2005-05-10 10:38

Could you paste the output of /stats S regarding throttling? (the 2 throttle::<etc> items)

Did you compile with IPv6 support? ('grep INET6 config.settings' in unreal dir)

No 3rd party modules? No modified code?

If all results are negative then I'll probably give you a module to trace this issue :p.
(0009933)
durrie (reporter)
2005-05-10 18:45

throttle::period: 2 minutes
throttle::connections: 5

nope didn't compile with IPv6

no 3rd party & no modified code
(0009934)
syzop (administrator)
2005-05-10 19:04
edited on: 2005-05-10 19:05

I've attached TDebug.tar.gz to the bugreport - a small debugging module I made for this, just extract it somewhere and run ./build in it.

If someone tells you (s)he is throttled for no reason again, then do:
/TDEBUG LIST
/TDEBUG LISTEVENTS
and mail it to me (syzop@unrealircd.com) or post it here.

After you did that, you can do /TDEBUG FLUSH which will remove all throttling entries.

These commands (especially the /TDEBUG LIST) are also "safe" to use when there's no problem, so feel free to test if it outputs anything (if there are any throttling entries of course ;p).

(0009935)
durrie (reporter)
2005-05-10 19:17
edited on: 2005-05-10 19:40

./build: Permission denied.

nm got it had to chmod +x build

(0009936)
durrie (reporter)
2005-05-11 03:11

slot=192, ip=65.170.4.59, since=1115794611, count=1, on_for=25
slot=385, ip=172.169.251.224, since=1115794502, count=8, on_for=134 [EXP]
End of /TDEBUG LIST
htmcalc: fptr=2818e03c, every=1, howmany=0, last=1115794671, owner=81f1880
lcf: fptr=2818de3c, every=5, howmany=0, last=1115794671, owner=81f1880
modef_event: fptr=8058364, every=10, howmany=0, last=1115794671, owner=0
bucketcleaning: fptr=805aaac, every=60, howmany=0, last=1115794671, owner=0
cmodej_cleanup_structs: fptr=805d808, every=60, howmany=0, last=1115794671, owner=0
fdlistcheck: fptr=805ba74, every=1, howmany=0, last=1115794671, owner=0
loop: fptr=805b38c, every=0, howmany=0, last=1115794671, owner=0
garbage: fptr=805b3a8, every=600, howmany=0, last=1115794611, owner=0
tunefile: fptr=807d560, every=300, howmany=0, last=1115794627, owner=0
tklexpire: fptr=80781d4, every=5, howmany=0, last=1115794671, owner=0
ADDITIONAL INFO: now=1115794671, e_clean_out_throttling_buckets=805aaac
End of event list.
(0010010)
durrie (reporter)
2005-05-29 04:12

slot=294, ip=24.32.5.73, since=1117353224, count=2, on_for=74
slot=326, ip=63.230.51.126, since=1117353224, count=1, on_for=74
slot=477, ip=207.68.110.129, since=1117353226, count=1, on_for=72
slot=567, ip=66.252.2.167, since=1117353221, count=2, on_for=77
slot=614, ip=172.149.68.101, since=1117353230, count=1, on_for=68
slot=633, ip=24.49.97.211, since=1117353224, count=1, on_for=74
slot=670, ip=65.170.4.157, since=1117353226, count=1, on_for=72
slot=948, ip=65.95.26.183, since=1117353225, count=1, on_for=73
slot=955, ip=65.3.154.86, since=1117353232, count=1, on_for=66
slot=977, ip=67.181.231.43, since=1117353225, count=1, on_for=73
slot=1006, ip=70.178.137.3, since=1117353226, count=1, on_for=72
End of /TDEBUG LIST
(0010852)
syzop (administrator)
2005-12-10 17:18

Unable to reproduce.

Module output also showed (in all cases) the user was "rightfully" throttled (no weird timestamps etc).
(0012306)
syzop (administrator)
2006-09-04 09:50

I just want to add that someone else reported a similar problem on another server. I ran the TDEBUG module at it, and it actually showed tons (really *TONS*) of entries that should have been cleared.
Unfortunately it didn't have a debugger (well, gdb crashed on boot), so wasn't able to figure it out.
I've upgraded the server now from 3.2.4 to 3.2.5.

slot=0, ip=XXX.157.116.XX, since=1151878203, count=1, on_for=5492508 [EXP]
slot=2, ip=XX.17.166.X, since=1154570315, count=1, on_for=2800396 [EXP]
slot=2, ip=XXX.169.153.XX, since=1154514478, count=1, on_for=2856233 [EXP]
slot=2, ip=XXX.173.0.XX, since=1152066530, count=1, on_for=5304181 [EXP]
slot=3, ip=XX.231.248.XX, since=1153460793, count=1, on_for=3909918 [EXP]
slot=3, ip=XX.25.164.X, since=1153003905, count=1, on_for=4366806 [EXP]
slot=4, ip=XX.248.53.XX, since=1154859996, count=1, on_for=2510715 [EXP]
slot=4, ip=XXX.147.104.XXX, since=1151843211, count=1, on_for=5527500 [EXP]
slot=6, ip=XX.6.177.XXX, since=1156311818, count=2, on_for=1058893 [EXP]
slot=6, ip=XXX.144.32.XXX, since=1156078137, count=1, on_for=1292574 [EXP]
slot=6, ip=XX.232.185.XXX, since=1155404820, count=1, on_for=1965891 [EXP]
slot=6, ip=XX.248.53.XXX, since=1153276292, count=1, on_for=4094419 [EXP]

As you can see, some throttling entries have been on it for over 2 months.

If it happens again, I hope to trace it better, but without a debugger it's hard.

Also ->durrie... I didn't notice any [EXP] entries in your list, yet you were saying you're having trouble, back then I therefore said it didn't show anything suspicious. But.. maybe you were pasting only part of it (the last XX lines) and not everything? So maybe you did actually have more results, including [EXP] entries?
Well, I'm not expecting any answer back, but... just to say maybe due to miscommunication I did not receive the proper results.
Otherwise, if that actually *was* the complete output (*all* output). Then there was no issue at that time (no bug). That could mean that others were having issues at another time, but not the time when /TDEBUG LIST was done. Or at least, all the IP's on that specific list were throttled correctly.
(0012738)
devil (reporter)
2006-11-26 17:49

I recently updated from CVS to regular .5 and started having the very same error. The time is now 00:37 local, and I get:

ERROR :Closing Link: [83.233.59.125] (Throttled: Reconnecting too fast) -Email chatten@snyggast.se for more information.

The time() is: 1164588259

TDebug list shows:
01:43 -!- ip=81.224.227.246, since=1164583970, count=1, on_for=223 [EXP]
01:43 -!- ip=83.233.59.125, since=1164583950, count=19, on_for=243 [EXP]
01:43 -!- ip=194.237.110.189, since=1164583939, count=1, on_for=254 [EXP]
01:43 -!- ip=81.236.210.39, since=1164583958, count=1, on_for=235 [EXP]
01:43 -!- ip=213.114.201.165, since=1164583978, count=1, on_for=215 [EXP]
01:43 -!- of /TDEBUG LIST

[EXP] is there and I still get throttled. Happens to everyone. You simply can't reconnect since it doesn't appear to clear the throttle.

I've got AntiRandom and PrivDeaf modules installed. Neither "should" disturb throttle and I've been running a late CVS of .5 for month (many month).

However, my time offset it huge:

01:53 !chat.snyggast.se *** Server=chat.snyggast.se TStime=1164584823 time()=1164588823 TSoffset=-3998

But it's been working for years as it is. The time offset is due to summer/winter time.

I'm reverting to the older version to see it if works there. Honestly I don't have the time right now. If it works I'll probably wait for .6 and check there.
(0012739)
devil (reporter)
2006-11-26 17:56

Old CVS worked. So either one of the modules disturbed (old CVS used the same modules) or something else was wrong. I would really like to dig deeper into this bug honestly I am kind of burned out at the moment.

If you would like I could probably do it later this week.

Regards,
Niklas
(0012740)
syzop (administrator)
2006-11-26 17:58

Understood. Thanks for your info so far ;)
(0012741)
syzop (administrator)
2006-11-26 18:03

If the ts offset change happend more than 3998 seconds ago (well slightly more), then the offset should be no problem.
Basically whenever it's changed, like from 0 to -3998, it takes up to that time (3998 seconds, and a bit more) for everyhing to be back in line again [hence why having incorrect time is so bad].
[If this offset was already stored (like in ircd.tune), then it's no problem to begin with.]

That's all for now ;) -- off to bed
(0012742)
djGrrr (reporter)
2006-11-27 04:48

i've also experienced this with at least one of my users on one of my servers with 3.2.5 without either of those modules loaded, so its not related to those modules at all
(0012764)
Jon335 (reporter)
2006-11-29 09:34

Some of my users are experiencing this problem too. I can post any debug stuff you need. I just rebooted the server, I think it's working now.
(0012765)
syzop (administrator)
2006-11-29 09:40

If you could do this (after installing the TDebug module, see 'attached files' in the report), run these commands as ircop on irc:
/TDEBUG LIST
/TDEBUG LISTEVENTS
/TSCTL ALLTIME

(applies to everyone experiencing this issue, btw)
(0012766)
syzop (administrator)
2006-11-29 09:43

I guess the above would also be helpful for in devil's case... Like I guess I was missing /TDEBUG LISTEVENTS output, which would be helpful (this shows, for example, if the 'remove old entries every X time' timer was correctly called).
(0012767)
Jon335 (reporter)
2006-11-29 09:55
edited on: 2006-11-29 09:56

Only /TDEBUG LISTEVENTS gave any output:

fptr=28399d30, every=5, howmany=0, last=1164815421, owner=816d3c0
fptr=2838f2bc, every=1, howmany=0, last=1164815422, owner=816d3c0
fptr=2838f094, every=5, howmany=0, last=1164815421, owner=816d3c0
fptr=805ba68, every=10, howmany=0, last=1164815422, owner=0
fptr=805df7c, every=30, howmany=0, last=1164815393, owner=0
fptr=8054e98, every=15, howmany=0, last=1164815412, owner=0
fptr=8060e54, every=60, howmany=0, last=1164815382, owner=0
fptr=805ef50, every=1, howmany=0, last=1164815422, owner=0
fptr=805e91c, every=0, howmany=0, last=1164815422, owner=0
fptr=805e85c, every=600, howmany=0, last=1164815371, owner=0
fptr=8079cd0, every=300, howmany=0, last=1164815373, owner=0
INFO: now=1164815422, e_clean_out_throttling_buckets=805df7c
of event list.

I also noticed that only the people running IceChat 7.0 (OS X) are experiencing this issue.

Restarting the server fixed the issue temporarily.

(0012768)
syzop (administrator)
2006-11-29 10:02
edited on: 2006-11-29 10:02

Hm, all those 3 should output *something*.
Also I'm missing the first word of the LISTEVENTS output for each line :P.

/me blames your client ;) <-- for not displaying all info correctly, that is.

(0013281)
hmtX (reporter)
2007-03-08 05:15
edited on: 2007-03-08 07:10

slot=106, ip=XXX.60.236.XXX, since=1173350598, count=2, on_for=730 [EXP]
slot=426, ip=XXX.134.221.XXX, since=1173350546, count=3, on_for=782 [EXP]
End of /TDEBUG LIST

tklexpire: fptr=2a955a3150, every=5, howmany=0, last=1173354141, owner=8621f0
modef_event: fptr=43a5e0, every=10, howmany=0, last=1173354141, owner=0
bucketcleaning: fptr=43d0b0, every=15, howmany=0, last=1173354141, owner=0
unrealdns_removeoldrecords: fptr=433600, every=15, howmany=0, last=1173354141, owner=0
cmodej_cleanup_structs: fptr=440510, every=60, howmany=0, last=1173354141, owner=0
fdlistcheck: fptr=43e180, every=1, howmany=0, last=1173354141, owner=0
loop: fptr=43dae0, every=0, howmany=0, last=1173351332, owner=0
garbage: fptr=43da10, every=600, howmany=0, last=1173354141, owner=0
tunefile: fptr=45a740, every=300, howmany=0, last=1173354141, owner=0
htmcalc: fptr=2a95598470, every=1, howmany=0, last=1173354141, owner=8621f0
lcf: fptr=2a95598230, every=5, howmany=0, last=1173354141, owner=8621f0
ADDITIONAL INFO: now=1173351332, e_clean_out_throttling_buckets=43d0b0
End of event list.

-Corvus.Immortal-Anime.Net- *** Server=Corvus.Immortal-Anime.Net TStime=1173351384 time()=1173354983 TSoffset=-3597

Unreal3.2.6 x86_64 GNU/Linux=2309

/edit: after issuing infinite throttles for a while they suddenly started to work fine as they should. weird.

(0013282)
syzop (administrator)
2007-03-08 07:18

Thanks hmtX, for all the info.

All details seem to indicate that the IRCd clock was put 1 hour backwards (3597 seconds to be exact) very recently before your post. Possibly by a services time synch (SVSTIME), such as one done by neostats (though anope mods exist as well).

Can you confirm that the issue solved by itself, to be exact: 46 minutes after your first post (without the edit)?

Whenever the ircd clock is changed so drastically, it takes up to [the offset change] to get everything correct again. Although many things are impacted by a time change, throttling is the most visible part in this case (eg: few will notice a channel timestamp in the future, but when they can't connect to the server that's immediately visible).

I'm working on something that will actively warn ircops whenever such a huge timeshift happens, and also tries to do a couple of small things to fix the *worst* part of the consequences, such as throttling.

Let me know if you agree the above (first part ;p) has possibly happened.
(0013283)
hmtX (reporter)
2007-03-08 07:38
edited on: 2007-03-08 07:41

unfortunately i can't confirm that because something weird happened afterwards. after the TSCTL ALLTIME i could no longer perform any command, the the ircd was stalled like it is when it tries to catch up after a time change. i stayed connected for 10 minutes and told myself to wait it out, ever so often issuing /lusers to see when it would react again. after 10 minutes i suddenly got a * [10101] Host disconnected message and couldn't reconnect (because of the throttle).

ok er not that i wrote that... i reconnected 12:30, issued TDEBUG LIST at 13:11 where it output
slot=426, ip=XXX.134.221.XXX, since=1173349799, count=1, on_for=2485 [EXP]
End of /TDEBUG LIST

next time i did it was 14:00 where the list was empty. it has worked since then even after restarting the ircd.

/edit: TSoffset=0 since then. the server is standalone right now and not connected to the network, it was initially though until we noticed the throttle thing.

(0013284)
syzop (administrator)
2007-03-08 07:44
edited on: 2007-03-08 07:45

Ok, thanks :)

The "stalling" is indeed another effect of time change, I forgot if that happens if the time goes backwards or forwards, though ;p
It's the other thing I'll code a workaround for when timechanging, besides throttling.

EDIT: time shift = time

(0013285)
hmtX (reporter)
2007-03-08 07:49
edited on: 2007-03-08 08:24

it stalls for positive timeshifts until it has been caught. negative timeshifts are worse i guess ;o

/edit: manually changing TStime() back and forth is fun.

/edit2: while i'm ranting, i don't understand why there's a difference between
hash.c:796
for (i = 0; i < THROTTLING_HASH_SIZE; i++)

and tdebug.c:84
for (i=0; i <= THROTTLING_HASH_SIZE; i++)

~_~

(0013286)
djGrrr (reporter)
2007-03-08 09:13

perhaps we should use this report for the timechange stuff:
0003230
i think when adjusting timestamp offset, every timestamp should be updated (or at the least, ones that cause issues)
(0013287)
syzop (administrator)
2007-03-08 09:22

yes, we'll use 0003230 for this.

Note for future users experiencing this throttle bug: if you have not doneany time changes and can provide us with the TDEBUG stuff from above, let us know
(0013296)
djGrrr (reporter)
2007-03-09 22:54
edited on: 2007-03-09 22:56

Syzop, whats causing this bug is actually the event timers (not sure if you knew that or not)

[4] <- [:bunker.de.p2p-network.net 304 :slot=204, ip=85.17.40.165, since=1173501224, count=2, on_for=317 [EXP]]
[4] <- [:bunker.de.p2p-network.net 304 :slot=423, ip=85.17.40.167, since=1173500484, count=2, on_for=1057 [EXP]]
[4] <- [:bunker.de.p2p-network.net 304 :slot=434, ip=209.128.8.134, since=1173500216, count=3, on_for=1325 [EXP]]
[4] <- [:bunker.de.p2p-network.net 304 :slot=1004, ip=85.17.40.163, since=1173501137, count=3, on_for=404 [EXP]]

[4] <- [:bunker.de.p2p-network.net 304 :tklexpire: fptr=b7dc47d9, every=5, howmany=0, last=1173501587, owner=864b690]
[4] <- [:bunker.de.p2p-network.net 304 :htmcalc: fptr=b7db9403, every=1, howmany=0, last=1173501589, owner=864b690]
[4] <- [:bunker.de.p2p-network.net 304 :lcf: fptr=b7db950e, every=5, howmany=0, last=1173501587, owner=864b690]
[4] <- [:bunker.de.p2p-network.net 304 :modef_event: fptr=807f2b7, every=10, howmany=0, last=1173503741, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :bucketcleaning: fptr=8083db1, every=30, howmany=0, last=1173503730, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :unrealdns_removeoldrecords: fptr=807a60a, every=15, howmany=0, last=1173503736, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :cmodej_cleanup_structs: fptr=80874f0, every=60, howmany=0, last=1173503730, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :fdlistcheck: fptr=808584a, every=1, howmany=0, last=1173503743, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :loop: fptr=8085638, every=0, howmany=0, last=1173501589, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :garbage: fptr=8085588, every=600, howmany=0, last=1173503549, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :tunefile: fptr=80a4a6a, every=300, howmany=0, last=1173503549, owner=0]
[4] <- [:bunker.de.p2p-network.net 304 :ADDITIONAL INFO: now=1173501589, e_clean_out_throttling_buckets=8083db1]

[4] <- [:bunker.de.p2p-network.net NOTICE djGrrr_Marine :*** Server=bunker.de.p2p-network.net TStime=1173501660 time()=1173501662 TSoffset=-1]
[4] <- [:borg.nl.p2p-network.net NOTICE djGrrr_Marine :*** Server=borg.nl.p2p-network.net TStime=1173501661 time()=1173501663 TSoffset=0]
[4] <- [:grass.nl.p2p-network.net NOTICE djGrrr_Marine :*** Server=grass.nl.p2p-network.net TStime=1173501663 time()=1173501663 TSoffset=0]
[4] <- [:thecrypt.de.p2p-network.net NOTICE djGrrr_Marine :*** Server=thecrypt.de.p2p-network.net TStime=1173501662 time()=1173501662 TSoffset=1]
[4] <- [:meatball.se.p2p-network.net NOTICE djGrrr_Marine :*** Server=meatball.se.p2p-network.net TStime=1173501662 time()=1173501665 TSoffset=-3]
[4] <- [:hub.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=hub.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0]
[4] <- [:citadel.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=citadel.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0]
[4] <- [:juggernaut.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=juggernaut.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1]
[4] <- [:blizzard.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=blizzard.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1]
[4] <- [:base.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=base.us.p2p-network.net TStime=1173501664 time()=1173501664 TSoffset=0]
[4] <- [:juno.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=juno.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1]
[4] <- [:enterprise.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=enterprise.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1]
[4] <- [:mars.ca.p2p-network.net NOTICE djGrrr_Marine :*** Server=mars.ca.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0]
[4] <- [:drone.p2p-network.net NOTICE djGrrr_Marine :*** Server=drone.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0]
[4] <- [:area51.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=area51.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1]

my clock was behind by 1 hour (-3600). i synced it via ntpdate, then, when i synced the clocks with SVSTIME via services, it adjusted the event timers forward by 3600 seconds. so basically, you need to be able to detect system clock changes somehow
btw, i never started connecting to this server until i did all this clock syncing stuff

edit: or maybe, this would be easier...
detect when the "last" parameter for the event timers are ahead of current TStime(), if they are, readjust them

(0013300)
syzop (administrator)
2007-03-10 05:31

Yeah I know, see 0003230 :)
(0015704)
syzop (administrator)
2009-01-24 15:20

- 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
Date Modified Username Field Change
2005-05-10 05:44 durrie New Issue
2005-05-10 06:08 sin-x Note Added: 0009920
2005-05-10 06:09 sin-x Note Edited: 0009920
2005-05-10 06:14 durrie Note Added: 0009921
2005-05-10 06:20 sin-x Note Added: 0009923
2005-05-10 06:22 durrie Note Added: 0009924
2005-05-10 06:26 sin-x Note Added: 0009926
2005-05-10 06:29 durrie Note Added: 0009927
2005-05-10 06:34 sin-x Note Added: 0009928
2005-05-10 06:37 durrie Note Added: 0009929
2005-05-10 10:38 syzop Note Added: 0009931
2005-05-10 18:45 durrie Note Added: 0009933
2005-05-10 19:00 syzop File Added: TDebug.tar.gz
2005-05-10 19:04 syzop Note Added: 0009934
2005-05-10 19:05 syzop Note Edited: 0009934
2005-05-10 19:05 syzop Note Edited: 0009934
2005-05-10 19:17 durrie Note Added: 0009935
2005-05-10 19:40 durrie Note Edited: 0009935
2005-05-11 03:11 durrie Note Added: 0009936
2005-05-29 04:12 durrie Note Added: 0010010
2005-12-10 17:18 syzop Status new => closed
2005-12-10 17:18 syzop Note Added: 0010852
2005-12-10 17:18 syzop Resolution open => unable to reproduce
2006-09-04 09:50 syzop Note Added: 0012306
2006-09-04 09:50 syzop Status closed => acknowledged
2006-11-26 17:49 devil Note Added: 0012738
2006-11-26 17:56 devil Note Added: 0012739
2006-11-26 17:58 syzop Note Added: 0012740
2006-11-26 18:03 syzop Note Added: 0012741
2006-11-27 04:48 djGrrr Note Added: 0012742
2006-11-29 09:34 Jon335 Note Added: 0012764
2006-11-29 09:40 syzop Note Added: 0012765
2006-11-29 09:43 syzop Note Added: 0012766
2006-11-29 09:55 Jon335 Note Added: 0012767
2006-11-29 09:56 Jon335 Note Edited: 0012767
2006-11-29 10:02 syzop Note Added: 0012768
2006-11-29 10:02 syzop Note Edited: 0012768
2007-03-05 05:52 syzop Relationship added related to 0003252
2007-03-08 05:15 hmtX Note Added: 0013281
2007-03-08 05:20 hmtX Note Edited: 0013281
2007-03-08 06:09 hmtX Note Edited: 0013281
2007-03-08 07:10 hmtX Note Edited: 0013281
2007-03-08 07:18 syzop Note Added: 0013282
2007-03-08 07:38 hmtX Note Added: 0013283
2007-03-08 07:41 hmtX Note Edited: 0013283
2007-03-08 07:44 syzop Note Added: 0013284
2007-03-08 07:45 syzop Note Edited: 0013284
2007-03-08 07:45 syzop Note Edited: 0013284
2007-03-08 07:49 hmtX Note Added: 0013285
2007-03-08 07:57 hmtX Note Edited: 0013285
2007-03-08 08:24 hmtX Note Edited: 0013285
2007-03-08 09:13 djGrrr Note Added: 0013286
2007-03-08 09:22 syzop Note Added: 0013287
2007-03-09 22:54 djGrrr Note Added: 0013296
2007-03-09 22:56 djGrrr Note Edited: 0013296
2007-03-10 05:31 syzop Note Added: 0013300
2009-01-24 15:20 syzop QA => Not touched yet by developer
2009-01-24 15:20 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2009-01-24 15:20 syzop Status acknowledged => resolved
2009-01-24 15:20 syzop Fixed in Version => 3.2.8
2009-01-24 15:20 syzop Assigned To => syzop
2009-01-24 15:20 syzop Note Added: 0015704


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker