OpenVAS socket.timeout with hundred of tasks to create and to start (load)

[gquittet]

Hello guys, I have a similar issue with OpenVAS than the linked one:

gvmd --version
Greenbone Vulnerability Manager 21.4.2

using

PostgreSQL 12.7 (Ubuntu 12.7-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit

On heavy load (aka creating 300 tasks to scan 300 targets), I have this output after creating ~260 tasks and targets:

gmp.get_targets(filter_string=f"{name}") \
  File "/usr/local/lib/python3.8/dist-packages/gvm/protocols/gmpv208/entities/targets.py", line 282, in get_targets
    return self._send_xml_command(cmd)
  File "/usr/local/lib/python3.8/dist-packages/gvm/protocols/base.py", line 86, in _send_xml_command
    return self.send_command(xmlcmd.to_string())
  File "/usr/local/lib/python3.8/dist-packages/gvm/protocols/base.py", line 140, in send_command
    raise e
  File "/usr/local/lib/python3.8/dist-packages/gvm/protocols/base.py", line 137, in send_command
    response = self._read()
  File "/usr/local/lib/python3.8/dist-packages/gvm/protocols/base.py", line 63, in _read
    return self._connection.read()
  File "/usr/local/lib/python3.8/dist-packages/gvm/connections.py", line 142, in read
    data = self._read()
  File "/usr/local/lib/python3.8/dist-packages/gvm/connections.py", line 105, in _read
    return self._socket.recv(BUF_SIZE)
socket.timeout: timed out

I think this issue is really the same as the referenced one, even if it's 2 years old.

---

https://github.com/greenbone/gvmd/issues/347

[gquittet]

Hello, any update here?

[bjoernricks]

You can try increasing the timeout (or even to deactivate it) by using the command line argument or the config (https://gvm-tools.readthedocs.io/en/latest/config.html).

[gquittet]

I've already increased the timeout to 600 seconds, but I think the Postgres has some issues with a lot of tasks.

[gquittet]

I found the issue.

I created one task by one target.

The huge amount of created task takes too much RAM ⇒ docker container restart

So the solution was to create one task by type of target. With this technic, we launch only 7-8 tasks that are is much more simple to handle by OpenVAS and much lighter in RAM consumption.

So we can close this issue.