View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000794 | unreal | ircd | public | 2003-03-12 05:39 | 2003-11-20 19:46 |
| Reporter | mikron15 | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.2-beta15 | ||||
| Summary | 0000794: [BUG] Duplicate user entry in SJOIN! | ||||
| Description | I get this error msg mostly at the time of linking servers..I am using beta 15, freeBsd 4.7 OS, and Zip link support Notice -- [BUG] Duplicate user entry in SJOIN! Please report at http://bugs.unrealircd.org !!! Chan='#ALL-Movies', User='[AM]-MovXdcc01', modeflags=2 | ||||
| Steps To Reproduce | 5 out of 10 times attempted to relink servers using zip links | ||||
| Attached Files | error.log.bz2 (839 bytes) | ||||
| 3rd party modules | |||||
|
|
I have a similar problem. I'm currently running two Unreals on my localhost. If I activate ziplinks, there sometimes seem to be "transmission" errors. Usually it tells me *** Notice -- inflate() error(-3): invalid block type or *** Notice -- inflate() error(-3): invalid stored block lengths Sometimes the ircds stay linked, but I get the 'duplicate user' stuff. Example: --- *** Notice -- Missing user back... in SJOIN for #will from ora.test.net (@73 ~ !{RnAi #will be back...) --- *** Notice -- [BUG] Duplicate user entry in SJOIN! Please report at http://bugs.unrealircd.org !!! Chan='#warm', User='bottie-181', modeflags=0 --- *** Notice -- [BUG] Duplicate user entry in SJOIN! Please report at http://bugs.unrealircd.org !!! Chan='#warroom', User='bottie-249', modeflags=0 --- *** Notice -- Missing user :ora.test.net in SJOIN for #wam from ora.test.net (@73 ~ !{RnAi #wam ::ora.test.net 9 ora.test.net :ora2.test.net) --- *** Notice -- Missing user 9 in SJOIN for #wam from ora.test.net (@73 ~ !{RnAi #wam ::ora.test.net 9 ora.test.net :ora2.test.net) (I have the users bottie-1 - bottie-500 connected. They join #warrom, 'talk' there and part with the message 'bottie will be back'). I'm running Linux 2.4.19-4GB, using zlib 1.1.4. |
|
|
@ora: looks bad indeed, I wonder what causes that... Maybe I'll someday have the time to do a clonetest too, I've done it before and didn't have any problem, but maybe I can add some delay etc. Btw @duplicate user entry.. this also happens without ziplinks (even before it was implemented) and I still wonder what's causing it... IIRC I was thinking about kicks or something, don't remember it anymore... ora: since your whole data seems get's f*cked up somehow, I wouldn't trust :/. |
|
|
Damn, I didn't test whether that also happens with non ziped links. Now I did, and it happens :) There is no kick involved here. My bots only do the following: JOIN #warroom; sleep 6s; PRIVMSG #warroom :Bot x is here!; sleep 1s PART #warroom :Bot x will be back...; sleep 4s. Then they start joining again. I get random duplicate user entry notices. The point of the above messages was to show you the compression/transmisson/whatever errors. My 'net' didn't have the channel #will nor #wam at that time. If there is anything I can help you with to resolve one of these problems, let me know. |
|
|
Thanks. Hopefully I or other coders can reproduce it with those details. What's your net setup.. Just A<->B or do we need something more complicated to reproduce it? |
|
|
I think I never said thanks for the time and effort you guys are dedicating to Unreal. So accept a hug from me :-) The 'net' I used to test was as simple as it can be: Just A<->B, both running on the same machine. The clients (500 clones) all connected to A. On B there was just me to check for notices. I wasn't in any channel. ReleaseID 1.1.1.1.2.1.2.29. HTH. |
|
|
Hm I can't reproduce it here. Tried ehm: - connect 500 clones to A - A<->B are both at localhost linked (normal, no zip, no ssl) - sending a privmsg, a part and a join. Tried various things like normal part, part with reason, part with a nick as reason, etc... Tried cycle #chan too... but I don't get the duplicate msg thing :/. Btw do you also get the *** Notice -- Missing user <something>... without ziplinks? (not to be confused with the duplicate sjoin). If you have any idea's or want to give your clone prog; [email protected] My cloner connected 500 clients from ~100 ips, sends the command in sequence from highest clone (k0499) to lowest (k000) [/details]. edited on: 03-12 23:46 |
|
|
I also can't reproduce the ziplinks problem, tried with 700 clones. Also op'ed/voice'd etc them in another test.. but no bug / weird results :/ |
|
|
I've very little time, but I've been able to reproduce it. When I looked quickly at the packet dump it seems that sometimes messages are missing: T 127.0.0.1:46342 -> 127.0.0.1:6668 [AP] :bottie-365 D #warroom :Bot 365 will be back.....:bottie-364 ! #warroom :Bot 364 is here!..:bottie-364 D #warroom :Bot 364 will be back.. ...:bottie-363 ! #warroom :Bot 363 is here!..:bottie-363 D #warroom :Bot 363 will be back.....:bottie-362 ! #warroom :Bot 362 is here!..: bottie-362 D #warroom :Bot 362 will be back.....:bottie-361 ! #warroom :Bot 361 is here!..:bottie-361 D #warroom :Bot 361 will be back... ..:bottie-360 ! #warroom :Bot 360 is here!..:bottie-360 D #warroom :Bot 360 will be back.....:bottie-359 ! #warroom :Bot 359 is here!..:b ottie-359 D #warroom :Bot 359 will be back.....:bottie-358 ! #warroom :Bot 358 is here!..:bottie-358 D #warroom :Bot 358 will be back.... .:bottie-357 ! #warroom :Bot 357 is here!..:bottie-357 D #warroom :Bot 357 will be back.....:bottie-356 ! #warroom :Bot 356 is here!..:bo ttie-356 D #warroom :Bot 356 will be back.....:bottie-355 ! #warroom :Bot 355 is here!..:bottie-355 D #warroom :Bot 355 will be back..... :bottie-354 ! #warroom :Bot 354 is here!..:bottie-354 D #warroom :Bot 354 will be back..... T 127.0.0.1:46342 -> 127.0.0.1:6668 [AP] :bottie-352 ! #warroom :Bot 352 is here!..:bottie-352 D #warroom :Bot 352 will be back.....:bottie-351 ! #warroom :Bot 351 is here!..:bot tie-351 D #warroom :Bot 351 will be back.....:bottie-350 ! #warroom :Bot 350 is here!..:bottie-350 D #warroom :Bot 350 will be back.....: bottie-349 ! #warroom :Bot 349 is here!..:bottie-349 D #warroom :Bot 349 will be back.....:bottie-348 ! #warroom :Bot 348 is here!..:bott ie-348 D #warroom :Bot 348 will be back.....:bottie-347 ! #warroom :Bot 347 is here!..:bottie-347 D #warroom :Bot 347 will be back.....:b ottie-346 ! #warroom :Bot 346 is here!..:bottie-346 D #warroom :Bot 346 will be back.....:bottie-345 ! #warroom :Bot 345 is here!..:botti e-345 D #warroom :Bot 345 will be back.....:bottie-344 ! #warroom :Bot 344 is here!..:bottie-344 D #warroom :Bot 344 will be back.....:bo ttie-343 ! #warroom :Bot 343 is here!..:bottie-343 D #warroom :Bot 343 will be back.....:bottie-342 ! #warroom :Bot 342 is here!..:bottie -342 D #warroom :Bot 342 will be back.....:bottie-161 D #warroom :Bot 161 will be back..... note the missing 353 which exactly "in between" those two packets. I checked two duplicate sjoin notices and both had this, I'm not sure ofcourse.. but this might be the problem. And if sending/receiving/putting stuff together has problems then this would also explain why zip links in such a case will get f*cked up. I'm not able to debug or help any further atm, sorry. [additional info]there are also 324862394634324632 other cases where it goes well, so it's just an observation.. again, no time.[/additional info] edited on: 03-17 04:11 |
|
|
Playing secretary :) There were two other users on IRC who encountered the same bug: JAYates and Alias. Alias wants to add "it was on a 3.2b15 with ssl linking to a 3.2b15ipv6". |
|
|
I am using Unreal3.2-beta15 and i've tried to link with SSH & Ziplinks, only with SSH and with a normal link, i get the error in the three cases. My Net-map is: Server1.MyNet.Org Numeric 1 and HUB `-Server2.MyNet.Org Numeric 2 and HUB It seems when a user KICK somebody in a channel and both are in Server1, Server2 doesn't receive the PART or KICK, and when the user rejoins channel, the opers in Server2 get's a duplicated SJOIN error. It's still happening restarting and relinking Server2, but i didn't restart Server1 because i couldn't access it yet, i'll post if this bug clears restarting servers. Sorry for my bad english but i hope this hints help fix the bug. |
|
|
Hey, it's a problem related with tokens. I've commented in sendto_serv_butone_token function the part of check-token, leaving only the MSG part: /* if (IsToken(cptr)) { if (SupportNS(cptr) && pref[0]) { sendto_one(cptr, "@%s %s", pref, tcmd); } else { sendto_one(cptr, ":%s %s", prefix, tcmd); } } else {*/ if (SupportNS(cptr) && pref[0]) { sendto_one(cptr, "@%s %s", pref, ccmd); } else { sendto_one(cptr, ":%s %s", prefix, ccmd); } // } And problems related about duplicates SJOIN disappears. Please, check the token part. I've notified if my services uses tokens, some commands are ignored ( such as SVSMODE, and others ) maybe this is the problem too. ;oP |
|
|
What file/function are you referring to? |
|
|
i commented in send.c function "sendto_serv_butone_token" it seems that there is no problem sending tokens, but when the server receives tokens, it doesn't process it right. I've seen the AddCommand function but it seems ok. At this moment, i cannot find what's wrong, so i have to remove the TOKEN in PROTOCTL in common.h and it seems no problems with SJOINs. |
|
|
When the duplicate thing happens, it should write some stuff to ircd.log, could you please include that here? |
|
|
what would you lose disabling TOKEN? |
|
|
codemastr: How many do you need? :) [Sun Mar 23 22:56:46 2003] - [BUG] Duplicate user entry in SJOIN! Please report to UnrealIrcd team!! Chan='#warroom', User='bottie-197', modeflags=0 [Sun Mar 23 22:56:46 2003] - --- Dump of parameters --- [Sun Mar 23 22:56:46 2003] - parv[0] = 'ora.test.net' [Sun Mar 23 22:56:46 2003] - parv[1] = '!{VYsV' [Sun Mar 23 22:56:46 2003] - parv[2] = '#warroom' [Sun Mar 23 22:56:46 2003] - parv[3] = 'bottie-197 ' [Sun Mar 23 22:56:46 2003] - --- End of dump --- [Sun Mar 23 22:57:45 2003] - Connect - ora-test!~w@localhost [VHOST hid-38CC5594] [Sun Mar 23 22:59:49 2003] - [BUG] Duplicate user entry in SJOIN! Please report to UnrealIrcd team!! Chan='#warroom', User='bottie-155', modeflags=0 [Sun Mar 23 22:59:49 2003] - --- Dump of parameters --- [Sun Mar 23 22:59:49 2003] - parv[0] = 'ora.test.net' [Sun Mar 23 22:59:49 2003] - parv[1] = '!{VYtT' [Sun Mar 23 22:59:49 2003] - parv[2] = '#warroom' [Sun Mar 23 22:59:49 2003] - parv[3] = 'bottie-155 ' [Sun Mar 23 22:59:49 2003] - --- End of dump --- I also have lots of other duplicate join thingies, with modes and multiple users... available on request. BarArcade: Youd probably lose some bandwith and 'some' cpu time? |
|
|
what does token do, if you disable it, what functionality do you lose? edited on: 03-25 14:18 |
|
|
You shouldn't lose any functionality. See doc/technical/protoctl.txt (token TOKEN). But codemastr certainly knows better :) |
|
|
Tokens are a method of reducing CPU load (comparing 2 characters is faster than comparing 20) and bandwidth usage (2 characers is 2 bytes where as 20 characters is 20 bytes). Unreal will function 100% perfectly without tokens, although as of now I am doubting that tokens are the cause of this problem, but I will continue to look into it. And ora, since you say the log has a bunch of those messages, would you be able to upload your ircd.log somewhere and provide a url? |
|
|
[I'm refering to the net I described above, whithout active ZIP linking] I'm quite sure tokens don't have anything to do with the problem. I compiled my Unreals wihout token support and I was still able to reproduce the error. I attached my current error log. Unfortunately there aren't that many entries in it, but I can make you more, should you wish :D I also have an error log from a production environment (where this error occured [mainly?] during splits) but I don't think I should publicly share that; of course I'll provide it to the developers if needed. Furthermore I did some debugging (with the built in debug msgs only). I saw that A was going to send a part message to B, but B never received (or parsed) it. Hence the duplicate join problem in my case. I verified that trice, it was always the same problem. I can provide the debug logs (lvl 10) but I don't think it is very useful cause they're ~200 MB. They'll prolly be really small when bziped, so if you want them... :) BTW: I now know that grep'ing thru a 600 MB logfile is not fun :p |
|
|
Can you try this for me, in include/config.h find #undef JOIN_INSTEAD_OF_SJOIN_ON_REMOTEJOIN and change it to #define JOIN_INSTEAD_OF_SJOIN_ON_REMOTEJOIN Then recompile, tell me if you are still able to reproduce it. |
|
|
that disables the use of SJOIN Completely doesn't it? |
|
|
No it does not. |
|
|
codemastr: My flood script is running for 20 mins now and until now I coudln't reproduce it. With JOIN_INSTEAD_OF_SJOIN_ON_REMOTEJOIN undefined, the first errors usually showed up in less than 2 minutes. I'll let it run for some hours and check back when I'm awake again. (running .1690 of course ;) ) [edit] Running for 6:30 hrs now. Still no bad notice. Stats: C 911701 9117008 D 913339 39026960 ~ 2285 68511 Hmm, you think it would even yell when the duplicate user bug occurs? :) edited on: 03-27 02:21 |
|
|
I've started tracing this again and I can tell you the part message isn't even sent over the wire. The reason you don't get any warnings is because there's no duplicate-user check in m_join, only in m_sjoin :). Anyway, I'll try to find out the cause.. :) |
|
|
:bottie-521 ! #warroom :Bot 521 is here!M :bottie-521 D #warroom :Bot 521 will be back...M :bottie-522 ! #warroom :Bot 522 is here!M :bottie-522 D #warroom :Bot 522 will be back...M :bottie-523 ! #warroom :Bot 523 is here!M :bottie-523 D #warroom :Bot 523 will be back...M :bottie-524 ! #warroom :Bot 524 is here!M :bottie-524 D #warroom :Bot 524 will be back...M :bottie-526 ! #warroom :Bot 526 is here!M :bottie-526 D #warroom :Bot 526 will be back...M :bottie-527 ! #warroom :Bot 527 is here!M :bottie-527 D #warroom :Bot 527 will be back...M :bottie-528 ! #warroom :Bot 528 is here!M :bottie-528 D #warroom :Bot 528 will be back...M where's 525? :P -- remote serv -- [23:25:42] <bottie-523> Bot 523 is here! [23:25:42] *** bottie-523 (w@localhost) has left #warroom (Bot 523 will be back...) [23:25:42] <bottie-524> Bot 524 is here! [23:25:42] *** bottie-524 (w@localhost) has left #warroom (Bot 524 will be back...) [23:25:42] <bottie-526> Bot 526 is here! [23:25:42] *** bottie-526 (w@localhost) has left #warroom (Bot 526 will be back...) [23:25:42] <bottie-527> Bot 527 is here! -- local serv -- [23:25:41] <bottie-523> Bot 523 is here! [23:25:41] *** bottie-523 (w@localhost) has left #warroom (Bot 523 will be back...) [23:25:41] <bottie-524> Bot 524 is here! [23:25:41] *** bottie-524 (w@localhost) has left #warroom (Bot 524 will be back...) [23:25:41] <bottie-525> Bot 525 is here! [23:25:41] *** bottie-525 (w@localhost) has left #warroom (Bot 525 will be back...) [23:25:41] <bottie-526> Bot 526 is here! [23:25:41] *** bottie-526 (w@localhost) has left #warroom (Bot 526 will be back...) [23:25:41] <bottie-527> Bot 527 is here! =========== ANOTHER TRACE ============= This time it creates 2 logs... servername.buf = before it gets queued, servername.traffic = right before it gets sent over the wire so a nice diff -u between those gives: # diff -u maintest.hok.net.buf maintest.hok.net.traffic --- maintest.hok.net.buf Thu Apr 10 23:44:35 2003 +++ maintest.hok.net.traffic Thu Apr 10 23:44:35 2003 @@ -7532,7 +7532,6 @@ @x ~ !{bUIb #warroom :bottie-524 @x ~ !{bUIb #warroom :bottie-525 @x ~ !{bUIb #warroom :bottie-526 -@x ~ !{bUIb #warroom :bottie-527 @x ~ !{bUIb #warroom :bottie-528 @x ~ !{bUIb #warroom :bottie-529 @x ~ !{bUIb #warroom :bottie-530 @@ -8694,8 +8693,6 @@ :bottie-493 D #warroom :Bot 493 will be back... :bottie-494 ! #warroom :Bot 494 is here! :bottie-494 D #warroom :Bot 494 will be back... -:bottie-495 ! #warroom :Bot 495 is here! -:bottie-495 D #warroom :Bot 495 will be back... :bottie-496 ! #warroom :Bot 496 is here! :bottie-496 D #warroom :Bot 496 will be back... :bottie-497 ! #warroom :Bot 497 is here! @@ -8742,7 +8739,6 @@ :bottie-517 D #warroom :Bot 517 will be back... :bottie-518 ! #warroom :Bot 518 is here! :bottie-518 D #warroom :Bot 518 will be back... -:bottie-519 ! #warroom :Bot 519 is here! :bottie-519 D #warroom :Bot 519 will be back... :bottie-520 ! #warroom :Bot 520 is here! :bottie-520 D #warroom :Bot 520 will be back... Hm ;) So it get's lost between queued and sending... interresting ;) |
|
|
Syzop: Since people brought it up, if you disable TOKENs does it then work correctly? |
|
|
Nope :/. # diff -u maintest.hok.net.buf maintest.hok.net.traffic --- maintest.hok.net.buf Fri Apr 11 00:15:38 2003 +++ maintest.hok.net.traffic Fri Apr 11 00:15:38 2003 @@ -6742,7 +6742,6 @@ :bottie-267 PART #warroom :Bot 267 will be back... :bottie-266 PART #warroom :Bot 266 will be back... :bottie-265 PART #warroom :Bot 265 will be back... -:bottie-264 PART #warroom :Bot 264 will be back... :bottie-263 PART #warroom :Bot 263 will be back... :bottie-262 PART #warroom :Bot 262 will be back... :bottie-261 PART #warroom :Bot 261 will be back... But maybe you get it fewer times ;P. |
|
|
Traced, now fixing it. |
|
|
Now fixed in CVS (.1716), paste from Changes: - Fixed MAJOR "messages are lost" bug which can cause various problems: ziplink corruption, duplicate user entry in sjoin, etc etc. This would happen if BUFFERPOOL was set too low (like the default) and you got a lot of traffic. It's now handled a bit better and you'll get a nice warning, additionally the default BUFFERPOOL is now set to MAXSENDQLENGTH*18 instead of *9. With this new default I was unable to reproduce the problem, the client's sendq was hit earlier ;P. I also tested the warning/error system by setting BUFFERPOOL to *4 and then I get: -- snip -- [02:00:56] -maintest.hok.net- *** Notice -- Client exiting: bottie-550 (w@localhost) [Buffer allocation error] [02:00:56] -maintest.hok.net- *** Notice -- Client exiting: bottie-549 (w@localhost) [Buffer allocation error] [02:00:56] -maintest.hok.net- *** Notice -- Client exiting: bottie-546 (w@localhost) [Buffer allocation error] [02:00:58] -maintest.hok.net- *** Notice -- *** TROUBLE: buffer allocation error! Increase BUFFERPOOL! *** isn't that nice!?!? ;PP Thanks everyone for helping and reporting ;). |
|
|
I assume, http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000793 http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000820 http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000824 Are all the same? Also, what about, http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000569 http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000774 Based on the changes you made, do you think those would have been caused by the same thing? Resolve whichever ones you think were related... |
|
|
Ok, closed 0000793, 0000820, 0000824, 0000569 (possible indeed), and waiting for reply at #0000774. Thanks for the search ;P. |
|
|
Hmm, in tests i have done with Unreal, exposed in my post of 03-23-03 at 01:23 i didn't got a lot of traffic, i only do a kick in a channel, and the problem with services, some commands aren't processed by the uplink of services if services send it in token, but is processed if in text. |
|
|
I also have these messages in my ircd.log. My question is this, has anyone had the server seg fault because of or is this a possibility? After 2 servers with over 30 day uptimes since first upgrading to Beta15, 2 of our servers have crashed without warning twice today. Both with good filteration policies so I don't think we're being DDoS'd and no sign of any lag. There was no output in the ircd.log , all I have is this: "Program terminated with signal 11, Segmentation fault" and it dumped the core. Anyone else reported just random crashes? lastly.. i read the above a few times. But to be clear, by up'ing the MAXSENDQLENGTH does it seem to solve these s_join errors? Should "#undef JOIN_INSTEAD_OF_SJOIN_ON_REMOTEJOIN" be changed to ===> #define JOIN_INSTEAD_OF_SJOIN_ON_REMOTEJOIN anywho.. thanks in advance. i'll browse the rest of this board |
|
|
question... the SSL bug reported in another bug track as 'resolved' today and what is mentioned above sounds pretty promising to fix my latest issues. Is this the version in the latest CVS i.e: cvs -z3 -d :pserver:[email protected]:/home/cmunk/ircsystems/cvsroot co -r beta -d Unreal unreal sorry.. just never had to use the CVS before for Unreal because it's already been pretty stable for us. But 4 crashes in one day, 2 to each server.. well something is up :). thx |
|
|
Pryan/blahblah: http://www.vulnscan.org/UnrealIrcd/ has both new win cvs builds and contains the latest cvs .tar.gz which has the fix. Or even better, you can use cvs, it's indeed not mentioned at the page: cvs -d :pserver:[email protected]:/home/cmunk/ircsystems/cvsroot login [press enter if asked for pass] cvs -d :pserver:[email protected]:/home/cmunk/ircsystems/cvsroot co -r devel -d Unreal unreal blahblah: if you still get crashes _after_ this upgrade, PLEASE report! :). You can send the core + ircd binary to [email protected] then if you want. Pryan: you have another problem? I'm not sure if I understand, but it looks like a services issue, right? ;P. Please upgrade anyway, just to be sure ;P. If you still have the problem, maybe you can create a new bugreport and give some details like the network traffic (what does it respond to, what does it ignore, what does happen, etc). |
|
|
ahhh damnit. i thought i had the right CVS . i had installed the latest one use the -r beta flag. thanks syszop.. i'm installing the latest CVS on all 3 servers we have and if any go down we'll be bringing it back up as the CVS. thanks.. i'll sure to get back with any more useful bugtracking info and i've already requested from my other admin to send me the dumped core ... |
|
|
*close bug*. See ealier, fixed in CVS. If anyone can reproduce this with current CVS then please re-report :). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-04-10 21:38 | syzop | Note Added: 0002231 | |
| 2003-04-10 21:53 | syzop | Note Added: 0002232 | |
| 2003-04-10 22:02 |
|
Note Added: 0002233 | |
| 2003-04-10 22:20 | syzop | Note Added: 0002234 | |
| 2003-04-10 23:13 | syzop | Note Added: 0002235 | |
| 2003-04-11 00:12 | syzop | Note Added: 0002236 | |
| 2003-04-11 02:32 |
|
Note Added: 0002238 | |
| 2003-04-11 02:42 | syzop | Note Added: 0002247 | |
| 2003-04-11 04:22 | Pryan | Note Added: 0002248 | |
| 2003-04-11 06:32 | blahblah | Note Added: 0002249 | |
| 2003-04-11 07:22 | blahblah | Note Added: 0002251 | |
| 2003-04-11 13:35 | syzop | Note Added: 0002252 | |
| 2003-04-11 17:55 | blahblah | Note Added: 0002266 | |
| 2003-04-11 19:47 | syzop | Severity | feature => minor |
| 2003-04-11 19:47 | syzop | Status | new => confirmed |
| 2003-04-11 19:47 | syzop | Summary | Notice -- [BUG] Duplicate user entry in SJOIN! Please report at <a href="http://bugs.unrealircd.org">http://bugs.unrealircd.org => [BUG] Duplicate user entry in SJOIN! |
| 2003-04-12 17:23 | syzop | Status | confirmed => resolved |
| 2003-04-12 17:23 | syzop | Resolution | open => fixed |
| 2003-04-12 17:23 | syzop | Assigned To | => syzop |
| 2003-04-12 17:23 | syzop | Note Added: 0002293 | |
| 2003-11-20 19:46 | syzop | Status | resolved => closed |
