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.memoryset 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
gvmdlogs 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
deprecatedByarrays 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
gvmdandpg-gvmlogs for the entire sync window,pg_stat_activitysnapshots taken during an active sync, or test further configuration changes if that would help narrow this down.