View Issue Details

IDProjectCategoryView StatusLast Update
0002943unrealircdpublic2013-05-07 01:48
ReporterstskeepsAssigned Tonenolod 
Status resolvedResolutionfixed 
OSFedora CoreOS Version4 (sec. patch?) 
Product Version3.2.5 
Target Version3.3-alpha0Fixed in Version3.4-alpha1 
Summary0002943: ircd logging: use fflush instead of fopen+fclose all the time
DescriptionI noticed we open/close the ircd log each time. how about we simply flush instead and keep the fd open? Should be better for performance?
Additional Information** NOTE: The below is about the discussion of a 99% CPU increase issue, but this was actually about regex, this issue is kept for the fopen+fclose --> fflush thing **
TagsNo tags attached.
3rd party modules



2006-06-03 07:29

administrator   ~0011828

Logging never showed any (significant) cpu impact in my speedresults. So if there was any cpu increase or spike or even 99% cpu usage that must be some kind of bug.

I too, have wondered why we do the close+open thing all the time instead of fflush(), maybe the author was lazy. Though the (only?) good thing about it is that you don't have to worry if someone rm's the file ;)


2006-06-04 13:15

reporter   ~0011840

If I recall, it was because of Windows. I seem to remember there having been an issue where if we didn't fclose(), and I tried to open the file in notepad, it would give one of those fun "file is in use" errors but I think that was only a Win 9x issue so it could easily be changed now.


2006-06-04 16:07

reporter   ~0011844

New material which has gotten us to realize what the problem is

// block repeting letters
spamfilter {
        regex "^.*(\w)\1{15,}.*$";
        target channel;
        action block;
        reason "Chars flood";

This, with a normal user flooding and moderate server traffic, causes the ircd to go high up in CPU (15%, where normal traffic is 1-2%. A ltrace is at ). With a good amount of users doing the same, it'd reach 99%


2006-06-04 16:41

reporter   ~0011845

Backreferences are an NP-complete problem. That kinda makes it inefficient by definition, doesn't it?


2006-06-04 16:42

administrator   ~0011846

Last edited: 2006-06-04 16:45

codemastr: ack :P

stskeeps: yeah regexes can be a pain, especially with backrefs.. the TRE author even said to me "if you care about speed, don't use backreferences" ;P

EDIT: *grin* timing ;p


2006-06-05 04:32

reporter   ~0011855

Last edited: 2006-06-05 04:33

Well, true, but it would be a hell lot more efficient if it didn't go out and do a strncmp to compare one character.. and just did a char comparision instead :>


2006-06-05 16:36

administrator   ~0011863

So..... now this bugreport is screwed up.. what to do about it...

Since we cannot do anything about regex, and the TRE author probably can't either, I suppose I'll keep it as-is for the fflush-logging tactic, and rename it to that ;p


2006-06-05 21:54

reporter   ~0011869

[quote]Well, true, but it would be a hell lot more efficient if it didn't go out and do a strncmp to compare one character.. and just did a char comparision instead :>[/quote]
Well, you know C, stop being lazy and go make a patch :P


2006-06-06 10:17

administrator   ~0011879

Let's move this regex talk to 0002887, even though that is about ++ :P


2007-06-21 15:43

reporter   ~0014398

Fixed in .2446


2013-05-07 01:47

reporter   ~0017510

Issue History

Date Modified Username Field Change
2006-06-03 07:25 stskeeps New Issue
2006-06-03 07:29 syzop Note Added: 0011828
2006-06-03 07:41 syzop Relationship added child of 0002936
2006-06-04 13:15 codemastr Note Added: 0011840
2006-06-04 16:07 stskeeps Note Added: 0011844
2006-06-04 16:41 codemastr Note Added: 0011845
2006-06-04 16:42 syzop Note Added: 0011846
2006-06-04 16:45 syzop Note Edited: 0011846
2006-06-05 04:32 stskeeps Note Added: 0011855
2006-06-05 04:33 stskeeps Note Edited: 0011855
2006-06-05 16:36 syzop Note Added: 0011863
2006-06-05 16:38 syzop Summary Problem with 99% cpu with connection logging enabled => ircd logging: use fflush instead of fopen+fclose all the time
2006-06-05 16:38 syzop Description Updated
2006-06-05 16:38 syzop Additional Information Updated
2006-06-05 21:54 codemastr Note Added: 0011869
2006-06-06 10:17 syzop Note Added: 0011879
2006-11-03 17:40 syzop Relationship deleted child of 0002936
2007-04-27 03:25 stskeeps Status new => acknowledged
2007-05-19 14:38 Trocotronic Status acknowledged => assigned
2007-05-19 14:38 Trocotronic Assigned To => Trocotronic
2007-06-11 12:50 stskeeps Assigned To Trocotronic =>
2007-06-11 12:50 stskeeps Status assigned => acknowledged
2007-06-21 15:43 stskeeps Status acknowledged => resolved
2007-06-21 15:43 stskeeps Fixed in Version => 3.3-alpha0
2007-06-21 15:43 stskeeps Resolution open => fixed
2007-06-21 15:43 stskeeps Assigned To => stskeeps
2007-06-21 15:43 stskeeps Note Added: 0014398
2011-07-19 13:48 syzop Assigned To stskeeps =>
2011-07-19 13:48 syzop Status resolved => needs re porting
2011-07-19 17:11 syzop Target Version => 3.3-alpha0
2013-05-07 01:47 nenolod Note Added: 0017510
2013-05-07 01:47 nenolod Status needs re porting => resolved
2013-05-07 01:47 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2013-05-07 01:47 nenolod Assigned To => nenolod