Service gvmd fails to start with "sqlv: sql_exec_internal failed"

Archive Greenbone Community Edition
1

Hello all,
I am facing an issue when starting the gvmd service, after compiling the code from sources. I compiled all Greenbone components from github sources and using the latest release (v20.8.1) and my OS is RHEL 7.9 (see versions and environment details below), and postgresql version 13.

When trying to start the gvmd service, it fails with the following logs in gvmd.log:

md manage:WARNING:2021-03-05 16h37.06 utc:31759: sql_exec_internal: SQL: CREATE OR REPLACE FUNCTION hosts_contains (text, text) RETURNS boolean AS '/opt/gvm/lib/libgvm-pg-server', 'sql_hosts_contains' LANGUAGE C IMMUTABLE;
md manage:WARNING:2021-03-05 16h37.06 utc:31759: sqlv: sql_exec_internal failed
md   main:MESSAGE:2021-03-05 16h39.07 utc:31878:    Greenbone Vulnerability Manager version 20.08.1~git-cda1613-HEAD (GIT revision cda1613-HEAD) (DB revision 233)
md manage:WARNING:2021-03-05 16h39.07 utc:31879: sql_exec_internal: PQexec failed: ERROR:  could not load library "/opt/gvm/lib/libgvm-pg-server.so": /opt/gvm/lib/libgcrypt.so.20: symbol gpgrt_lock_lock, version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference
 (7)

I understand that Greenbone does not provide any guarantee that it will work on another distribution than Debian, but in my case installing on Debian is unfortunately not an option. Therefore if someone has an idea of what could be the problem, or at least an idea of something to look for, any help would be really appreciated !
I don’t know if it helps but for information, I am able to start the gsad service.

Thanks

GVM versions

gsad: (‘gsad --version’) - Greenbone Security Assistant 20.08.1~git-fc9e551-HEAD

gvmd: (‘gvmd --version’) - Greenbone Vulnerability Manager 20.08.1~git-cda1613-HEAD

openvas-scanner: (‘openvas --version’, in older GVM versions < 11: ‘openvassd --version’) OpenVAS 20.8.1

gvm-libs: gvm-libs 20.8.1~git-2712b4d-HEAD

Environment

Operating system: RHEL 7.9 (Maipo)
Kernel: (‘uname -a’) 3.10.0-1160.11.1.el7.x86_64
Installation method / source: compiled from sources (Greenbone official github repositories)

2

Is libgpg-error part of the sources you compiled ?
If no then it’s just missing (my guess).

3

Thanks for you answer. Unfortunately I am already compiling libgpg-error version 1.39 and I made sure the compiler is using this version when compiling Greenbone components, so I don’t think this is the issue.

4

Make sure you have all the libs linked and accessible.
Assuming you installed into “/usr/local”

echo "/usr/local/lib" > /etc/ld.so.conf.d/openvas.conf
ldconfig

If docker (or podman) is an option on your RHEL box, you could try using a containerized version of openvas.

immauss/openvas (docker.com)

1 Like
5

Thanks for your answer. I tried what you suggested and checked with ldd that all librairies are properly linked: all seem correct but I keep getting the same error …

For info I am compiling libgpg-error version 1.42 (latest) and libgcrypt version 1.8.7 (latest stable). I also checked that symbol gpgrt_lock_lock is defined in libgpg-error.so.0 with objdump, and it is well defined.

6

Your environment might be different then the one from the gvmd and/or postgres daemons. Therefore ensure that the dir

is in the library search path.

2 Likes
7

Hi, thanks for your answers. The folder is already in LD_LIBRARY_PATH env variable.
Actually the links to the libraries seem ok, following are the output of ldd and objdump commands:

# ldd /opt/gvm/sbin/gvmd | grep gcrypt
libgcrypt.so.20 => /opt/gvm/lib/libgcrypt.so.20 (0x00007fc5cd3b6000)

# ldd /opt/gvm/sbin/gvmd | grep gpg-e
libgpg-error.so.0 => /opt/gvm/lib/libgpg-error.so.0 (0x00007ff5fd8c7000)

And the apparently non-defined symbol seems well defined:

# objdump -TC /opt/gvm/lib/libgpg-error.so.0 | grep gpgrt_lock_lock
000000000000f370 g    DF .text  0000000000000005  GPG_ERROR_1.0 gpgrt_lock_lock
8

You need to check

as the postgres user too. The environment as the postgres user might be different. The postgres daemon is loading this binary extension not gvmd.

1 Like