Please keep in mind that there can’t be a solution for every problem, especially not within such a short time-frame the linked post was created.
New major releases might introduce additional capabilities / features bringing additional load and complexity where e.g. the SQLite database is hitting its limits.
You could subscribe to the referenced issue tracker linked in the thread above to see if there are any questions of the development team: https://github.com/greenbone/gvmd/issues/347
Generally its recommended to create a new issue at one of the github issue trackers of the problematic component if you think you have found a bug within the code and not only a configuration / environmental issue.
Just an update on this; actually you can connect back to GSA after some times. You don’t need to restart / flush anything. I’ve scanned around 50 targets from different sizes and I confirm the problem happens randomely, but almost on every targets.
I also notices that the dashboards are often broken, and everytime this happens I see the sqlite3 error in my logs.
With lot´s of results, you will get much better results by using PostgreSQL SQLITE does have many locking issues, so this might be worth looking into a real database.
Thanks Lukas. Well, fact is my database is already quite large (almost 3GB large) so switching to a real database as you said couldn’t harm. I will try your suggestion. Is there any guide or howto to available to do this transition ?
Hi tatooin, I think the problem is similar to mine (Openvas with PostgresSQL Could not authenticate to manager daemon)
I have quite 700 Tasks and 20 daily scans (during the night).
In the beginning i used SQLite3 and had the connection problems with quite 300 tasks. The problem was SQLite timeout and I solved modifying the openvas source code.
Because this is not a good idea, I tried to use PostgresSQL but today I have the same problems.
I think the problem is still about timeout connection to the DB.
I create a my own (simple) interface in PHP end connect directly to openvas PostgresSQL and it works, so the problem shouldn’t be the DB.
Thanks for your answer. What version of openvas manager are you using ? Have you tried with the latest version available on git or like me with a rather old version provided by packages maintainers (in my case, ubuntu).
Would be interesting to see if latest version available on git is fixing this. I’ve installed the latest version from git on ubuntu as well and now trying to have it work. I’ll see if I get the same results there.
I think it’s a bug so hopefully it has been fixed already.
Just to keep you updated;
I have recompiled the source of the latest stable version available (GVM-9) and I confirm the problem is still there. It seems it’s a bug introduced in GVM-9, as this wasn’t happening prior upgrading to this version.
I think the problem is that the SQLite answer to OpenVas the code: SQLITE_BUSY and after 10 retries Openvas close the connection and return the error.
In sql_sqlite3.c I have noticed these possible problems:
The timeout is hardcoded
#define BUSY_TIMEOUT 1000
Openvas has a config file, maybe it could be a good choice to put this configuration in this file
Line 441 sql_sqlite3.c in the function sql_exec_internal
int sql_exec_internal (int retry, sql_stmt_t *stmt)
[…]
while (1)
{
int ret;
ret = sqlite3_step (stmt->stmt);
if (ret == SQLITE_BUSY)
{
if (retry)
{
if ((retries > 10) && (OPENVAS_SQLITE_SLEEP_MAX > 0))
openvas_usleep (MIN ((retries - 10) * 10000,
OPENVAS_SQLITE_SLEEP_MAX));
retries++;
continue;
}
if (retries++ < 10)
continue;
return -2;
}
if (retry == 0)
sqlite3_busy_timeout (task_db, BUSY_TIMEOUT);
if (ret == SQLITE_DONE)
return 0;
if (ret == SQLITE_ROW)
return 1;
g_warning ("%s: sqlite3_step failed: %s\n", FUNCTION,
sqlite3_errmsg (task_db));
return -1;
}
Tha variable “OPENVAS_SQLITE_SLEEP_MAX” is never set or, if it set, the default is 0.
checking in my code, I have this code in CMakeLists.txt (line 167 and 168):
if (NOT DEFINED OPENVAS_SQLITE_SLEEP_MAX)
set (OPENVAS_SQLITE_SLEEP_MAX 0)
This means that Openvas doesn’t retry to connect to DB, but only abort.
I have checked in the Github code, but in CMakeLists.txt I haven’t seen the OPENVAS_SQLITE_SLEEP_MAX 0
If you modify the code in sql_sqlite3.c line 435:
if ((retries > 10) && (OPENVAS_SQLITE_SLEEP_MAX > 0))
in
if ( ((retries > 10) && (OPENVAS_SQLITE_SLEEP_MAX > 0))
OR (ret == SQLITE_BUSY) )
The workaround should work (but it’s not the correct way to solve it)