-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tasks progression frozen on gvmd / gsad side, while actually on-going or even finished on ospd / ospd-openvas side #1668
Comments
Yes, I confirm. It's a master slave setup. Thanks for clarifying. |
I can confirm this problem. Currently, no scans are possible. |
@jnicolas, I have upgraded to the latest revision, and I confirm I no longer see this bug. It may be a little too early to close this bug though, since this problem is erratic and I don't have tested it enough, but this is encouraging ! |
Hello, unfortunately I just had the same problem again with latest build. It seems to happens less frequently, though. But during the night I had 2 scans changed to Interrupted without reasons. :-( |
Hello, Bug still occuring with 21.4.3 final version. Much less frequent though, but still occuring on some tasks. Thanks |
I believe I'm facing the same issue, however I'm running the community containers. Greenbone Vulnerability Manager 22.4.2
Is there any more-detailed debugging I can enable to look at why there is a disconnect between GVMD and OSPD? |
OS:
In some circumstances (often after a short network communication failure between gvmd & scanner), gvmd freeze tasks progression and is unable to refresh status; despite the fact that ospd-openvas is up and tasks are ongoing or set as finished on openvas side. Moreover, in case we want to refresh the task status by stopping / resuming it; the following happens:
Overrall that's always the same story; gvmd is not reliably maintaining the communication with ospd and loose tracks of scans tasks too easily. It should be able to resume tasks where it left, and also to get up to date scan status from the scanner directly, even after the connection has dropped for some time. For old timers, please note this issue was ALREADY signaled under GVM 11. It was closed as being too old when GVM 20+ was released.
Expected behaviour: Gvmd shouldn't start a new scan when the connection is back, but instead resuming the ongoing / finished one (and putting the state as accordingly). And gvmd shouldn't put the resumed task as Interrupted.
Note: Syncing scan IDs between GVM and ospd-openvas would also greatly increase the debugging capability and the overrall investigations. This request was also already submitted back in GVM 11 !
The text was updated successfully, but these errors were encountered: