3.x behaviour w.r.t. unused modules
I've just noticed something odd. If I have a module in mods-enabled but it's not referenced anywhere, FreeRADIUS still seems to load it and perform module instantiation including e.g. setting up connection pools. I don't think 2.x used to do that, or am I imagining it? For us that's undesirable as we use "radiusd -n" and start several processes up, and I don't really want to have multiple mods-enabled just to avoid instantiating e.g. SQL/redis/LDAP connections in server processes that don't reference the module. I can work around it, but am wondering if this is expected?
Phil Mayers wrote:
I've just noticed something odd. If I have a module in mods-enabled but it's not referenced anywhere, FreeRADIUS still seems to load it and perform module instantiation including e.g. setting up connection pools.
That's how it works. It's an enabled module.
I don't think 2.x used to do that, or am I imagining it?
2.x didn't do that, because it had no "mods-enabled" directory. It loaded all of the modules which were used. Adding a mods-enabled directory solved some problems with the way that v2 did it. But... at the cost of other side effects.
For us that's undesirable as we use "radiusd -n" and start several processes up,
Hmm... that's what virtual servers are for, right?
and I don't really want to have multiple mods-enabled just to avoid instantiating e.g. SQL/redis/LDAP connections in server processes that don't reference the module.
I can work around it, but am wondering if this is expected?
It's expected. Alan DeKok.
On 31/08/14 16:31, Alan DeKok wrote:
For us that's undesirable as we use "radiusd -n" and start several processes up,
Hmm... that's what virtual servers are for, right?
Processes protect against segfaults and other app/library errors. They can also be restarted independently. This is useful to avoid blowing away one servers in-progress (and on 2.x cached) EAP sessions. At peak times, that can be a real win; I don't really trust HUP TBH. We use virtual servers as well; each process is one or more virtual servers grouping the same functionality e.g. all the wireless in one process, all the macauth in another. It also discourages config bleed-in; if the macauth process *has* to be on a separate port and/or IP, I avoid the temptation to smoosh them into one vserver with if/else, then find I can't break it back out at a later date. I probably wouldn't do it this way now, but it evolved back in very early 2.0 days when we did have a few periodic segfaults and I wanted to isolate things, and now we've got the config, there's no real cost to keeping it. If the mods thing is expected, I'll work around it.
participants (2)
-
Alan DeKok -
Phil Mayers