21.4.3 - VTs list is empty


Following the update 20.8.1 → 21.4.3, Openvas generates an error at each scan : “Interrupted at 0%”
In gvmd.log
md manage:WARNING:2021-11-18 17h34.41 CET:18983: OSP start_scan d3184365-e316-4b55-a9db-377f8d855446: VTs list is empty

And indeed, on the interface, in Administration / Feed Status, all seems ok :
version 20211118T1122
Status Current

But in SecInfo / NVTs, everything is empty:
No NVTs available

The updates are done without any problem.
greenbone-nvt-sync runs without any problem and the files are downloaded and accessible by the “gvm” user

find /var/lib/openvas/plugins | wc -l

The command “openvas --update-vt-info” also passes without error and the Redis database seems to receive the data.

I don’t understand where the problem comes from. If you have any clues, I’m interested.


GVM versions

gsad: Greenbone Security Assistant 21.4.3
gvmd: Greenbone Vulnerability Manager 21.4.4
openvas-scanner: OpenVAS 21.4.3
gvm-libs: gvm-libs 21.4.3


Operating system: Debian 10
Kernel: 4.19.0-18-cloud-amd64
Installation method / source: Install from source as describe here : GVM 21.04 (stable, initial release 2021-04-16)

Hi, please try some steps:

1 Like

It looks to be an issue with a specific nasl file, which causes rsync to timeout. See the logs from the nvt sync:

          7,223 100%    5.44kB/s    0:00:01 (xfr#47321, ir-chk=2327/50357)
          4,192 100%    3.16kB/s    0:00:01 (xfr#47322, ir-chk=2326/50357)
          3,658 100%    2.75kB/s    0:00:01 (xfr#47323, ir-chk=2325/50357)
          3,922 100%    2.95kB/s    0:00:01 (xfr#47324, ir-chk=2324/50357)
          5,240 100%    3.94kB/s    0:00:01 (xfr#47325, ir-chk=2323/50357)
rsync: [receiver] read error: Connection timed out (110)
rsync error: error in socket IO (code 10) at io.c(784) [receiver=3.2.3]
rsync: connection unexpectedly closed (2567400 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(228) [generator=3.2.3]
<27>Nov 19 18:55:55 greenbone-nvt-sync: rsync failed.

Please note I have run this three times.


That typically happens if a IDS/IPS/NG-Firewall matches a signature with the NASL file and closing the connection.

1 Like