The scanner task is no longer working and I keep getting this error:
gsm ospd-openvas[495]: corrupted size vs prev_size in fastbins
gsm sudo[7153]: pam_unix(sudo:session): session closed for user root
gsm pspd-openvas[6503]: OSPD[495] ERROR: (ospd_openvas.daemon) Task f82…00db was unexpectedly stopped or killed
I installed version 21.04.1 in May, I ran the first 3 scans and it worked okay, and then after that none of the scans I have tried have worked. The “journalctl -f” shows me that error after about 15 minutes of execution. When it was working, it took about 8 hours to run normally.
Hey, thank you for reporting this! It is probably a bug on our side.
We have released the GSM TRIAL 21.04.2 in the meantime. Since we only use the newest version as a base for bugfixes, can you please check if the problem occurs there? ⟶ https://www.greenbone.net/en/testnow/#downloadnow
If the problem persists, I can forward this issue to our developers. However bugs of this kind are very hard to reproduce, and we will need more information:
Which scan config and port list did you use?
Were any credentials configured for the task?
Which alive test was configured for the target?
How many hosts and excluded hosts did the target have?
What kind of hosts and excluded hosts were configured? IPv4, IPv6, hostnames, or mixed?
At your discretion: What were the actual targets? E.g. which operating systems? Do they have virtual hosts (vhosts)? Were there firewalls or intrusion detection systems between the GSM TRIAL and the target?
Feel free to send me a private message if you do not want to disclose any information publicly, and thank you for any information you can provide!
Martin, it happened again. I think there is some relation to the Oracle virtualbox putting the greenbone VM on “hold”.
I had installed the new version without deleting the old version of the GSM vm. I have a windows 10 system on a laptop for this install. I had 2 GB of disk space left, and then windows update used up all the remaining disk space trying to install the newest version of windows.
Oracle VirtualBox put the GSM VM on “Hold” because the system was out of space.
When I found it had done this, several days later, I was able to free up space by deleting the GSM install media and then deleting the previous GSM VM.
Oracle virtualbox was able to release the hold on the vm.
I then rebooted (from the menus) the current GSM to get it to show the correct time.
From that point forward the scans have been inconsistent, taking a really long time to even start (I click the play button today, and it sits at 0% for 24 hours before starting), and coming up with 0 logs and 0 events to report.
I am going to have to discard and reinstall the GSM VM again. I thought I would give you this update in case your engineers want to test against low disk space issues on their side.