On Sat, Sep 04, 2004 at 07:56:29PM +0200, Thor Spruyt wrote:
> Paul Hampson wrote:
> > New behaviour: (Replaces behaviour identical to <0 above)
> > If the program returns 1 through RLM_MODULE_NUMCODES, return the
> > appropriate code and attributes as expected.
[trim]
> > If it returns > RLM_MODULE_NUMCODES, return RLM_MODULE_OK. (as for 0)
> Maybe it's better to return RLM_MODULE_FAIL in this case.
Yes, quite probably. I only noticed afterwards (when checking the
usage of the return value for the last paragraph) that normally >0
is RLM_MODULE_FAIL too.
This seems wrong to me, in so far as I expect <0 to be failure, and
>0 success, but for historical reasons you're right.
> > This should work for everyone using 0 = success and -1 = failure, but
> > I'll prolly catch people who're using >0 for failure, which is
> > possible but (slightly) deranged. ^_^;
> I guess they can easily change their programs if this is the case.
> Otherwise a configuration option which activates this new behaviour might
> solve this:
> rlm_module_returncodes = yes
> If this configuration item is "yes", then use the new return code
> interpretation (maybe without the -1):
> If this configuration item is absent or anything else than "yes", then use
> the old return code interpretation (0=ok, !0=fail)
I'm hoping to avoid another configuration option. The idea is to make
it a slightly painful but important migration... The _goal_ is to get
rlm_exec to be a fully-useful replacement for Exec-Program{,-Wait} so
we can get rid of the latter, which has (as I understand) problems we
don't want to (or can't reasonably) fix.
> > This then leads the question, what return code do we want for when the
> > child process terminates abnormally? (!WIFEXITED or rad_waitpid
> > returns something other than the child's pid)... If we leave it as it
> > is, it's RLM_MODULE_REJECT with the below patch... Would
> > RLM_MODULE_FAIL be better? (Changes return 1 at src/main/exec.c:390
> > to return 2... This
> I guess RLM_MODULE_FAIL would be better here.
OK.
--
Paul "TBBle" Hampson, on an alternate email client.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
