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.
