skip to content

After a fresh Greenbone Community Edition source build and a greenbone-feed-sync run, GSA lists no scan configs and a test scan finds nothing: what is happening, and how do you confirm it?

level: seniorimportance: should knowfreq 9%

answer

  1. download versus load
  2. two daemons, two logs
  3. scan configs depend on VTs
  4. an owner for feed objects

basics

~20 s

Downloading the feed is only half a sync: ospd-openvas and gvmd must then load it, which can take hours, and scan configs also need a Feed Import Owner set in gvmd. Confirm with both daemons' load messages.

solid answer

~40 s

A Greenbone sync has two steps: `greenbone-feed-sync` downloads the data, then the daemons load it, and until loading finishes scans are incomplete. I would check `ospd-openvas.log` for `Finished loading VTs` and `gvmd.log` for `Updating VTs in database ... done`, plus the SCAP and CERT completion lines, and look at **SecInfo > NVTs** and **Administration > Feed Status**. For the missing configs I would confirm the Full and fast XML exists under `/var/lib/gvm/data-objects/`; if it does and VTs are loaded, the usual cause is an unset **Feed Import Owner**, because `gvmd` creates feed resources only when that setting names a user. Setting it to the admin's UUID, then letting `gvmd` reload or forcing it with `gvmd --rebuild-gvmd-data=all`, brings the configs in.

code

bash · 6 lines
bash
grep -E "Loading VTs|Finished loading VTs" /var/log/gvm/ospd-openvas.log | tail -n 2
grep -E "Updating VTs in database|update_scap_end|sync_cert: Updating CERT info" /var/log/gvm/gvmd.log | tail -n 3
find /var/lib/gvm/data-objects/ -name "*daba56c8-73ec-11df-a475-002264764cea*.xml"
/usr/local/sbin/gvmd --get-users --verbose
/usr/local/sbin/gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value <admin-user-uuid>
sudo -u gvm gvmd --rebuild-gvmd-data=all

go deeper

for a junior

Recall that a Greenbone feed sync is a download followed by the daemons loading the data, and that the load can take hours.

for a middle

Explain which daemon loads which data, which log line shows each step is done, and why scan configs need VTs loaded first.

for a senior

Work the fault in order: files on disk, VTs loaded, Feed Import Owner set, forced rebuild, and treat any report taken before loading as suspect.

for a principal

Build feed loading into the operating model: sync windows away from scans, a readiness check before scheduled scans, and alerting when loading stalls.

## A sync is two steps, and only the first is the script On Greenbone Community Edition a **feed synchronization** always consists of two parts: 1. **Downloading** the changes, via `rsync` with `greenbone-feed-sync` on a source build, or by pulling the feed data images on the Community Containers; 2. **Loading** the changes into memory and a database, which the daemons do by themselves once they are running. Both steps can take from several minutes to hours, especially the first time. The docs warn that without loaded data, scans contain incomplete and erroneous results. A finished `greenbone-feed-sync` therefore proves only that files arrived on disk. ## Where each kind of data is loaded, and the log line that proves it | Data | Loaded by | Start message | Finished message | |---|---|---|---| | VTs (scanner side) | `ospd-openvas` | `Loading VTs. Scans will be [requested\|queued] until VTs are loaded.` | `Finished loading VTs. The VT cache has been updated from version X to Y.` | | VTs (manager side) | `gvmd` | `OSP service has different VT status (version X) from database (version (Y), Z VTs). Starting update ...` | `Updating VTs in database ... done (X VTs).` | | SCAP (CPE, CVE) | `gvmd` | `update_scap: Updating data from feed` | `update_scap_end: Updating SCAP info succeeded` | | CERT advisories | `gvmd` | `sync_cert: Updating data from feed` | `sync_cert: Updating CERT info succeeded.` | | Data objects | `gvmd` | — | `Scan config Full and fast (daba56c8-...) has been created by admin` | The ospd-openvas lines are in `/var/log/gvm/ospd-openvas.log`, the rest in `/var/log/gvm/gvmd.log`. In the web interface, **SecInfo > NVTs** shows whether VTs are loaded and **Administration > Feed Status** shows whether a sync is still running. ## Why scan configs in particular go missing Scan configs such as **Full and fast**, port lists and report formats arrive as **data objects** (GVMD data). Two conditions hold before `gvmd` creates the scan configs: - **The VT data is loaded in gvmd**, because a scan config references VTs; - **a Feed Import Owner is set**, because every resource needs an owner for its permissions, and `gvmd` creates feed resources only when that setting names a user. A fresh source build commonly misses the second. The guide sets it to the admin user's UUID: ```bash /usr/local/sbin/gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value `/usr/local/sbin/gvmd --get-users --verbose | grep admin | awk '{print $2}'` ``` ## A diagnosis in order 1. **Are the files there?** `find /var/lib/gvm/data-objects/ -name "*daba56c8-73ec-11df-a475-002264764cea*.xml"`. No file means the data objects were not downloaded: run `greenbone-feed-sync --type gvmd-data`. 2. **Are the VTs loaded?** Check SecInfo > NVTs and the two VT log pairs above. If the ospd-openvas line never reached "Finished loading VTs", wait or look for errors there. 3. **Is the Feed Import Owner set?** If files exist, VTs are loaded, the logs show no errors and hours have passed, set the owner as above. 4. **Force a reload** if needed: `gvmd --rebuild-gvmd-data=all` makes `gvmd` reload the data objects from disk. 5. **Only then look elsewhere.** If configs exist but a scan still returns no results, the troubleshooting page lists other product causes: an alive test the hosts do not answer, a custom scan config lacking the **Ping Host** and **Nmap (NASL wrapper)** VTs, or an unsuitable port list. ## The same fault on the Community Containers The containers follow the same two steps. The download is `docker compose pull` of the feed data images followed by `docker compose up -d` for them, which copies the data into the volumes; the running `gvmd` and `ospd-openvas` containers then load it. The log messages are identical, read with `docker compose logs` for the matching service, and an empty report taken during the first load is just as untrustworthy as on a source build. ## Habits that prevent a repeat - **Schedule feed syncs away from scans.** The troubleshooting page advises against running feed updates while scan tasks run, because loading is heavy and large scans can already push Redis into the OOM killer. - **Treat the first start as hours, not seconds.** `systemctl start` returns at once while the first load continues. - **Check, do not assume.** A report produced before loading finished should be rerun, not filed.

  • What happens to a scan started while ospd-openvas is still loading VTs?
    The ospd-openvas log says scans will be requested or queued until the VTs are loaded, so the scan waits rather than running against a partial set. Reports produced before both daemons finished loading should still be treated as suspect, because the docs warn that unloaded data gives incomplete and erroneous results.
  • Why should feed synchronizations not be scheduled while large scans are running?
    Loading feed data is heavy work for gvmd and ospd-openvas, and large scans already lean on Redis memory; the troubleshooting page lists feed updates during scans among the habits to avoid when the OOM killer stops Redis mid-scan.

saying these in an interview costs you the question

  • greenbone-feed-sync exited cleanly, so the next scan uses the new VTs.
  • No scan configs always means the rsync download failed, so rerun it.
  • Restarting gsad makes gvmd reload the feed data.
  • A scan started during VT loading fails at once with an error.
  • Scan configs appear as soon as the data-objects files exist on disk.