KALI, Scans fail at 0%, VAS 23.45.1, gvm-libs 22.41.0

Hello fellow orthopedists,

I’m trying to get Openvas working on the latest Kali build. Everything is fully updated / upgraded and I didn’t hit any struggles or errors. It took about an hour for the initial feed download on a reasonably fast virtual machine. When I start a scan task the effect is that the scanner restarts and the NVT feed is reloading… The jobs fail at 0%

I verified the log files (no errors), I re-applied the permissions to the plugins directory (no change) , I manually removed the lock file and pulled the NVT feed with all other services stopped. None of these things had any effect. Any ideas what could trigger this behavior or what I’m missing here ?

Many Thanks

Picture 1: This is how it looks when I start the scans

Picture 2: After clicking start it switches to this screen

@gamer

Could you tell me how much capacity it has? Nowadays, 4 vCPUs and 16 GB of RAM are usually the minimum requirements, and naturally an SSD drive would be expected too.

Also, please check logs for error messages.

Eero

Just from your screen shot,your scanner is still synchronizing, you are not ready to start. I would look at the log, they give you details.

Hello Gamer,

I am too suffering from the issues you describe, and have some additional details for the group to consider.

I am running Kali - OpenVAS under a ProxMox virtual machine with 16+ GB RAM, but rotational hard drives.

gvm-check-setup 25.04.0
This script is provided and maintained by Debian and Kali.
Test completeness and readiness of GVM-25.04.0
Step 1: Checking OpenVAS (Scanner)…
OK: OpenVAS Scanner is present in version 23.45.1.
OK: Notus Scanner is present in version 22.7.2.
OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.

Everything checks out with the exception of a GLIB filename issue –

(gsad:3425): GLib-CRITICAL **: 09:06:52.534: g_file_get_contents: assertion ‘filename != NULL’ failed

I can load up the GUI, and schedule some tasks. I’ll trigger a scan, and see this in /run/ospd:

┌──(root㉿openvas-arf)-[~]
└─# ls /run/ospd
7e061c6e-9671-4ed8-ac9a-d18441ab7786 feed-update.lock ospd-openvas.pid ospd-openvas.sock

Once the GUI shifts from REQUESTED to QUEUED, the /run/ospd directory vaporizes, and if you look in the logs, we see an error:

event task:MESSAGE:2026-08-24 14h00.21 utc:2391: Status of task Scan Christian Internal (5fee9e8a-fd2c-4d93-a9f8-da3a4945c6fe) has changed to Requested
event task:MESSAGE:2026-08-24 14h00.21 utc:2391: Task Scan Christian Internal (5fee9e8a-fd2c-4d93-a9f8-da3a4945c6fe) has been requested to start by admin
event task:MESSAGE:2026-08-24 14h00.49 utc:2394: Status of task Scan Christian Internal (5fee9e8a-fd2c-4d93-a9f8-da3a4945c6fe) has changed to Queued
md manage:WARNING:2026-08-24 14h00.54 utc:2394: Could not connect to Scanner at /run/ospd/ospd-openvas.sock
md manage:WARNING:2026-08-24 14h00.54 utc:2394: Connection lost with the scanner at /run/ospd/ospd-openvas.sock. Trying again in 1 second

If you look into the journal, we see:

Aug 24 09:00:52 openvas-arf ospd-openvas[874]: Traceback (most recent call last):
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/bin/ospd-openvas”, line 8, in
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: sys.exit(main())
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd_openvas/daemon.py”, line 1307, in main
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: daemon_main(‘OSPD - openvas’, OSPDopenvas, NotusParser())
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/main.py”, line 153, in main
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: daemon.run()
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/ospd.py”, line 1104, in run
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: self.start_queued_scans()
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~~~~~~~~~~~~^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/ospd.py”, line 1141, in start_queued_scans
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: scan_process.start()
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~~~~~~~^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/process.py”, line 121, in start
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: self._popen = self._Popen(self)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~^^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/context.py”, line 230, in _Popen
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: return _default_context.get_context().Process._Popen(process_obj)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/context.py”, line 306, in _Popen
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: return Popen(process_obj)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/popen_forkserver.py”, line 35, in init
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: super().init(process_obj)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/popen_fork.py”, line 20, in init
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: self._launch(process_obj)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~^^^^^^^^^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/popen_forkserver.py”, line 47, in _launch
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: reduction.dump(process_obj, buf)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/reduction.py”, line 60, in dump
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ForkingPickler(file, protocol).dump(obj)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: TypeError: cannot pickle ‘_thread.RLock’ object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing dict item ‘_fork_lock’
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing redis.connection.ConnectionPool state
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing redis.connection.ConnectionPool object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing dict item ‘connection_pool’
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing redis.client.Redis state
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing redis.client.Redis object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing dict item ‘ctx’
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing ospd_openvas.db.MainDB state
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing ospd_openvas.db.MainDB object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing dict item ‘main_db’
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing ospd_openvas.daemon.OSPDopenvas state
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing ospd_openvas.daemon.OSPDopenvas object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing tuple item 0
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing method reconstructor arguments
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing method object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing dict item 'target’
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing multiprocessing.context.Process state
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: when serializing multiprocessing.context.Process object
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: Exception ignored in atexit callback <function exit_cleanup at 0x7f235c1bf690>:
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: Traceback (most recent call last):
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/main.py”, line 69, in exit_cleanup
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: daemon.daemon_exit_cleanup()
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/ospd.py”, line 446, in daemon_exit_cleanup
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: self.scan_collection.clean_up_pickled_scan_info()
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/scan.py”, line 251, in clean_up_pickled_scan
>Aug 24 09:00:52 openvas-arf ospd-openvas[874]: if self.get_status(scan_id) == ScanStatus.QUEUED:
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3/dist-packages/ospd/scan.py”, line 352, in get_status
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: status = self.scans_table.get(scan_id, {}).get(‘status’, None)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “”, line 2, in get
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/managers.py”, line 828, in _callmethod
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: self._connect()
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/managers.py”, line 815, in _connect
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: conn = self._Client(self._token.address, authkey=self._authkey)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/connection.py”, line 552, in Client
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: c = SocketClient(address)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: File “/usr/lib/python3.14/multiprocessing/connection.py”, line 689, in SocketClient
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: s.connect(address)
Aug 24 09:00:52 openvas-arf ospd-openvas[874]: FileNotFoundError: [Errno 2] No such file or directory
Aug 24 09:00:52 openvas-arf systemd[1]: ospd-openvas.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited

As I am not a programmer, I need to yield to folks who know more. The core appears to be

TypeError: cannot pickle….

Hope this helps,

Christian

I believe this issue was fixed a few days ago. However, the fix has not been adopted in the Kali Linux native repositories.

The issue stems from a Python 3.14 compatibility bug in ospd-openvas/OSPd multiprocessing due to a change in Python 3.14/Linux, where multiprocessing now defaults to forkserver instead of fork. forkserver requires the Process target to be pickleable.

I suggest submitting a bug report to the Kali Linux Bug Tracker to remediate the package conflict.

Hello Joseph,

I have opened a ticket as suggested, and hope I did it properly. Thank you for the guidence. I will post updates here as I see them from the bug tracker.

Christian

1 Like