The only way to restore access to openvasmd is either by flushing redis cache or by restarting openvasm, which will put the task status to “Stopped”.
This is a major issue as basically openvas9 is unuseable with big tasks in this environment. I must note that starting small tasks doesn’t create any issue.
Last point, this doesn’t seem related with bug described in https://community.greenbone.net/t/sqlite- error-and-tasks-stuck/199/10 as patching the current version with the patch available doesn’t fix the problem.
Did you checked that your machine had enough resources, did you turned memory over-commitment off ? I don´t think this is a GVM9 issue, more of your build, setup or machine.
This might be related to/the same as Gvm-cli connections fail under openvassd load where the same messages in the openvasmd.log are showing up. The “high load” could happen on “big tasks” as well.
The machine has a lot of ressources and is clearly not overloaded. Memory over-commitment is set to default, and according to what I can read elsewhere, changing this setting is not recommended. But I don’t really believe in this anyway, as again my system is full of RAM/Disks space.
I checked that post but unfortunately there doesn’t seem to be a fix for this available yet. Also, this problem wasn’t happening with GVM8 (same machine, same config) where I was managing big tasks without any problems.
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.