Endless: OSP service has different VT status

[henningkessler]

hi there,
after having problems with my initial installation I am trying to start from scratch by following the instructions from here.
Allmost everything works as expected but the feeds never finishes updating:

running:

docker compose -f ~/greenbone-community-container/docker-compose.yml  -p openvas-ce logs gvmd -f  

Shows this:

gvmd-1  | md manage:   INFO:2025-01-07 08h39.15 utc:64: update_epss_scores: EPSS scores file '/var/lib/gvm/scap-data/epss-scores-current.json' not found
gvmd-1  | md manage:   INFO:2025-01-07 08h39.15 utc:64: Updating CVSS scores and CVE counts for CPEs
gvmd-1  | md manage:   INFO:2025-01-07 08h43.56 utc:64: Updating placeholder CPEs
gvmd-1  | md manage:   INFO:2025-01-07 08h44.38 utc:64: Updating Max CVSS for DFN-CERT
gvmd-1  | md manage:   INFO:2025-01-07 08h44.47 utc:64: Updating DFN-CERT CVSS max succeeded.
gvmd-1  | md manage:   INFO:2025-01-07 08h44.47 utc:64: Updating Max CVSS for CERT-Bund
gvmd-1  | md manage:   INFO:2025-01-07 08h44.51 utc:64: Updating CERT-Bund CVSS max succeeded.
gvmd-1  | md manage:   INFO:2025-01-07 08h44.57 utc:64: update_scap_end: Updating SCAP info succeeded
gvmd-1  | md manage:   INFO:2025-01-07 08h44.58 utc:62: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 08h44.58 utc:215: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 08h49.30 utc:213: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 08h49.40 utc:325: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 08h54.46 utc:322: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 08h54.57 utc:373: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 08h59.31 utc:369: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 08h59.41 utc:386: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 09h03.53 utc:384: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 09h04.03 utc:392: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 09h10.48 utc:389: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 09h10.58 utc:404: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 09h15.28 utc:400: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 09h15.38 utc:408: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 09h20.12 utc:405: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 09h20.22 utc:457: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 09h25.02 utc:454: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 09h25.12 utc:461: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...
gvmd-1  | md manage:   INFO:2025-01-07 09h30.44 utc:459: Assigning EPSS scores to VTs
gvmd-1  | md manage:   INFO:2025-01-07 09h30.54 utc:526: OSP service has different VT status (version 202501070713) from database (version (null), 0 VTs). Starting update ...

Any ideas to solve this?

[cfi]

The following posting below mentions lack of computing resources (e.g. RAM, disc space, …) on a VM causing this, could this also apply to the host system running the containers?

Endless: OSP service has different VT status

Hi Joseph, I was testing another install using the Docker containers and noticed some suggested hardware specs. I changed my Virtualbox settings to match those (4CPU cores and 8GB memory) and this has fixed the problem! I never saw a resource error in the gvmd.log file so didn’t suspect that but glad it’s working now. Thanks again for your help.

[kennypyatt (Kenny)]

I have what I believe is the same issue attempting to run the community containers in a Kubernetes cluster. It would start the feed sync process, complete it, and then immediately restart it again. I can log into the UI and see that all the data sources are populated but I can’t run scans.

The only issue I see in the logs is this:

```
md manage: INFO:2025-10-17 15h09.52 utc:1260: Updating VTs in database ... 208671 new VTs, 0 changed VTs
md manage:WARNING:2025-10-17 15h09.56 utc:1260: update_nvts_from_osp_vts: SHA-256 hash of the VTs in the database (a26e9ccdaf3d7863da193f618f4d2fca3ad8827509f69cc93c7e2b1be2f7ac50) does not match the one from the scanner (742f201f915fb98d58195161565990299bdf81f8dc33fd457cd6da57b319404b).
md main:MESSAGE:2025-10-17 15h09.56 utc:1260: Rebuilding all NVTs because of a hash value mismatch
```
When I exec’d into the pods I was able to manually verify both the gvmd and ospd-openvas containers had access to the same exact files. I could also verify they had access to write to redis and postgres. I don’t give up easily, but so far this one has me beat.

I was able to run the docker compose version in a virtual machine (using the same images) and it worked on the first try (I gave it 16GB of RAM and 8 cores just to be sure) and I was able to run scans. I prefer to run software in the k8s cluster, but for now we are sticking with the VM version until someone has an idea of what I’m doing wrong.

I’m happy to post my config YAML if that would be helpful.

Note: I was also having issues with the OOM killer and I ended up fixing that by giving the pod 11GB of RAM and 4 CPU cores. 8GB didn’t work for me.