View Issue Details

IDProjectCategoryView StatusLast Update
0000585unrealircdpublic2016-12-29 10:55
ReporterWraith Assigned Tosyzop  
Status resolvedResolutionfixed 
Platform*nixOSRedhatOS Version8?
Product Version3.2-beta13 
Fixed in Version4.0.10 
Summary0000585: [config] include files aren't directly included
Descriptionwhen starting the ircd:

Starting UnrealIRCd
 _ _ _ ___________ _____ _
| | | | | |_ _| ___ \/ __ \ | |
| | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| |
| | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` |
| |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |
 \___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|
* Loading IRCd configuration ..
* unrealircd.conf:29: illegal link::class, unknown class 'servers' using default of class 'default'
* Configuration loaded without any problems ..
* Dynamic configuration initialized .. booting IRCd.

I've also tried changing the link class to operators, same error.
Steps To ReproduceWill happen when I have class { ... }; blocks in another included file.

unrealircd.conf includes the .network, which has the class { ... }; block.

When moving the class block to unrealircd.conf, starts up fine, no error.
Additional Information--> See syzop's bug note 0000585:0017273 for proposed solution (or just read all bug notes)
TagsNo tags attached.
3rd party modules


has duplicate 0002831 closed Unknown class 'clients' in oper block (CVS .467) 
has duplicate 0000907 closedsyzop problem with .conf files 
has duplicate 0000936 closedsyzop Class definitions invisible to link definitions when included 
has duplicate 0004146 closedsyzop order of remote include processing not guaranteed 



2002-12-28 08:20

reporter   ~0000944

didn't seem to put the bug recreation notes...

comes up with the error when the class block is not in the unrealircd.conf - error is present when the class block is in the .network, not present when in the unrealircd.conf


2002-12-29 19:00

reporter   ~0000959

That's right, I'm having the same problem.

include "classes.conf";

        ip *@*;
        hostname *@*;
        class clients;
        maxperip 3;

I've made sure that the class definitions are before my allow{} directive.


2003-01-06 19:03

reporter   ~0000979

What about this problem, coders? It seems that the configuration parser doesn't care where include:: directives are located, and they are loaded after the main configuration file. This causes the error descripted above. I could solve the problem myself putting allow::, class::, link::, etc. directives to one configuration file or each directive to separate files in the right order. But they aren't the best solution, are they?


2003-01-20 02:58

administrator   ~0001105

Changed title. Not a nice bug indeed... maybe someone else can fix this (/me doesnt expect a fix soon ;P).


2003-04-20 19:52

administrator   ~0002433

[quote duplicate bug from creative1 (0000907)]

this is the problem, when you define the class for connections (the old Y lines) you have to do it on unrealircd.conf you can't do it in any external files

my problem came when i wanted to do a general.conf file for all the network with all the common stuff, which included the configuration for the Y lines, i put the class server and class client there
then i did a include general.conf from the unrealircd.conf and it will never find the connection classes no matter what i did

I had to move the connection classes to unrealircd.conf and then it works.

Just test it out... simple to check.


2003-04-30 18:54

administrator   ~0002579

[quote duplicate bug from aragon (0000936)]
 If classes are defined in a separate file and then included from unrealircd.conf all definitions are not usable from any link blocks lower down (or higher up) in unrealircd.conf.

This bug has been present since conf3 from beta13 IIRC.
 Errors on startup:

* Loading IRCd configuration ..
* unrealircd.conf:117: illegal link::class, unknown class 'hub_services' using default of class 'default'
* unrealircd.conf:128: illegal allow::class, unknown class 'clients' using default of class 'default'


2004-10-19 22:23

reporter   ~0008047

Well, one option is this :) (probably won't happen but once can dream eh?).

We run two seperate passes through unrealircd.conf:

The first pass scans for includes and reads them in textually, similar to how #include from C(++) works.

The second pass scans the resulting configuration as normal.

Essentially do it like how C(++) does it. If necessary, make an internally used directive to modify the filename/linenumber (like #line) so that error reporting works right.


2004-10-19 22:59

reporter   ~0008048

aquanight forgot to say this still exists in 3.2.1

Another suggestion for conf reading:
Unreal can read the conf's and put everything from the main conf and includes in 1 file in the tmp dir. Then load that file. (I dont know if this is what aqua was saying, but its in simple terms)


2004-10-20 12:59

reporter   ~0008050

Bugz: that essentially was what I was thinking. That's actually essentially how C(++) preprocessors do their work (except, I guess, when you do gcc -pipe, or for something like CL where it's all in one bundle). Though I was thinking more like storing an in-memory copy so that we don't need to keep track of yet ANOTHER temporary file :/ .


2004-10-20 13:30

reporter   ~0008051

But in-memory takes more memory!


2004-10-24 07:56

reporter   ~0008100

Only temporarily, if he's suggesting how I think he is.


2004-10-30 21:38

reporter   ~0008188

Only during startup and rehashes.


2006-10-17 14:30

reporter   ~0012499

Under aquanight's system, please parse includes until you run out. I have a master remote include file, which remote includes the actual include files and serves to keep them organized, but allows me to restructure without going everywhere, if I need to. Don't break me!


2012-12-17 10:46

administrator   ~0017273

Basically the idea is to fetch all includes, as aquanight mentioned. This is already done AFAIK: we only scan for include's in each file, and every time we see one we queue the download, only after all remote includes are fetched (including remote includes that fetch other remote includes), only after that the real parsing starts...
The change proposed is then to 'merge' all these includes in one (virtual) "file".
I say "file", but this has to be done in memory, so file names and line numbers are kept intact.
It's of no use if you would get an error like:
mergedconfig.6523865238.tmp.conf:2643: Missing quote
...which makes tracing errors impossible.

Resolving this bug may require quite some effort, but if someone wants to give it a try, then feel free to do so! ;)

For Unreal3.4, not 3.2, naturally.


2016-12-29 10:55

administrator   ~0019577

commit cbcbdc656a8f7bd1f58a4fd7ea0cf04dfa180859
Author: Bram Matthys <>
Date: Thu Dec 29 10:38:10 2016 +0100

    The 'class' block is now always read before 'allow'. No specific order required anymore.

I know, this doesn't fix the "include files aren't directly included" but in practice this issue has always been about class blocks not being read first and that issue is solved now :)

Issue History

Date Modified Username Field Change
2003-04-20 19:52 syzop Note Added: 0002433
2003-04-30 18:54 syzop Note Added: 0002579
2004-10-19 22:23 aquanight Note Added: 0008047
2004-10-19 22:59 Stealth Note Added: 0008048
2004-10-20 12:59 aquanight Note Added: 0008050
2004-10-20 13:30 Stealth Note Added: 0008051
2004-10-24 07:56 w00t Note Added: 0008100
2004-10-30 21:38 aquanight Note Added: 0008188
2004-12-08 12:40 syzop Relationship added has duplicate 0002228
2004-12-08 12:41 syzop Relationship deleted has duplicate 0002228
2006-02-23 09:37 syzop Relationship added has duplicate 0002831
2006-02-23 09:40 syzop Relationship added has duplicate 0000907
2006-02-23 09:40 syzop Relationship added has duplicate 0000936
2006-10-17 14:30 JasonTik Note Added: 0012499
2012-12-15 20:29 syzop Relationship added related to 0004146
2012-12-17 10:44 syzop Relationship replaced has duplicate 0004146
2012-12-17 10:46 syzop Note Added: 0017273
2012-12-17 10:49 syzop Additional Information Updated View Revisions
2016-12-29 10:55 syzop Assigned To => syzop
2016-12-29 10:55 syzop Status confirmed => resolved
2016-12-29 10:55 syzop Resolution open => fixed
2016-12-29 10:55 syzop Fixed in Version => 4.0.10
2016-12-29 10:55 syzop Note Added: 0019577