View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002479 | unreal | ircd | public | 2005-04-13 01:29 | 2005-04-15 10:23 |
| Reporter | w00t | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Summary | 0002479: Many glines cause problems when listing | ||||
| Description | Listing a *lot* of glines causes excess flood kills, this is not a Good Thing(tm) | ||||
| Steps To Reproduce | Create many, many glines or klines, and try to list them. | ||||
| 3rd party modules | |||||
|
|
Yes, this is well known. There have been many complaints about it on the support channel, but I don't know if anything can really be done about it. The best current workaround is to have your opers in a class that has a bigger sendq amount so they don't get killed. Also, you should make all your *lines expire in a reasonable amount of time (like 1 day at the most, and 1 week for *lines that are a must (such as highly abused proxies)). |
|
|
But the sendq is limited (or so I have heard) to a certain factor. There is a workaround, I was recently talking with a person who supposedly did a four-line patch to fix this problem (presumably he just disabled sendq kills) As for expiry, I'm playing with a bot that bans for a *long* time for *good* reason. |
|
|
uh-huh? This is really basic ircd knowledge! Just up your sendq to, say, 10mb for the oper class, and be sure in all your oper blocks you refer to that oper class. (Or be more careful with listing of course.) It's that simple, really. If you cannot configure your oper/class blocks right, that isn't our problem. |
|
|
[I know you're gonna shoot me for reopening this, but I feel I have to add something] Ok, so then it's designed behaviour to kill opers listing glines? Why then was list modified to avoid this same problem? Isn't it possible to have a safe banlist like it is with /list? I will experiment, but this problem has only hit me once or twice-- I'm also reporting on behalf of around two others who have asked for support on this issue, apparantly their "other ircds" they had experience with did not have this result, I didn't manage to gather what IRCd they were discussing, but I will try and find out. [edit] Please don't take this the wrong way, I just feel that it's wrong that opers (the "trusted" ones) or indeed anyone can get killed for being sent a large amount of data, I mean, sure if it's something like requesting MOTD 100000000 times per second, but then a penalty system like IRCDs could be considered or something? [/edit] |
|
|
if your opers are the trusted guys, you're talking about, you would propably not mind to build suitable connection-class-settings for their o:lines... for my understanding the whole connection/sendq/recq -stuff is a more basical and simple structure then most of the other functions within the ircd. if the queues are exceeded you fly away. It does neither look if that connection is an oper or a user, nor what kind transported data is - spamflooding, /list or /stats requests or anything else. It's just a counter - dropping the line if the set figures are exceeded. Since this is really simple to config i don't think its worth the time recoding every thing that might produce large amount of data - especially for commands better restricted to opers who should know what to do... |
|
|
/LIST is a special implementation, yes. Besides that, medice' story is right: it's just flood protection for the send queue in the ircd (it does not look at the contents of the data, just at the amount), otherwise if you queue some huge requests you can make the server eat up a lot of ram, so the client is killed for protection. There's really no IRCd with 'safe /stats' or anything I'm aware of, and it's also not needed IF YOU CONFIG YOUR SENDQ CORRECTLY... So why not do just that? Changing a few digits in the oper class isn't that hard... I always wonder why people don't know these relatively basic things, when I started with my first (ircnet) ircd I knew this in the 1st week, because I readed the docs/etc carefully and had enough normal IRC experience. I find it hard to believe that I'm such an exception. Basically when I fill in a number, I look up WHAT it means, that can't be such an amazing thought, really ;). Also, if you see your own quit (ask others if you didn't see any quit msg) and you see 'sendq exceeded' -- doesn't that ring a bell? |
|
|
Well, like I said, I only had one or two problems before tweaking it slightly as suggested :) But there are others out there :/ And it just... doesn't seem right that trusted users are subject to this. But oh well. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-04-13 01:29 | w00t | New Issue | |
| 2005-04-13 03:05 | Stealth | Note Added: 0009739 | |
| 2005-04-13 03:19 | w00t | Note Added: 0009740 | |
| 2005-04-13 09:04 | syzop | Status | new => closed |
| 2005-04-13 09:04 | syzop | Note Added: 0009741 | |
| 2005-04-15 01:52 | w00t | Status | closed => feedback |
| 2005-04-15 01:52 | w00t | Resolution | open => reopened |
| 2005-04-15 01:52 | w00t | Note Added: 0009752 | |
| 2005-04-15 01:54 | w00t | Note Edited: 0009752 | |
| 2005-04-15 06:19 | medice | Note Added: 0009755 | |
| 2005-04-15 08:41 | syzop | Note Added: 0009757 | |
| 2005-04-15 09:47 | w00t | Note Added: 0009758 | |
| 2005-04-15 09:48 | w00t | Note Edited: 0009758 | |
| 2005-04-15 10:23 | syzop | Status | feedback => closed |
