Openvasmd not starting after update


We recently updated our Greenbone/OpenVAS to the following RPMs on CentOS 7:

It was at openvas-9.0.1. After the update, we’re unable to get both openvasmd to run or gsad.

openvas-check-setup --v9 reports:

Step 1: Checking OpenVAS Scanner …
OK: OpenVAS Scanner is present in version 5.1.3.
OK: redis-server is present in version v=3.0.7.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /var/run/redis/redis.sock
OK: redis-server is running and listening on socket: /var/run/redis/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /var/lib/openvas/plugins contains 50979 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see
OK: The NVT cache in /var/cache/openvas contains 67180 files for 50979 NVTs.
Step 2: Checking OpenVAS Manager …
OK: OpenVAS Manager is present in version 7.0.3.
OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 50475 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration …
WARNING: Your password policy is empty.
SUGGEST: Edit the /etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) …
ERROR: No Greenbone Security Assistant (gsad) found.
FIX: Please install Greenbone Security Assistant.

ERROR: Your OpenVAS-9 installation is not yet complete!

GreenBone Security Assistant is installed.

When attempting to start openvas-manager, the openvasmd.log file shows:

md main:MESSAGE:2019-04-08 15h45.46 utc:12558: OpenVAS Manager version 7.0.3 (DB revision 184)
base gpgme:MESSAGE:2019-04-08 15h45.46 utc:12559: Setting GnuPG dir to ‘/var/lib/openvas/openvasmd/gnupg’
base gpgme:MESSAGE:2019-04-08 15h45.46 utc:12559: Using OpenPGP engine version ‘2.0.22’
lib serv:WARNING:2019-04-08 15h45.46 utc:12559: server_new_internal: failed to set credentials key file
lib serv:WARNING:2019-04-08 15h45.46 utc:12559: server_new_internal: cert file: /etc/pki/openvas/CA/servercert.pem
lib serv:WARNING:2019-04-08 15h45.46 utc:12559: server_new_internal: key file : /etc/pki/openvas/private/CA/serverkey.pem
md main:CRITICAL:2019-04-08 15h45.46 utc:12559: main: client server initialisation failed

When attempting to start gsad we see:

gsad: error while loading shared libraries: cannot open shared object file: No such file or directory

Any ideas on what we’re missing here?

Thanks in advance.

I would say libgcrypt is missing. Seems the package dependencies are not correct.

libgcrypt is installed:

rpm -q libgcrypt

We’re also seeing this same libgcrypt error when trying to run omp, e.g.

omp: error while loading shared libraries: cannot open shared object file: No such file or directory

libgcrypt20 doesn’t appear to be an available CentOS 7 package. How are others getting this to work? I do see a /opt/atomic/atomic-libgcrypt folder that does include a, however it doesn’t appear to that omp are using it.

Looks like there are some issues with the packages you’re using so you probably need to contact the maintainer of these packages and/or subscribe to that issue to see if there are any fixes provided/mentioned there.

I was able to get omp working by changing the LD_LIBRARY_PATH variable for the user account running it with:

export LD_LIBRARY_PATH=/opt/atomic/atomic-libgcrypt/root/usr/lib64:/opt/atomic/atomic-libgpg-error/root/usr/lib64

GSAD also needed to be updated, it wasn’t added as a dependency (package is greenbone-security-assistant) which is now at v 7.0.3

Now we have all services up and running, however the underlying databse appears to have been corrupted by the upgrade. Within GSA we’re able to view targets for example, however when loading a report we get a Internal error: get_report:14231 (GSA 7.0.3) error. In /var/log/openvas/openvasmd we see:

md manage:WARNING:2019-04-08 18h12.20 UTC:19690: sql_prepare_internal: sqlite3_prepare failed: near “WITH”: syntax error
md manage:WARNING:2019-04-08 18h12.20 UTC:19690: init_iterator: sql_prepare failed
md manage:WARNING:2019-04-08 18h12.20 UTC:19690: sql_close: attempt to close db with open statement(s)

Any further ideas here? I’m surpised a 9.0.1 to 9.0.3 update would cause so many issues.

I’m still suggesting to raise your concerns / issues to the package maintainer at as all issues seems to be related to the provided packages and not to OpenVAS / GVM itself.

Especially this should have already fixes some time ago by the package maintainer:

by providing a newer SQlite3 version >= 3.8.3 but is now hitting the packages again.

Have a look here…

Do you got the same Problem?

Its a very similar problem. We’ve gotten around the libgcrypt issue. Currently GSA isn’t working due to the sqlite3 >= 3.8.3 dependency. We have the atomic-sqlite package installed in /opt/atomic, but GSA doesn’t appear to use.

I had to downgrade back to …

This is after the upgrade to 10 made a complete mess …

Thankfully, … backups.


Please note the following from

Disclaimer: Greenbone isn’t responsible for any packages shipped by Linux distributions. Therefore we also aren’t responsible for your CentOS packages. I guess you should report problems at

Depending where you get the packages from it is strongly suggested to report such upgrading issues to the package maintainer.

@cfi … ACK …

However, in the days since my habit of auto-updating made a mess of my scanner, I’ve tried to build openvas on a Debian Stretch and it seemed to be much harder than it should be. (Maybe because it’s been so long since I’ve compiled a large project from source.) Is there a binary distribution that you would recommend? (Even if it runs on Debian, which as a Red Hatter, I try to avoid. :smiley: )


Besides the GCE there is no official supported binary distribution.

Most uncoordinated integrations does have some serious security issues (running all parts as root) or functional limitations. So you need to go the hard way on doing it on your own.

1 Like