Bug #5622
closedCaptive Portal database handling can reset the DB while it is locked when it should wait instead
0%
Description
From a user-submitted message:
[snip]
etc/inc/captiveportal.inc:captiveportal_opendb() will reinitialize the
database(-file) if the file exists, but an error happens during query
execution. Because this can be a simple database lock (e.g. by minicron
job to prune old entries, or by a login happening at the same time),
chances are relatively that this happens sooner or later.The relevant loc is
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/captiveportal.inc#L1440
[snip]
Possible "solutions":
1) give opendb a "retry" like it already does e.g. in
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/captiveportal.inc#
if (! $DB->exec($createquery)) { captiveportal_syslog("Error during table {$cpzone} creation. Error message: {$DB->lastErrorMsg()}. Trying again."); # sleep (0.1) // Did I mention I dont know php much? if (! $DB->exec ... captiveportal_syslog("Still error during table {$cpzone} creation.... Resetting");
2) Explicitely check whether we ran into a lock and retry. This should
be done using $DB->lastErrorCode()
a) do retry x times/seconds or
b) wait to get the lock forever.Both approaches will not forever solve the issue, but drastically
lowering the chances that we have "pass-throughs" without being able to
easily spot them via the CP pages.
If the DB is reset while users are active, IPFW rules are left in place which allow some users to inadvertently retain access longer than they should. If the DB is reset the IPFW tables should be reset as well, but it looks like it should also wait a brief period for the lock to clear before resetting if it's locked and not actually corrupt.