Author Topic: Fix openvas-manager exiting with error during openvas-services start  (Read 31681 times)

b4d_bl0ck

  • Sr. Member
  • ****
  • Posts: 285
    • View Profile
Hi guys, i'm posting here since i had a little issue with openvas on my virtual machine, and maybe some of you may have experienced the same. Well, not everyone and not always, and i'll explain why.
In BackBox, when we want to start all openvas services needed to interact with the web interface, we usually go through MENU -> Services -> openvas -> start, or we run sudo openvas-services in the terminal. Ok, there is a third way, you can also start all services manually, but i guess no one ever did, unless when messing openvas up :)
The first two methods are different ways to call the same /usr/bin/openvas-services which, in turn, calls all the openvas manager, scanner, administrator and gsad services (in /etc/init.d), in this order.
The issue happens during this startup procedure, but only the first time i start openvas-services, when i get:

Code: [Select]
[i] Starting OpenVAS services...

Starting OpenVAS Scanner: openvassd.
Starting OpenVAS Manager: ERROR.

So, it stops in the openvas manager starting phase. After some investigation this seems due to the DODTIME timeout in openvas-manager startup script (/etc/init.d/openvas-manager), which is set to 5 seconds by default.
This is the time the scripts waits before checking if the pidfile of openvas-manager has been correctly created, i.e. it is correctly running. If it doesn't find the pidfile or it is not valid, the starting procedure stops and exits.
We can imagine that if this timeout is too short, the pidfile will not be present when it has to be checked, and so we have the error. And this is exactly what happens.

This explains why this doesn't happen to everyone, since on fast computers the default timeout may be reasonable. On a slower pc or on a virtual machine, though, these operations may take a while, so we need to tweak the DODTIME timeout to have things working at first attempt.
Anyways some tests i did show that this issue doesn't happen on every boot. And the time needed to create the pidfile is also very variable.

If you have this issue, you can monitor when the pidfile is created in the way you prefer, but if you want you can copy/paste/run this one-line-command to get an approximative value for the timeout. Run this line and then start openvas-services from menu or cli:

Code: [Select]
(secs=0; while true; do if (ps aux | grep -v grep | grep -w "/etc/init.d/openvas-manager start" > /dev/null); then while true; do if [ -f /var/run/openvasmd.pid ]; then echo -e "\nTimeout: $secs seconds\n"; exit; fi; secs=$(($secs+1)); sleep 1; done; fi; sleep 0.1; done)

Since this is an empirical value you might want to correct it adding some more seconds, just to be sure in the case the machine is really busy. After that you can replace the value of the variable DODTIME in /etc/init.d/openvas-manager with this one. On my vm that printed 38 seconds... way far from the 5 seconds default timeout.
But as said before, this is not happening all the times to me (i got it starting fine the last 4 or 5 times), so from time to time you can check if things have speeded up, maybe with new upgrades or such.

Bye!

bool secure = check_paranoia() ? true : false;


ostendali

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 588
    • View Profile
That is great b4d_bl0ck,
finally for those who are having issues with OpenVAS the mistery is revealed.

Good one.
 ;)



b4d_bl0ck

  • Sr. Member
  • ****
  • Posts: 285
    • View Profile
Hi ostendali, thx.
I'm not sure if this is related to older issues too... anyways hope it helps someone.

bool secure = check_paranoia() ? true : false;


nXXo

  • Newbie
  • *
  • Posts: 7
    • View Profile
thx for the info,  :o



sinflooddotnet

  • Newbie
  • *
  • Posts: 40
    • View Profile
I usually check if 'openvasmd --rebuild' might help, and otherwise restart all components by hand. Fixing the real problem is much better. I hope this is the issue I had in the past. Thanks for sharing!  :)