So NVT feed is gone again and gvmd seems to report loading NVTs then apparently stuck in a loop… Why NVT, why… Other feeds are updated and done… Need to find the root cause of this issue…
Here is the odd part about this… Removing the following files from the run directory 0 byte and nothing more the nvt update finishes and it’s good to go…
gvm-checking
gvm-create-functions
gvm-helping
gvm-migrating
gvm-serving
Not sure why all this manual intervention is required but removing these allowed the process to complete and gvmd to become operational and the NVT feed to reappear…
Thoughts?
So what I explained above works everytime. Now looking in the logs (even though everything is working) I see this repetitively:
md manage:WARNING:2020-06-21 15h12.01 utc:4712: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-scap’: No such file or directory
md manage:WARNING:2020-06-21 15h12.01 utc:4713: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-cert’: No such file or directory
md manage:WARNING:2020-06-21 15h12.11 utc:4725: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-scap’: No such file or directory
md manage:WARNING:2020-06-21 15h12.11 utc:4727: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-cert’: No such file or directory
md manage:WARNING:2020-06-21 15h12.21 utc:4740: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-scap’: No such file or directory
md manage:WARNING:2020-06-21 15h12.21 utc:4741: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-cert’: No such file or directory
md manage:WARNING:2020-06-21 15h12.31 utc:4753: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-scap’: No such file or directory
md manage:WARNING:2020-06-21 15h12.31 utc:4756: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-cert’: No such file or directory
md manage:WARNING:2020-06-21 15h12.41 utc:4765: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-scap’: No such file or directory
md manage:WARNING:2020-06-21 15h12.41 utc:4766: open_secinfo_lockfile: failed to open lock file ‘/tmp/gvm-sync-cert’: No such file or directory
Why is it looking for these files. Where is the setting for this as the path for me would be /opt/gvm/tmp
Thanks!
1 Like
Adding sleep commands into the script did the trick to me as well. Thanks for sharing this !
Yeah adding sleep commands works for me too. When there’s a whole thread of different people having the same issue, with the same resolution, kind of hard to blame NAT or the firewall for this. Unless every firewall on the planet is broken, seems to me that the common denominator here is the script. Probably just opening the next connection so fast that the mirror doesn’t have time to realize the first connection is closed. Sounds like a mirror problem, not a NAT / firewall issue. I think someone mentioned the repos are on NIST servers (which are incredibly slow). I’m more inclined to believe it’s a problem on that end than on all the users having the same problem’s end with the common denominator of this script and the NIST servers.
Yes, I completely agree with this. I have had the same problem with this script with different firewalls manufacturers. Systematically; adding the sleep command fixed the issue.
So very hard to continue blaming the firewalls / NAT for this… I wonder if the professional feeds have the same problem…
GSF is behind a different system where double connections are allowed and HTTPS port 443 as SSH are possible due to a different authentication and authorization process.
2 Likes