Hi Phil,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's not completely unreasonable, but be aware that the server thread is entirely blocked whilst waiting for the exec to complete. If all threads in the pool are blocked, you'll have serious problems.<br>
<br>
Basically: 10 seconds is a long to wait, so waiting even longer... I'm kind of curious what you're doing?<br>
<br></blockquote><div><br></div><div>Well, the script is waiting for user interaction to authorize the radius transaction. (which will take up to 2 minutes)</div><div>And in our proof of concept we're using a shell script with rlm_exec.</div>
<div><br></div><div>If there's another way to achieve this. e.g. by letting freeradius invoke the shell script like every 10s and check if the request is still pending or already accepted or denied, that would also be an acceptable solution.</div>
<div><br></div><div>Philipp</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, enough people already get confused about this w.r.t. SQL/LDAP databases that are slow - the complain "the server is slow", when in fact the server is *blocked*. So you might want to surround this config option with BIG BOLD TEXT explaining this ;o)<br>


<br>
Personally I think the option might be more generally useful for *decreasing* the timeout!<br>
-<br>
List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/devel.html" target="_blank">http://www.freeradius.org/<u></u>list/devel.html</a><br>
</blockquote></div><br>