I’m having similar a similar issue that others have faced where I cannot launch scans from the GUI as I get error 'failed to load scan config. I have reviewed other posts and attempted the all historically listed steps.
Troubleshooting Attempts
Set the feed owner gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value 02d66dd3-5403-488d-9908-7948b0c4beb4<which is the uuid obtained from --get-users --verbose
Syncing all nvts with ospd-openvas greenbone-nvt-sync greenbone-nvt-sync -type GVMD_DATA sudo openvas --update-vt-info gvmd --modify-scanner=08b69003-5fc2-4037-a479-93b440211c73 --scanner-host=/opt/gvm/var/run/ospd.sock
Every aspect of the build has been clean, services are active. However, I get errors in ospd-openvas.log OpenVAS Scanner failed to load VTs. Command '['openvas', '--update-vt-info']' died with <Signals.SIGABRT: 6>
Curiously, the OpenVAS service only shows 4 tasks (where install guide had 6) and --update-vt-info is not listed in CGROUP:
I’ll report you my experience, just posted in another thread.
A wise user told me that “even after you have fully synced the feeds, it takes gvm some time to ingest that data. I’ve seen it take anywhere from 15minutes to an hour depending on how much CPU/Memory you are throwing at it”.
I had been trying other tricks (could share some if necessary, but I don’t think they were solving anything), but in the end I guess that only waiting solved my issue.
Appreciate the insight. I had reviewed your post saying so, and hoped that if I just left it alone that the issue would resolve itself. After giving it a day with 4 cores and 16GB of memory, the error still persists. Additionally, the error that I’m getting in ospd-openvas.log indicates that I’ve got something wrong in the config. Even though I updated the socket according to Greenbone recommendations.
Oh yes, I hadn’t seen the error in the log, I read too quickly…
It’s definitely a different case.
And I see you followed exactly the same guide I used, so I don’t think I’ll be able to help much, sorry…
check the redis configuration, that the redis instance is up and you have the right permissions to access the redis socket.
Basically, openvas -s should show the db_address which is the path to the redis socket. This must be the same you have configured in your redis.conf, and the user running ospd-openvas must have permissions on the socket (add the user to the redis group). You have to set the socket permissions in the redis.conf as well (unixsocketperm 770), or just chmod the socket after starting redis.