OID-named results - follow up on https://community.greenbone.net/t/vulnerability-names-display-as-oids-only/362

Use this category only if you have build GVM from sources or if you use packages provided by a 3rdparty repository.

Please read About the Greenbone Source Edition (GSE) and About GVM Architecture before posting.

When posting you should provide information about your environment using the following template:

GVM versions

gsad: Greenbone Security Assistant 7.0.3
gvmd: n/a
openvas-scanner: OpenVAS Scanner 5.1.3


Operating system:
VERSION=“30 (Container Image)”
Kernel: Linux 3.10.0-1127.18.2.el7.x86_64
Installation method / source:

Hello, first I do realize we are using a very old version of OpenVAS, I am sorry for asking a question about it. Also, I do see this has been discussed before but I think our setup is a bit unique in that we spin up OpenVAS in a container. So therefore:“internal database build is still running.” - basically our container start script, the last thing is creating our own config. so the container is ‘ready’ after the feed-sync is done and we can see our custom config. therefore, it seems to me feedsync is completed by the time we are running a scan? and two: “The next scan should show names” - our setup is such that we only run one scan in a container then tear it down.
Is there something in the logs we should look for before beginning a scan to prevent it? or by x minutes it should be done assuming a fresh feed-sync?

We are working on converting to GVM20: is this an issue that has been fixed in gvm-20? I don’t believe we’ve encountered it thus far in our tests, but this is a very sporadic issue for us so it could be attributed to luck on our end. I’d just like to confirm this hasn’t been documented/seen on gvm20 instances.

With GVM 9 as far as I can remember you can track the process title of openvassd to know when the sync is finished. The feed sync consists of syncing the nasl files via rsync to your local machine and openvassd to load the meta data of the nasl files into the redis db.

With GVM 11 and therefore in 20.08 too the whole scanner architecture has changed. The daemon openvassd has been changed into an openvas application and an ospd-openvas daemon.


Thank you @bricks! Sorry for so many questions, I’m still learning about the greenbone products. So the architecture change you mentioned, if my understanding is correct this means that running the feed-sync command syncs the files and updates the db (instead of separate processes?), so there wouldn’t be opportunity for the OID-name results?
We have a similar setup for our GVM20 script. We spin up the GVM20 container, and wait until the logs say “Updating VTs in database … done”, then start the scan.