Edit- please read the entire thread before responding, thank you!
New reports of the issue should be directed to the Kali Bug Tracker, Bug ID 9420: https://bugs.kali.org/view.php?id=9420 opened by @dadoXYZ and the rest of this thread will stay up for reference.
Hi everyone,
As we are seeing new reports about OOM (out of memory) issues and unfinished jobs we need to narrow it down to see where the issue is. If you are affected please respond to this thread with:
Operating system and version of operating system
Greenbone Community Edition version
Install Method
Is this a virtual install? yes/no
4(a). If yes, what what is your virtualization environment? (name of virtualization manager and resource allocation configuration)
Is this a container install? yes/no
5(a). if yes, please name the container source (ex. official Greenbone container from…)
Is it reliably reproducible with each run?
If you have any additional information like (for example) error codes, OpenVAS log entries, etc. please let us know (using the post formatting described here).
I realize that this is not a comprehensive set of questions but the point is to narrow it down some. We might have followup questions requesting additional information. If this exact issue (out of memory or unfinished jobs) does not affect you, please do not post in this thread. Thank you!
Hi DeeAnn,
I’m running into a persistent OOM-killer issue on Kali 2025.4.
During large scans, the scanner gradually ramps memory usage until the kernel kills it, taking Redis down with it and restarting the gvm services
Installed from official Kali packages (apt install gvm).
Repeated OOM on openvas processes, example:
oom-kill:constraint=CONSTRAINT_NONE ... task=openvas
Out of memory: Killed process ... total-vm:20GB, anon-rss:4.8GB
OOM killing Redis:
Killed process redis-server ... anon-rss:1561512kB
systemd logs showing killer events:
ospd-openvas.service: The kernel OOM killer killed some processes in this unit.
ospd-openvas.service: Failed with result 'oom-kill'.
gvmd aborts with backtraces
During the OOM event, gvmd produces repeated backtraces and aborts:
md main:MESSAGE: Received Aborted signal
...
BACKTRACE: gvmd: Serving (+0x13e5b9) [0x55cafc2f85b9]
BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x12)
BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(abort+0x22)
After gvmd aborts, it repeatedly loses connection to the scanner
md manage:WARNING: OSP get_scan: Couldn't send get_scans command to scanner
md manage:WARNING: Connection lost with the scanner at /run/ospd/ospd.sock.
md manage:WARNING: Could not connect to Scanner at /run/ospd/ospd.sock
md manage:WARNING: osp_scanner_feed_version: failed to connect
Please let me know if you have recommendations to address this problem or if you need more detailed logs.
Not sure if relevant but gvmd seems to be most current 26.12.1 similar to gvm-libs with 22.33.0 while all other versions are lacking some versions behind (e.g. for openvas-scanner version 23.32.5 is current, similar ospd-openvas with version 22.9.1).
Mixing different older and most current versions could be problematic, if this issue is only affecting Kali users maybe some one want to contact the Kali packaging team and asking to update all components to the most recent / current versions.
I have also experienced memory issues with the host_details.nasl process running on an 8GB RPi 500. Full and Fast scans will almost complete, and then crash.
All combined it looks like we have enough to report to Kali. We will need someone who is currently affected to submit the report and followup here https://bugs.kali.org/ (perhaps @dadoXYZ , @ttheweepster or someone else reading who is affected and can reproduce it). In the report if you could cross-reference Kali bug ID 9413 (which matches @cfi ‘s observation upthread) and also point a link to this thread here, it can help make it easier for them. Thank you so much!
Edit to add- updated the thread title, moved it and marking this as solved so it bumps this post closer to the top. And if this doesn’t solve the OOM issue or if the exact same issue appears across release types (Greenbone containers, etc.) we can look further.
