rlm_python failing

[Arran Cudbard-Bell]

> 
> The first line in our python accounting module is to radlog() so I know if
> the request hit our code, and that wasn't even happening

Hmm, so Python SDK has no timeout, and your complaint is that requests were never timing out?

Yes python is smart enough to release the GIL on blocking I/O, no there is not a mechanism to return control to the caller of the Python interpreter on blocking I/O.  At least none that i've found wandering through the shitty Python embedding documentation.

> so it seems as
> though FreeRADIUS+rlm_python had failed in some way.  Restarting freeradius
> resolved the problem.

No, your SDK failed, FreeRADIUS+rlm_python functioned as intended.

> I'm fairly certain the long request time problem is because the default
> timeout for the dynamo SDK is none (wait forever).  I'm working on setting
> a boto timeout to prevent the long response time from happening again, but
> at the moment I'm concerned about how freeradius was failing to even call
> python after a while.

No, all worker threads were blocked in the python module so there were no threads to call python after a while, they were all already calling python.

>  Aside from the boto timeout issue how would we go
> about debugging the freeradius+python problem to make sure it doesn't
> happen in the future?

Fix the SDK timeout.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150921/043d89e7/attachment.sig>