Module return codes
aland at deployingradius.com
Mon Oct 21 15:10:24 CEST 2013
Phil Mayers wrote:
> Where did we get with this? At the moment, I can't proceed with a
> migration to 3.x in the absence of last return code, and I don't want to
> use my local patch if it's not going upstream.
I just merged it.
> It doesn't look easy to do this with an xlat; the "last" return code
> only exists as local variable(s) in modcall_* functions, so we'd need to
> grow the request object to store it. Even the highest-prio code only
> exists on the relevant modcall_stack_entry_t struct, and an xlat has no
> easy way to know the position in the modcall stack/tree.
For 3.1, we'll add the modcall stack, and current stack index to the
REQUEST structure. It's very useful to have it there. It allows things
like proxying in a module, and then resumption from where it left off.
> I would appreciate a steer; we have serious problems with load spikes
> and time spent on this in 2.x is wasted IMO, so I need to get onto 3.x
> and then tackle the problem.
Grab v3.0.x now, it has your patch. The load spikes are a bit
different, of course.
I suspect that 3.0 will have better debugging than 2.0. You should
also be able to set triggers (SNMP or "exec") on certain events. If
there isn't a trigger for an event you want, adding one is ~2 lines of code.
More information about the Freeradius-Devel