March 26, 2020, 1:29pm
gsa: Greenbone Security Assistant 9.0
gvm: Greenbone Vulnerability Manager 9.0.0 / Manager DB revision 221
openvas-scanner: OpenVAS 7.0.0
gvm-libs: 11.0.0 Environment
Operating system: Ubuntu
Kernel: 4.15.0-91-generic x86_64
Installation method / source: instructions from https://sadsloth.net/post/install-gvm11-src_part1/, github source tar files.
I have a fresh install, all components are up and running. I can successfully do scans.
When at rest, just freshly booted the gvmd is stuck at 100% CPU, even after loading the NVT’s ext. The only thing i’ve discovered which is off is that there are not CVE’s and CPE’s in GSA.
The feeds download fine, and gvmd imports them with no errors or warnings.
What i’ve done to try to solve this:
Flush redis cache and db
Re-Created postgresql DB
Dropped the scap-data, cert-data and plugins folder
I’m totally lost, could it be something in the feed? What else?
It’s not clear. You said there is no CVE / CPE (SCAP feed not updated ?) but at the same time you said gvm import them without problems.
First time you run gvmd it needs to create the database, which takes some times, hence the 100% CPU. Perhaps you just need to wait.
Before doing anything, make sure the three feeds are properly downloaded and installed, via the “Feeds status” in GSA.
March 26, 2020, 3:01pm
Ok, perhaps I need to clarify it a bit more.
Under non-priveledged user, I run:
These complete with success, and drop their data into the correct folders.
Then I start
ospd-openvas' and gvmd`. Now it’s expected the CPU goes to 100% because al VT’s are being processed. When this is done, accoring to the log, the CPU should dive down. This doesn’t happen, even after several hours.
This is the gvmd log:
md main:MESSAGE:2020-03-26 14h45.59 utc:3197: Greenbone Vulnerability Manager version 9.0.0 (DB revision 221)
md manage:WARNING:2020-03-26 14h45.59 utc:3206: database must be initialised from scanner
md manage:MESSAGE:2020-03-26 14h45.59 utc:3206: No SCAP database found
md manage:MESSAGE:2020-03-26 14h45.59 utc:3206: No CERT database found
util gpgme:MESSAGE:2020-03-26 14h46.00 utc:3206: Setting GnuPG dir to '/opt/gvm/var/lib/gvm/gvmd/gnupg'
util gpgme:MESSAGE:2020-03-26 14h46.00 utc:3206: Using OpenPGP engine version '2.2.4'
md manage: INFO:2020-03-26 14h46.00 utc:3235: sync_scap: Initializing SCAP database
md manage: INFO:2020-03-26 14h46.00 utc:3237: Initializing CERT database
md manage: INFO:2020-03-26 14h46.00 utc:3237: sync_cert: Updating data from feed
md manage: INFO:2020-03-26 14h46.00 utc:3237: update_dfn_xml: dfn-cert-2017.xml
md manage: INFO:2020-03-26 14h46.00 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2017.xml
md manage: INFO:2020-03-26 14h46.00 utc:3235: sync_scap: Updating data from feed
md manage: INFO:2020-03-26 14h46.00 utc:3235: Updating CPEs
md manage: INFO:2020-03-26 14h46.03 utc:3237: update_dfn_xml: dfn-cert-2011.xml
md manage: INFO:2020-03-26 14h46.03 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2011.xml
md manage: INFO:2020-03-26 14h46.05 utc:3237: update_dfn_xml: dfn-cert-2013.xml
md manage: INFO:2020-03-26 14h46.05 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2013.xml
md manage: INFO:2020-03-26 14h46.09 utc:3237: update_dfn_xml: dfn-cert-2015.xml
md manage: INFO:2020-03-26 14h46.09 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2015.xml
md manage: INFO:2020-03-26 14h46.14 utc:3237: update_dfn_xml: dfn-cert-2018.xml
md manage: INFO:2020-03-26 14h46.14 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2018.xml
md manage: INFO:2020-03-26 14h46.20 utc:3237: update_dfn_xml: dfn-cert-2014.xml
md manage: INFO:2020-03-26 14h46.20 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2014.xml
md manage: INFO:2020-03-26 14h46.23 utc:3237: update_dfn_xml: dfn-cert-2019.xml
md manage: INFO:2020-03-26 14h46.23 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2019.xml
md manage: INFO:2020-03-26 14h46.30 utc:3237: update_dfn_xml: dfn-cert-2008.xml
md manage: INFO:2020-03-26 14h46.30 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2008.xml
md manage: INFO:2020-03-26 14h46.30 utc:3237: update_dfn_xml: dfn-cert-2009.xml
md manage: INFO:2020-03-26 14h46.30 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2009.xml
md manage: INFO:2020-03-26 14h46.32 utc:3237: update_dfn_xml: dfn-cert-2016.xml
md manage: INFO:2020-03-26 14h46.32 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2016.xml
md manage: INFO:2020-03-26 14h46.37 utc:3237: update_dfn_xml: dfn-cert-2020.xml
md manage: INFO:2020-03-26 14h46.37 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2020.xml
md manage: INFO:2020-03-26 14h46.39 utc:3237: update_dfn_xml: dfn-cert-2010.xml
md manage: INFO:2020-03-26 14h46.39 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2010.xml
md manage: INFO:2020-03-26 14h46.42 utc:3237: update_dfn_xml: dfn-cert-2012.xml
md manage: INFO:2020-03-26 14h46.42 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2012.xml
md manage: INFO:2020-03-26 14h46.46 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K18.xml
md manage: INFO:2020-03-26 14h46.49 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K19.xml
md manage: INFO:2020-03-26 14h46.52 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K17.xml
md manage: INFO:2020-03-26 14h46.58 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K16.xml
md manage: INFO:2020-03-26 14h47.03 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K20.xml
md manage: INFO:2020-03-26 14h47.04 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K15.xml
md manage: INFO:2020-03-26 14h47.10 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K14.xml
md manage: INFO:2020-03-26 14h47.13 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K13.xml
md manage: INFO:2020-03-26 14h47.14 utc:3237: Updating Max CVSS for DFN-CERT
md manage: INFO:2020-03-26 14h47.16 utc:3237: Updating DFN-CERT CVSS max succeeded.
md manage: INFO:2020-03-26 14h47.16 utc:3237: Updating Max CVSS for CERT-Bund
md manage: INFO:2020-03-26 14h47.17 utc:3237: Updating CERT-Bund CVSS max succeeded.
md manage: INFO:2020-03-26 14h47.17 utc:3237: sync_cert: Updating CERT info succeeded.
md manage: INFO:2020-03-26 14h49.18 utc:3404: OSP service has newer VT status (version 0) than in database (version (null), 0 VTs). Starting update ...
md manage: INFO:2020-03-26 14h49.28 utc:3404: Updating VTs in database ... 0 new VTs, 0 changed VTs
md manage: INFO:2020-03-26 14h49.38 utc:3404: Updating VTs in database ... done (0 VTs).
md manage: INFO:2020-03-26 14h50.28 utc:3479: OSP service has newer VT status (version 202003261047) than in database (version 0, 0 VTs). Starting update ...
md manage: INFO:2020-03-26 14h53.28 utc:3479: Updating VTs in database ... 58470 new VTs, 0 changed VTs
md manage: INFO:2020-03-26 14h53.38 utc:3479: Updating VTs in database ... done (58470 VTs).
In gsa, the feed status of all three is Current. Folowing the CVE’s of CPE’s link gives
CVEs 0 of 0 and
CPEs 0 of 0. While others like NVT’s hava data in gsa.
Therefore my big assumption is that the 100% gvmd stuck has something to do with the CVE/CPE import during startup of
Hope this make’s the issue more clear.
Edit: Everything from the SCAP feed is missing in GSA.
How are you running ospd-openvas / gvmd ? What options ? Please share your systemd files.
March 26, 2020, 3:11pm
Description=Job that runs the ospd-openvas daemon
ExecStart=/opt/gvm/bin/ospd-scanner/bin/python /opt/gvm/bin/ospd-scanner/bin/ospd-openvas --pid-file /opt/gvm/var/run/ospd-openvas.pid --unix-socket=/opt/gvm/var/run/ospd.sock --log-file /opt/gvm/var/log/gvm/ospd-scanner.log
Description=Job that runs the gvm daemon
March 26, 2020, 4:52pm
Have you tried to install the releases from the branches like “gvmd-9.0” and install the xml_split now recommended for the upcoming releases?
This file has been truncated.
# INSTALLATION INSTRUCTIONS FOR GREENBONE VULNERABILITY MANAGER
Please note: The reference system used by most of the developers is Debian
GNU/Linux 'Stretch' 9. The build might fail on any other system. Also, it is
necessary to install dependent development packages.
IMPORTANT NOTICE: This version changes quite a number of locations
and names compared to the previous version. It is highly recommended to
consider the section "Migrating to Version 8.0", unless you do not have
an old setup on your system.
## Prerequisites for Greenbone Vulnerability Manager
* cmake >= 3.0
* glib-2.0 >= 2.42
* gnutls >= 3.2.15
* libgvm_base, libgvm_util, libgvm_osp, libgvm_gmp >= 11.0.0
* PostgreSQL database >= 9.6
March 26, 2020, 7:52pm
Have now used the branches:
git clone -b gvm-libs-11.0 https://github.com/greenbone/gvm-libs.git
git clone -b gvmd-9.0 https://github.com/greenbone/gvmd.git
git clone -b gsa-9.0 https://github.com/greenbone/gsa.git
git clone https://github.com/greenbone/openvas-smb.git
git clone -b openvas-7.0 https://github.com/greenbone/openvas.git
git clone -b ospd-2.0 https://github.com/greenbone/ospd.git
git clone -b ospd-openvas-1.0 https://github.com/greenbone/ospd-openvas.git
Built everything with xml_split. When gsad is started, i see this process going high for a few minutes and then all CPU goes low. So the gvmd locked at 100% CPU seems to be fixed.
The result of the feeds is also changed, the CVE’s and CPE’s are now listed but now the NVT status is Current, but no NVT’s in the list.
The gvmd log gives repediately:
lib osp:WARNING:2020-03-26 19h50.06 utc:5861: osp_get_vts_version: element VTS missing.
md manage:WARNING:2020-03-26 19h50.06 utc:5861: manage_update_nvt_cache_osp: failed to get scanner_version
lib osp:WARNING:2020-03-26 19h50.16 utc:5897: osp_get_vts_version: element VTS missing.
md manage:WARNING:2020-03-26 19h50.16 utc:5897: manage_update_nvt_cache_osp: failed to get scanner_version
md manage:WARNING:2020-03-26 19h45.07 UTC:4789: OSP start_scan 26a0b7c5-3074-4af4-a455-102dd0cecfd3: VTs list is empty
March 27, 2020, 8:07am
Where’s the config of gvmd stored?
I want to reset the scanner config, I have removed it by
gvmd --delete-scanner=<uuid>, checked the psql DB and done a
redish flushall but still gvmd logs entries as:
md manage:WARNING:2020-03-27 08h05.56 utc:8419: manage_update_nvt_cache_osp: failed to connect to /opt/gvm/var/run/ospd.sock
While this was the path of my removed scanner, the default scanner is set to
So, where’s this
/opt/gvm/var/run/ospd.sock coming from while my scanner is removed?
March 30, 2020, 10:09am
After removing the virtualenv for ospd and openvas and a remove of all feed data, and a full Postgressql DB reset, I no longer have this error and all feeds gets imported.
I now have a full functional setup!