using recent VM
Advanced task wizard wont create task with run immediately of date set.
error
Value '0' is not valid for parameter 'start_day'.
Works fine for me. Are you using GCE 6.0.10? Can you take a screen shot of the advanced task manager?
hello
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.
Based
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 .
Workaround :
Create a scheduled task 1-2 minutes ahead of UTC timezone
Proposed solution:
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 startDate
.