using recent VM
Advanced task wizard wont create task with run immediately of date set.
Value '0' is not valid for parameter 'start_day'.
using recent VM
Works fine for me. Are you using GCE 6.0.10? Can you take a screen shot of the advanced task manager?
it’s Greenbone OS 6.0.10
I’ll try to recreate it,
happened quiet a lot yesterday, is there any log file i can access to help ?
Well that’s typical, cannot recreate issue today, which makes that difficult to prove and me look a bit of a nerd… Wonder if it’s timing related or some other issue related to environment RAM ?? … at some point i did change the VM linux version following reading a forum but that’s a bit straw clutching…
Same error here, using Greenbone OS 20.08.4.
I have a clue, based on the screenshot from last user and my experience, it’s later night now, my timezone is UTC -3, the interface is trying to schedule for tomorrow (UTC timezone).
The last user’s screenshot was also taken later night, maybe there is a timezone bug.
I also had the same issue when i select “Start immediately” it’s gives me same error message as “Value ‘0’ is not valid for parameter ‘start_day’.”
Looking at console log whenever i select task “Start immediately”, in background it picks the time as per UI “Create schedule” timing which is UTC timezone by default .
Create a scheduled task 1-2 minutes ahead of UTC timezone
Start immediately timing should not be picked from Create schedule calendar.
Thank you everyone for the reports and the analysis. We’ll try to get this fixed!
I have this same issue running Greenbone Community Edition installed via Kali native packages.
Unlike the issues mentioned above, I cannot even seem to select the “Create Schedule” option.
Same issue here on the Greenbone Trial. Did you manage to find a workaround? I rebooted the VM etc., but no luck. Any simple tricks are welcome of course
All in all, this isn’t really making a convincing argument to purchase a paid license for my company. We need to keep the show running. Lags and bugs like these stick out like a sore thumb.
This issue just went away about 24 hours later for me. I noticed that I was starting the scan around midnight. I guess since it’s so intermittent that it is some type of timestamp collision with certain combinations of date parsing.
It should go away within a few hours.
This might be already solved once the following PR has been merged:
At least it contains references to e.g. schedules, timezones and