OpenVAS Scanner failed to load

GVM versions

gsad: 20.08.1~git-28ffce808-gsa-20.08
gvmd: 20.08.1~git-86a2dd798-gvmd-20.08
openvas-scanner: 20.8.2
gvm-libs: 20.8.2~git-c16719c2-gvm-libs-20.08


Operating system: Debian 10 Buster
Kernel: 4.19.181-1
Virtualization: Parallels Desktop 16
Installation method / source: Github 20.08 Branch from Source, using guide

Description of Issue

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 -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’m at wits end with this. Does anyone have ideas?

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.

1 Like

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…

Hi @yo_sono_io,

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.

Best regards,


Looks like crash of the scanner for such wrong / missing permissions or missing socket has been fixed with:

1 Like