greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.257 UTC [83] LOG: starting PostgreSQL 13.11 (Debian 13.11-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.258 UTC [83] LOG: listening on IPv4 address "127.0.0.1", port 5432
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.258 UTC [83] LOG: could not bind IPv6 address "::1": Cannot assign requested address
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.258 UTC [83] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.267 UTC [83] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.274 UTC [84] LOG: database system was shut down at 2023-07-06 07:19:06 UTC
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.281 UTC [83] LOG: database system is ready to accept connections
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.978 UTC [94] gvmd@gvmd ERROR: relation "public.meta" does not exist at character 19
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:06.978 UTC [94] gvmd@gvmd STATEMENT: SELECT value FROM public.meta WHERE name = 'database_version';
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:08.207 UTC [95] gvmd@gvmd ERROR: relation "public.meta" does not exist at character 19
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:08.207 UTC [95] gvmd@gvmd STATEMENT: SELECT value FROM public.meta WHERE name = 'database_version';
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:08.262 UTC [95] gvmd@gvmd ERROR: tuple concurrently updated
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:08.262 UTC [95] gvmd@gvmd STATEMENT: CREATE OR REPLACE FUNCTION level_max_severity (lvl text, cls text)RETURNS double precision AS $$DECLARE v double precision;BEGIN CASE WHEN lower (lvl) = 'log' THEN v := 0.0; WHEN lower (lvl) = 'false positive' THEN v := -1.0; WHEN lower (lvl) = 'error' THEN v := -3.0; ELSE CASE WHEN lower (lvl) = 'high' THEN v := 10.0; WHEN lower (lvl) = 'medium' THEN v := 6.9; WHEN lower (lvl) = 'low' THEN v := 3.9; ELSE v := -98.0; END CASE; END CASE; return v;END;$$ LANGUAGE plpgsql;
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:09.064 UTC [101] gvmd@gvmd WARNING: there is already a transaction in progress
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:19:09.867 UTC [101] gvmd@gvmd WARNING: there is no transaction in progress
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:26:48.593 UTC [356] gvmd@gvmd FATAL: remaining connection slots are reserved for non-replication superuser connections
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:26:48.892 UTC [357] gvmd@gvmd FATAL: remaining connection slots are reserved for non-replication superuser connections
greenbone-community-edition-pg-gvm-1 | 2023-07-06 07:27:00.031 UTC [359] gvmd@gvmd FATAL: remaining connection slots are reserved for non-replication superuser connections
Additionally, something I did not mention before, if I ran the top command while booting up, I had a few dozens of gvmd processes, whilst now there is only one:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2209324 104 20 0 244728 178068 150144 R 56.1 2.2 3:33.78 postgres
2209321 rse0001 20 0 1814824 1.7g 7040 S 10.0 21.3 0:51.34 gvmd
There a temporary fix way to modify the docker-compose.yml file to pull from a previous version or tag rather than the image: greenbone/<service-name>:stable for each service? This would allows building of the docker containers to revert to the previous version that is functional.
You can get around the gvmd issue with versioning in the .yml file. You may see sev 10 issues in scans for each host found, complaining that openvas-scanner version is old if you set gvmd version to 22.5.1 in order to get scans to work.
FWIW with postgresql max_connections and shared_buffers increased from 100/128MB to 400/512MB, gvmd 22.5.3 fails when a scan is started due to lack of db connections.
I’ve returned to gvmd 22.5.1 and created an override for the internal sev 10s for now.
I’m just starting to learn the source code, but I see in the gvmd/src/gvmd.c file an infinite loop is started which may spawn forked gvmd processes in the serve_and_schedule function.
Although I’m not so familiar with the source code yet, it seems plausible that this loop could be receiving multiple signals (from the feed sync?) and is spawning too many processes.
Again, I’m just learning the source code here and so if anyone can point me in the right direction of what could be causing this issue please let me know!
