Hi,
i have a problem. When installing GVM 22.04 on Ubuntu 20.04 gsad doesn’t start, it stops at Active: activating.
Other services status is ok (notus-scanner, ospd-openvas and gvmd) = Active: active (running)
What is supposed to be the problem here?
If you need some information, i’ll give it.
Thank you for help.
p
The reason on the failure to start the service should be usually available at /var/log/gvm/gsad.log.
This thread may have more useful information for you.
TL;DR: Try running gsad with the option --no-redirect as a temporary quick fix.
Oops, secure memory pool already initialized
This message is normal and should not interfere with the operation of gsad.
That looks like a permission issue to me, does the gsad user have sufficient permissions to read/write the PID file?
thank you, i will check it.
Do you mean gvm user?
I’ve seen these problems thanks to the distributed systemd unit file (/lib/systemd/system/gsad.service, generated from gsad.service.in) using Type=forking rather than Type=exec and passing the --foreground flag to gsad.
For some reason, systemd loses track of the gsad process (once it’s double-forked away or something, I haven’t bothered looking in to that) and then is unable to stop it. This means that when you next try to start gsad the old one is actually still running, so it can’t bind a listener or open a new pid file, and fails hard.
My solution is to change the systemd unit to Type=exec so that systemd can actually track the process properly, and then everything works better. I haven’t been bothered submitting a PR against the upstream source (I should probably do that) but rather I just drop this override in place:
/etc/systemd/system/gsad.service.d/override.conf
[Service]
Type=exec
ExecStart=
ExecStart=/usr/sbin/gsad --listen 127.0.0.1 --port 9392 --foreground
edit: PR created
I’ve never had issues in the past with the systemd service path but this might fix it. I’ll check your PR after my vacation and likely update our docs with this change too.