While coding the rlm_sql_sqlite module I found that even though it fails to "connect" to the database it doesn't stop Freeradius from launching. While I understand that once it's started it may need to reconnect, would it not be a good behavior to stop execution under sql_init_socketpool() ? if (!success) { radlog(L_DBG, "rlm_sql (%s): Failed to connect to any SQL server.", inst->config->xlat_name); } Why not return -1 here within this block?
Gabriel Blanchard wrote:
While coding the rlm_sql_sqlite module I found that even though it fails to "connect" to the database it doesn't stop Freeradius from launching.
Yes. The *other* databases need this. i.e. if they aren't up when FreeRADIUS starts, it needs to start,and keep trying until they're back up. This removes startup dependencies between programs. Alan DeKok.
On 15-Jul-09, at 4:03 AM, Alan DeKok wrote:
Gabriel Blanchard wrote:
While coding the rlm_sql_sqlite module I found that even though it fails to "connect" to the database it doesn't stop Freeradius from launching.
Yes. The *other* databases need this. i.e. if they aren't up when FreeRADIUS starts, it needs to start,and keep trying until they're back up.
This removes startup dependencies between programs.
I know I'm being picky here but would it be OK if a different return code from sqlite would cause it to fail? I understand it makes sense to continue starting for other databases, but I don't think it does for something like sqlite. -G
Gabriel Blanchard wrote:
I know I'm being picky here but would it be OK if a different return code from sqlite would cause it to fail? I understand it makes sense to continue starting for other databases, but I don't think it does for something like sqlite.
It may be reasonable, yes. Since the changes should be limited only to the SQL directory, having two return codes "temporary failure", and "permanent" failure for the sub-modules may be OK. Alan DeKok.
participants (2)
-
Alan DeKok -
Gabriel Blanchard