Gvmd 26.31.1 aborts (SIGABRT) during SCAP sync — self-cancelled query on scap.cves existence check

Karl · June 25, 2026, 1:41am

Summary

gvmd repeatedly aborts (SIGABRT) during the initial SCAP/CVE feed sync on a fresh install. The crash coincides with gvmd itself cancelling one of its own queries (ERROR: canceling statement due to user request) against a trivial information_schema.tables existence check on scap.cves. Postgres confirms the cancellation is client-issued, not the result of any server-side timeout — all relevant timeouts are disabled. gvmd restarts (via the compose restart policy) and the sync resumes, repeating this abort/restart cycle multiple times before eventually completing.

Environment

gvmd version: 26.31.1 (Manager DB revision 279)
Deployment: Official Greenbone Community Containers, unmodified compose.yaml (as published by Greenbone — registry.community.greenbone.net/community/gvmd:stable, pg-gvm:stable)
Host: Linux x86_64, Docker Compose
Host resources: 7.85 GiB RAM, 8 GiB swap (261 MiB used), 40 GB free disk
No custom mem_limit / deploy.resources.limits.memory set on any service in the compose file
Trigger: Fresh install, first SCAP data sync (nvdcve-2.0-*.json.gz, years 1999–2025)

Reproduction Steps

Deploy the Greenbone Community Containers using the standard, unmodified compose.yaml.
Bring the stack up (docker compose up -d) and allow the initial feed sync to begin.
Observe gvmd logs during the SCAP/CVE sync phase.

Observed Behavior

gvmd aborts repeatedly, each time at a different point in the CVE year-file sync sequence (i.e., not pinned to one specific malformed file/year):

md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x1438d9) [0x55a233a6f8d9]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x7fd2f65b9df0]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(+0x9495c) [0x7fd2f660e95c]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x12) [0x7fd2f65b9cc2]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(abort+0x22) [0x7fd2f65a24ac]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x14e2d4) [0x55a233a7a2d4]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0xcbaec) [0x55a2339f7aec]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0xd3a3f) [0x55a2339ffa3f]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x934ac) [0x55a2339bf4ac]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x148586) [0x55a233a74586]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x143431) [0x55a233a6f431]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x143b11) [0x55a233a6fb11]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x14772a) [0x55a233a7372a]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(+0x29ca8) [0x7fd2f65a3ca8]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7fd2f65a3d65]
md   main:MESSAGE:2026-06-25 00h10.06 utc:16748: BACKTRACE: gvmd(+0x59a51) [0x55a233985a51]
md manage:MESSAGE:2026-06-25 00h10.06 utc:16748: Received Aborted signal

This recurs at multiple distinct timestamps across the sync window (observed at minimum 7 separate occurrences over ~2 hours), each with a new PID, consistent with a restart policy (condition: any) relaunching gvmd after each abort.

Matching pg-gvm log for the same timestamp window (00:10:06–00:10:07):

pg-gvm-1  | 2026-06-25 00:09:29.221 UTC [45440] LOG:  skipping vacuum of "cpe_nodes_match_criteria" --- lock not available
pg-gvm-1  | 2026-06-25 00:10:06.411 UTC [45513] gvmd@gvmd ERROR:  canceling statement due to user request
pg-gvm-1  | 2026-06-25 00:10:06.411 UTC [45513] gvmd@gvmd STATEMENT:  SELECT EXISTS (SELECT * FROM information_schema.tables               WHERE table_catalog = 'gvmd'               AND table_schema = 'scap'               AND table_name = 'cves') ::integer;
pg-gvm-1  | 2026-06-25 00:10:07.323 UTC [45515] gvmd@gvmd ERROR:  canceling statement due to user request
pg-gvm-1  | 2026-06-25 00:10:07.323 UTC [45515] gvmd@gvmd STATEMENT:  SELECT EXISTS (SELECT * FROM information_schema.tables               WHERE table_catalog = 'gvmd'               AND table_schema = 'scap'               AND table_name = 'cves') ::integer;
pg-gvm-1  | 2026-06-25 00:10:29.100 UTC [146] LOG:  checkpoint starting: wal

gvmd aborts at the exact moment its own existence-check query against scap.cves is cancelled. The query is trivially simple (a schema-existence check), so a server-side timeout firing on it would be very unusual — and as shown below, no such timeout is configured. This points to gvmd itself issuing the cancel (e.g., via PQcancel() against a stale or wrong connection handle, or an internal watchdog/timer reacting incorrectly to concurrent sync load) rather than Postgres independently deciding to cancel the query.

Despite the repeated aborts, the sync eventually proceeds to completion (reaching CPE/CVSS scoring), suggesting the underlying SCAP data does eventually load — but only after multiple crash/restart cycles, which is alarming for any automated or unattended deployment and adds significant time/noise to a fresh install.

Ruled-Out Causes

The following were investigated and excluded:

Cause	Check performed	Result
Host OOM-killer	`dmesg	grep -i oom`,` journalctl -k
Container/cgroup memory limit	`docker inspect` on `gvmd` and `pg-gvm`; review of compose file	No `mem_limit` or `deploy.resources.limits.memory` set anywhere
Disk exhaustion	`df -h`	40 GB free
PostgreSQL `statement_timeout`	`SHOW statement_timeout;`	`0` (disabled)
PostgreSQL `lock_timeout`	`SHOW lock_timeout;`	`0` (disabled)
PostgreSQL `idle_in_transaction_session_timeout`	`SHOW idle_in_transaction_session_timeout;`	`0` (disabled)
Connection pool exhaustion	`SHOW max_connections;` / `SELECT count(*) FROM pg_stat_activity;`	9 active connections of 100 max
Custom `gvmd.conf` timeout/auth settings	`cat /etc/gvm/gvmd.conf`	No timeout-related settings present; only `[authentication]`, `[features]` (all disabled), and `[security_intelligence_export]` retry config, none of which apply to this code path
Environment variable overrides	`env	grep -i -E "timeout

Given that all server-side and configuration-based explanations are eliminated, the cancellation appears to originate from gvmd’s own client-side sync logic rather than from PostgreSQL or the deployment environment.

Expected Behavior

gvmd should not cancel its own routine schema-check queries during SCAP sync, and should not call abort() in response to a cancelled/failed query on this code path — at minimum it should retry or log a recoverable error rather than crashing the entire process.

Additional Notes

This was initially suspected to be the known issue where missing/empty deprecatedBy arrays in CPE data caused SCAP updates to abort (referenced in the Greenbone changelog, fixed under #GEA-1388). However, the Postgres-side log shows a different mechanism: a client-cancelled query, not a data-parsing failure. This may be a distinct, unreported issue, or a new regression in the SCAP-sync code path in gvmd 26.31.1.
I’m happy to provide the full gvmd and pg-gvm logs for the entire sync window, pg_stat_activity snapshots taken during an active sync, or test further configuration changes if that would help narrow this down.