[SOLVED] Crash reporter - Captive Portal
-
…..
and the question is ... "who is locking the database on that moment?" ???As far as I known, a database (a file) exists for every unique captive portal.
The engine is "sqllite", build into PHP.
The errors come from here https://github.com/pfsense/pfsense/blob/master/src/etc/inc/captiveportal.inc#L1399A captive portal login session will execute captiveportal_read_db() and captiveportal_write_db() and ones of these, … well, just can't.
To make things even less difficult to understand : login attempts from several users can happen simultaneously. This means the file can be written out, read, and, why not, written out by another instance at about nearly the same time.
When a file is created for (over) writing, the access to that unique structure is locked, the OS is flushing out the bytes, and the file is unlocked.
All this to guarantee that no two (or more) 'programs' write to the same file at the same moment, which will (this is the easy part) create a mess ....What you see is : the file is opened (for read or for write), but 'someone else' is currently still 'writing it'.
That triggers an error.I never saw this on my pfsense setup, but your are already the third who mentions the issue.
I showed you the thread, I thought it was the load (number of users login in) on the system, but now, given your number of users, I have a doubt that that's the reason.
It's something else ..... -
Maybe the DDL command to check if the table exists is not a good ideia at this point.
On my "box", I added the code below in captiveportal.inc to check table_exists with a SELECT statement, so no lock is applied… and until now I got 40 connections without any errors.
$tableCheck = $DB->query("SELECT name FROM sqlite_master WHERE name='captiveportal'");
if ($tableCheck->fetchArray() === false)
{
if (! $DB->exec($createquery)) {...
-
Tables, database …. whatever.
If the file (which contains a 'sqllite3' database) is written out by another 'thread', it will be locked ....As an alternative, what out a simple wait for 1 millisecond 'usleep(1000)' ?
-
This is the root issue for the "Error message: database is locked. Resetting and trying again" and similar logs, we're looking into it.
https://redmine.pfsense.org/issues/5622 -
I running about 2 days without any erros ( crashes or locking logs ) with the use of busytimeout :
$DB->busyTimeout(5000);
if (! $DB->exec($createquery)) {
…"Sets a busy handler that will sleep until the database is not locked or the timeout is reached."
public bool SQLite3::busyTimeout ( int $msecs )reference: http://php.net/manual/en/sqlite3.busytimeout.php
I hope this is a good solution.
-
hi.
can you show exactly where you enter these parameters in captiveportal.inc
thanks
-
can you show exactly where you enter these parameters in captiveportal.inc
Look (Ctrl-F) for :
if (! $DB->exec($createquery)) {
;)
-
;D ;D
-
That one spot's probably adequate for the issue most are hitting, but it needs to be done in more than that spot. This should be the proper fix.
https://git.pfmechanics.com/pfsense/pfsense/commit/7c4b3b2060c291a9c166d8196d053afac97861afNext snapshot after the time of this post will have that.
-
New snapshots including that fix are out, please try and report back.
-
@cmb:
New snapshots including that fix are out, please try and report back.
On my "spot", i got about 120 simultaneous connections and it's working fine. I think it's solved, but could someone with big numbers give us more reports ?
Thanks
JC Bilhega