michael at stroeder.com
Tue Sep 22 08:12:00 CEST 2015
Andrew Parisio wrote:
> Like I said in my original email we are aware of the problems caused by the
> lack of a timeout and are actively working to fix that,
> My question was that even after dynamo recovered FreeRADIUS continued to
> fail to call python, and I wanted to make sure that even after we fix the
> timeout issue that there isn't another problem that could be triggered.
Disclaimer: I don't know the FreeRADIUS internals and never used rlm_python.
But first I'd solve the timeout issue and then re-test. Before that your
analysis will always be unassured.
> Are you suggesting the only possible explanation for what we saw was that
> all of the worker threads were still waiting for a response from dynamo 2
> days later, and that there is no point in debugging why FreeRADIUS was
> unable to execute rlm_python? I suppose that's possible but it seems
> unlikely that that many sockets were hung open for that long. Is there any
> way to see what the worker threads were doing?
Also I'm not sure whether directly embedding Python/Perl/whatever interpreters
in a server process is a good approach. For various reasons I usually prefer
to implement a separate server process (e.g. in Python) listening on a Unix
domain socket. This gives you more control and you can better isolate blocking
problems in your own external listener.
Not sure whether current FreeRADIUS has such an interface though.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
More information about the Freeradius-Users