I can't reproduce this. For sure it takes a long time but it works.

What does openvas-check-setup report?

openvas-check-setup works fine, says that everything is ok.

Had the NVT for a long time. 1-2 days, and it was up and running.
But the Scanning does not work now, and taking a closer look it seems to hang on the NVT's
Smells like something might be wrong with the NVT's that causes it to hang :/

Ill do a new NVT update today and see if it was a plugin error.

with everything shutdown, I start openvas-scanner and wait for it to load all the way.

root@mexikali:~# openvassd

wait about 30 seconds...

root@mexikali:~# lsof -itcp:9391
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openvassd 29698 root 4u IPv4 368130 0t0 TCP *:9391 (LISTEN)

In another window, I start a tcpdump.

root@mexikali:~# tcpdump -i any port 9391
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

In the first window, I try to rebuild.

root@mexikali:~# openvasmd --rebuild --verbose --progress
Rebuilding NVT cache... /

The spinner stops there and never resumes.

The tcpdump shows almost no data changing hands other a handshake and PSH 218 long. This hangs forever.

15:20:59.086164 IP localhost.49591 > localhost.9391: Flags [S], seq 1557381704, win 43690, options [mss 65495,sackOK,TS val 331588206 ecr 0,nop,wscale 10], length 0
15:20:59.086173 IP localhost.9391 > localhost.49591: Flags [S.], seq 244454702, ack 1557381705, win 43690, options [mss 65495,sackOK,TS val 331588206 ecr 331588206,nop,wscale 10], length 0
15:20:59.086181 IP localhost.49591 > localhost.9391: Flags [.], ack 1, win 43, options [nop,nop,TS val 331588206 ecr 331588206], length 0
15:20:59.086288 IP localhost.49591 > localhost.9391: Flags [P.], seq 1:219, ack 1, win 43, options [nop,nop,TS val 331588206 ecr 331588206], length 218
15:20:59.086293 IP localhost.9391 > localhost.49591: Flags [.], ack 219, win 44, options [nop,nop,TS val 331588206 ecr 331588206], length 0

I would expect that lsof would show an ESTABLILSHED connection from both sides at this point, but I only see one side.
In a third window, I get this.

root@mexikali:~# lsof -itcp:9390,9391
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
openvassd 29698 root 4u IPv4 368130 0t0 TCP *:9391 (LISTEN)
openvasmd 29701 root 7u IPv4 368697 0t0 TCP localhost:49591->localhost:9391 (ESTABLISHED)

Is there any more info I can provide?

Confirming this bug. I am able to reproduce it each time I rebuild the NVT cache.

not to pile on, but confirming this as well

Getting this too. If anyone has a workaround please post. Scans are dead now.

+1

I dont know if this is related:
http://lists.wald.intevation.org/pipermail/openvas-discuss/2015-July/008228.html

rebuild hangs for me at this point every time:

rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7fc35af01d40}, NULL, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc35bfa1b50) = 8137
wait4(8137, ^Cstrace: Process 8136 detached
<detached ...>

I cannot determine why yet...

+1 fresh install of kali and openvas packages. Worked fine for a week but now I can't run any scans.

openvasmd --rebuild --listen 127.0.0.1 --progress --verbose

just hangs at Rebuilding NVT cache... /

I did get "Updating NVT cache" in the openvasmd.log when I specified listening on 127.0.0.1 but other than that I'm stuck for ideas on what to do next.

still the same with even a very fresh installation of OpenVAS!
is this could be a sign of starting to have a commercial version?!

I didn't reproduce this issue.
I update all packages for openvas 8 (libraries, scanner, manager, etc). There are changes on NVT cache update.
Please upgrade your system and let us know if you still have the problem.

I can confirm that this issue exists and offer a workaround/fix. The issue ONLY happens on fresh installs. (i.e. when fresh SSL keys are generated in <openvas_root>/CA/*) and appears to occur because the script tries to update the NVD cache before openvas-scanner is configured with the (newly created) TLS key...

For me the fix was to add the following line on line 29 of the file /usr/bin/openvas-setup (before running it):

openvasmd --modify-scanner 08b69003-5fc2-4037-a479-93b440211c73 --scanner-port 9391 --scanner-ca-pub /var/lib/openvas/CA/cacert.pem --scanner-key-pub /var/lib/openvas/CA/servercert.pem --scanner-key-priv /var/lib/openvas/private/CA/serverkey.pem

(See attached diff file)

This command updates the SSL keys used by the openvas-scanner after which the NVD cache update should complete. (This command can also be run manually on systems that have already been setup. After that the NVD cache should be updated manually with - 'openvasmd --update && openvasmd --rebuild'. )

I'm currently having this issue as well. Check-Setup advised me to delete and rebuild, but it just hangs. I just let it "rebuild" from Friday afternoon and it's not complete Monday morning. The only way I can fix this, is to totally reinstall Kali. Adding the line to Openvas-Setup per quant0 did not resolve this.

Prior to a fresh install, I also tried to start from scratch by performing the following, and it would hang while rebuilding at the initial setup like before.

apt-get purge openvas openvas-* ;
rm -fr /var/cache/openvas;
rm -fr /var/log/openvas;
rm -fr /var/lib/openvas;
apt-get autoremove;
apt-get install alien nsis rpm;
apt-get install openvas;

I can confirm what Muhaski reports. Same here. This is what I see on the console:

\md main: DEBUG:4363:2016-09-04 11h27.55 utc: sql_open: db open, max retry sleep time is 0
/md main: DEBUG:4363:2016-09-04 11h27.55 utc: sql_open: db open, max retry sleep time is 0
\md otp-Message: Scanner loading: 49100 / 49127 nvts.

/md main: DEBUG:4393:2016-09-04 11h28.06 utc: sql_open: db open, max retry sleep time is 0
\md main: DEBUG:4393:2016-09-04 11h28.07 utc: sql_open: db open, max retry sleep time is 0

I had the same problem with openvas (not on kali but ubuntu).
I followed the same steps as Muhaski without success (so no difference).
But I had success (yay!) after I did this:
<pre>

backup tasks.db to a safe location (mine was in /var/lib/openvas/mgr/tasks.db)

apt-get purge openvas openvas-* ;
rm -fr /var/cache/openvas;
rm -fr /var/log/openvas;
rm -fr /var/lib/openvas;
apt-get purge redis

REBOOT

apt-get install openvas
</pre>

I think the only thing I did different the 2nd time was the purging of the redis database and the reboot. Perhaps just purging redis is enough. If it doesn't help, let me know, perhaps I forgot another step I did differently and I could check...

Oh yeah, to restore tasks.db: stop openvas, put the file back, then start it again. I then got a 503 error when I started a new scan in greenbone security assistant. I followed this guide to fix it: http://plugins.openvas.org/ova_503.txt

Hopefully it helps someone.

I performed the same steps as syzop, and the setup completed this time. I believe my autoremove command previously removed redis, but I never performed a reboot.

It works. Reinstalling Redis was key.

I had this issue on a Raspberry Pi running the Kali image.

We noticed when we attempted to run:

omp --xml='<start_task task_id="3a53b4a8-80f7-4669-ab70-0aef5fb503f7"/>'

That the task would never fire off. We checked in the browser and attempted to start a task, and create a new task, and new target, and even re-run a pre-existing task, but the task would never start.

After running:

'apt-get purge redis-server'
'apt-get purge openvas'
'apt-get install openvas'

the issue was corrected. Redis appeared to be the issue, I could tell by watching the "Rebuilding NVT Cache" hang, and quit processing, but it kept calling redis over and over every now and then, and do nothing. I checked redis logs but nothing is logged there, except for:

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

Server started, Redis version 3.2.6

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

There are some possibilities why my redis database may have become corrupted...

I am using a mSD card and the filesystem is ext4.

As this is a Pi v3, we have tested unexpected shutdown by disconnecting the power.

The error in the redis logs might indicate redis could be prone to "Background save may fail" condition because of low memory, which this Piv3 has 1 GB of memory, while OpenVas recommends 4 GB.

Reproduced the error by simply initiating a scan on my target subnet with default settings. Openvas crashed after exceeding memory.
Found redis database corrupted, and resolved quickly using above process.
Resolved issue further and executed a scan by doing:

/etc/openvas# nano openvassd.conf
max_hosts=1
max_checks=3

Due to the age of the OS (Kali Moto [v1], Kali Safi [v2], Kali Rolling 2016.x), these legacy versions are no longer supported.
We will be closing this ticket due to inactivity.

Please could you see if you are able to replicate this issue with the latest version of Kali Linux - https://www.kali.org/downloads/)?

If you are still facing the same problem, feel free to re-open the ticket. If you choose to do this, could you provide more information to the issue you are facing,and also give information about your setup?
For more information, please read: https://kali.training/topic/filing-a-good-bug-report/