My definied GVM components on Debian 11.3 Bullseye
Linux test-openvas 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux
sudo -u gvm gvmd --version
Greenbone Vulnerability Manager 21.4.5
Manager DB revision 242
Copyright (C) 2009-2021 Greenbone Networks GmbH
License: AGPL-3.0-or-later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sudo -u gvm gsad --version
Greenbone Security Assistant 21.4.4
sudo -u gvm openvas --version
OpenVAS 21.4.4
gvm-libs 21.4.4
Most new code since 2005: (C) 2021 Greenbone Networks GmbH
Nessus origin: (C) 2004 Renaud Deraison <deraison@nessus.org>
License GPLv2: GNU GPL version 2
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Hello all,
I´m trying to upgrade my GSE from 21.4.3 to 21.4.4 (21.4.5) to a non-default folder /opt/gvm/
where I´m not able to start GVMD unit, it always fails with error
Apr 22 11:51:56 test-openvas systemd[1]: Starting Greenbone Vulnerability Manager daemon (gvmd)...
Apr 22 11:51:56 test-openvas systemd[1]: gvmd.service: Can't open PID file /opt/gvm/var/run/gvmd/gvmd.pid (yet?) after start: Operation not permitted
Apr 22 11:53:26 test-openvas systemd[1]: gvmd.service: start operation timed out. Terminating.
Apr 22 11:53:26 test-openvas systemd[1]: gvmd.service: Failed with result 'timeout'.
Apr 22 11:53:26 test-openvas systemd[1]: Failed to start Greenbone Vulnerability Manager daemon (gvmd).
I´m pretty sure, that is it related to the non-default folder, and ospd-openvas and gsad services can start without error.
I´m able to use commands like sudo -u gvmd --get-scanners and so on, but I´m not able to avoid this error message and force the unit to correct start.
Deployment method:
export PKG_CONFIG_PATH=/opt/gvm/lib/pkgconfig:$PKG_CONFIG_PATH
export HOMEX=/opt/gvm &&\
export PATH=$PATH:/opt/gvm/sbin && export INSTALL_PREFIX=/opt/gvm && \
export SOURCE_DIR=$HOMEX/source && mkdir -p $SOURCE_DIR && \
export BUILD_DIR=$HOMEX/build && mkdir -p $BUILD_DIR && \
export INSTALL_DIR=$HOMEX/install && mkdir -p $INSTALL_DIR
export GVM_VERSION=21.4.5 && \
export GVM_LIBS_VERSION=21.4.4
tar -C $SOURCE_DIR -xvzf $SOURCE_DIR/gvmd-$GVMD_VERSION.tar.gz && \
mkdir -p $BUILD_DIR/gvmd && cd $BUILD_DIR/gvmd && \
cmake $SOURCE_DIR/gvmd-$GVMD_VERSION \
-DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX \
-DCMAKE_BUILD_TYPE=Release \
-DLOCALSTATEDIR=/opt/gvm/var \
-DSYSCONFDIR=/opt/gvm/etc \
-DGVM_DATA_DIR=/opt/gvm/var \
-DGVM_RUN_DIR=/opt/gvm/var/run/gvmd \
-DOPENVAS_DEFAULT_SOCKET=/opt/gvm/var/run/ospd/ospd-openvas.sock \
-DGVM_FEED_LOCK_PATH=/opt/gvm/var/lib/gvm/feed-update.lock \
-DSYSTEMD_SERVICE_DIR=/opt/gvm/lib/systemd/system \
-DDEFAULT_CONFIG_DIR=/opt/gvm/etc/ \
-DLOGROTATE_DIR=/opt/gvm/etc/logrotate.d \
-DPostgreSQL_TYPE_INCLUDE_DIR=/usr/include/postgresql/ && \
make -j$(nproc) && \
make DESTDIR=$INSTALL_DIR install && \
cp -rv $INSTALL_DIR/* / && \
rm -rf $INSTALL_DIR/*
Unit:
gvmd.service
[Unit]
Description=Greenbone Vulnerability Manager daemon (gvmd)
After=network.target networking.service postgresql.service ospd-openvas.service
Wants=postgresql.service ospd-openvas.service
Documentation=man:gvmd(8)
ConditionKernelCommandLine=!recovery
[Service]
Type=forking
User=gvm
Group=gvm
PIDFile=/opt/gvm/var/run/gvmd/gvmd.pid
WorkingDirectory=/opt/gvm
ExecStart=/opt/gvm/sbin/gvmd --osp-vt-update=/opt/gvm/var/run/ospd/ospd-openvas.sock --listen-group=gvm
Restart=always
TimeoutStopSec=10
[Install]
WantedBy=multi-user.target
The reason why is not used runtime, suggested here: https://greenbone.github.io/docs/gvm-21.04/index.html#starting-services-with-systemd
is because the non-default folder /run/
RuntimeDirectory=gsad
RuntimeDirectoryMode=277
substituted by
PIDFile=/opt/gvm/var/run/gvmd/gvmd.pid
WorkingDirectory=/opt/gvm
On the gvmd.log is just a repeating message:
md main:MESSAGE:2022-04-22 10h16.04 utc:23342: Greenbone Vulnerability Manager version 21.4.5 (DB revision 242)
md manage: INFO:2022-04-22 10h16.06 UTC:23367: OSP service has different VT status (version 202204211024) from database (version 202109091021, 76222 VTs). Starting update ...
What I´m missing?
Any idea?
@cfi - some clue?
Thansk in advance.