Update of feeds forever

Hi everyone, I’m new to the forum. I wanted to ask how to solve a problem with GSA Version 21.4.3 updates
I always updated with the following commands:slight_smile:
greenbone-nvt-sync
greenbone-feed-sync --type GVMD_DATA
greenbone-feed-sync --type SCAP
greenbone-feed-sync --type CERT

It happens that the feeds are updated, but if I launch the SCAP, it remains there forever starting to occupy disk space. It loops!

Thank you all

1 Like

Hi @frankz66 and welcome to the forum :slight_smile:

To help us track it down, which operating system and which version are you running?

Thanks!

1 Like

Hello and thank you for responding

I use the version ubuntu 20.4.3
The version of GSA is theVersion 21.4.3

I forgot, the ubuntu distro is virtualized on the proxmox 7 platform like LXC.

Hello,

I am facing the same issue.
GVM is running in a Docker for me.
gvmd version is 21.4.4
Docker base image is debian:10-slim

Thank you!

Hi,

I would check the logs and your performance monitoring (memory, disk space) to avoid that the process killed / restarted over and over again.

1 Like

Thank you for responding, I just wanted to say that such abnormal behavior has never happened, and this only occurs when I perform the SCAP. I feel like it’s looping!

So what is your log saying ?

1 Like

Hi Lukas, unfortunately I didn’t keep the logs because gvd was in the snapshot phase from the cluster precisely for my appropriate checks. What I can confirm, however, is that in the logs you could see the progress of the SCAP update step by line, but as written before in perpetuity saturating the system disk after about 24 hours of updating in Progress …

Without any logs, there is no way to debug or fix this. Please consider your container design.

1 Like

Ok, then I’ll try to launch a snapshot from the cluster as soon as possible and repeat the update operations to show you the logs.

Hello, here’s what was done in order: light_smile:

greenbone-nvt-sync
greenbone-feed-sync --type GVMD_DATA
greenbone-feed-sync --type SCAP
greenbone-feed-sync --type CERT

I also tried with the :slight_smile commands:
greenbone-certdata-sync greenbone-feed-sync greenbone-nvt-sync greenbone-scapdata-sync

Another clue …

gsad gmp:WARNING:2021-12-02 18h13.41 CET:451: Failed to connect to server at /run/gvm/gvmd.sock: No such file or directory

dic 03 09:35:15 openvas systemd[1]: gvmd.service: A process of this unit has been killed by the OOM killer.

dic 03 09:35:15 openvas systemd[1]: gvmd.service: Failed with result ‘oom-kill’.

dic 03 09:35:15 openvas systemd[1]: gvmd.service: Consumed 52.237s CPU time.

dic 03 09:35:15 openvas systemd[1]: gvmd.service: Scheduled restart job, restart counter is at 1.

dic 03 09:35:15 openvas systemd[1]: Stopped Greenbone Vulnerability Manager daemon (gvmd).

dic 03 09:35:15 openvas systemd[1]: gvmd.service: Consumed 52.237s CPU time.

dic 03 09:35:15 openvas systemd[1]: Starting Greenbone Vulnerability Manager daemon (gvmd)…

dic 03 09:35:15 openvas systemd[1]: gvmd.service: Can’t open PID file /run/gvm/gvmd.pid (yet?) after start: Operation not permitted

dic 03 09:35:17 openvas systemd[1]: Started Greenbone Vulnerability Manager daemon (gvmd).

You don´t give enough memory please upgrade your system. oom => Out of Memory …

1 Like

Hi, could you tell me how to do it or rather what parameters to change?

Add more RAM what is so complicated on that. Either you add physical some bigger DIMM or give more via your orchestration.

Hi, sorry but I was never misexpressed. I have increased the size of the virtual memory on the cluster’s LXC at the moment, that is, right now it has not given an error and everything is up to date! Only GVM_DATA dates back 24 days ago

I wanted to point out after some time that in the LXC configuration, you need to enable at least 4 GB of memory 2 3 processors for the VM to avoid the problems I described above. I hope this will help everyone.

1 Like

Hi @frankz66,

Yes, that does help and thank you for following up with what worked :slight_smile:

1 Like