Update from me too.
First sync this morning - the same problem - Notus and NASL synched without an issue, all the others (SCAP, CERT and gvmd) failed. But then I resynched just a few minutes later and everything came down.
guys, this morning after several attempts to run command
sudo /usr/local/bin/greenbone-feed-sync
I was able to update all the databases.
I don’t know what this is connected with, tomorrow morning there will be an update attempt via сron, we’ll see if it succeeds
Yes, it seems that the initial sync will partially work but mostly fail but subsequent syncs a minute or two after will succeed fully. Weird but its a workaround - a workaround that for sure hits unfortunately harder Greenbone’s Rsync servers as we need to do multiple syncs to do a successful sync, so I hope they find a solution for themselves.
Hi Immaus! How are you? Can you check now, please? 
3 Likes
What so the fix is to just keep trying it until it works?
First test I ran about 3PM CEST, failed.
I’m running another now.
-Scott
Still an issue.
For anyone that needs a scanner in a hurry, my container implementation has a prebuilt database, and can start without the feed-sync. Until GB gets the issue straight, I’ll be updating the image daily.
info on sync issues and how to start.
Questions,
-Scott
There is no need to switch to a third-party solution for the Docker containers. The Greenbone Community Docker Containers are completely up to date despite the rsync / feed-sync downtime issues. Users can pull the feed updates using the same method as usual.
1 Like
The issue is caused by some very strange network problems which aren’t easy to solve or even to debug. Only rsync on feed.community.greenbone.net is affected. Not the enterprise feed servers nor the container images.
3 Likes
It was reported that using the IP addresses instead of DNS might work better. Therefore you could try setting the feed-url with greenbone-feed-sync to rsync://$IPV4_OR_IPV6_ADDRESS/community.
1 Like
Dang, I literally just started learning OpenVAS yesterday, and can’t get any feeds to update. I’m really hoping that the infrastructure issue is resolved, so I can continue. I don’t want to put it in reverse. Just curious, is this the case that the community feed is free, so there is limited infra support for it? Not trying to ruffle feathers, just trying to understand how things work here. I’m extremely excited to start learning OpenVAS. There is only so much you can get from YT videos. Thanks to all those that are working on the infra issue.
Ash
Hello @bricks ,
Tried to follow your recommendation, however, the issue has remained:
nano /etc/gvm/greenbone-feed-sync.toml
---
...
feed-url="rsync://45.135.106.143/community"
...
└─$ sudo greenbone-feed-sync --type ALL
Running as root. Switching to user '_gvm' and group '_gvm'.
Trying to acquire lock on /var/lib/openvas/feed-update.lock
Acquired lock on /var/lib/openvas/feed-update.lock
⠋ Downloading Notus files from rsync://45.135.106.143/community/vulnerability-feed/22.04/vt-data/notus/ to /var/lib/notus
rsync: [Receiver] failed to connect to 45.135.106.143 (45.135.106.143): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
⠋ Downloading NASL files from rsync://45.135.106.143/community/vulnerability-feed/22.04/vt-data/nasl/ to /var/lib/openvas/plugins
rsync: [Receiver] failed to connect to 45.135.106.143 (45.135.106.143): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
Releasing lock on /var/lib/openvas/feed-update.lock
Trying to acquire lock on /var/lib/gvm/feed-update.lock
Acquired lock on /var/lib/gvm/feed-update.lock
⠋ Downloading SCAP data from rsync://45.135.106.143/community/vulnerability-feed/22.04/scap-data/ to /var/lib/gvm/scap-data
rsync: [Receiver] failed to connect to 45.135.106.143 (45.135.106.143): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
⠼ Downloading CERT-Bund data from rsync://45.135.106.143/community/vulnerability-feed/22.04/cert-data/ to /var/lib/gvm/cert-data
rsync: read error: Connection reset by peer (104)
rsync error: error in socket IO (code 10) at io.c(806)
rsync: connection unexpectedly closed (969 bytes received so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(231)
⠋ Downloading gvmd data from rsync://45.135.106.143/community/data-feed/22.04/ to /var/lib/gvm/data-objects/gvmd/22.04
rsync: [Receiver] failed to connect to 45.135.106.143 (45.135.106.143): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(139) [Receiver=3.2.7]
Releasing lock on /var/lib/gvm/feed-update.lock
I tried this last night with both IPV4 & IPV6 and did not see an improvement…
-Scott
There is a immense amount of connections from 240e:300::/24, one specific IPv6 is doing huge amount of feed syncs.
I firewalled that network, not it should work find for everyone again. If you are on that network, please complain to your ISP that one of your fellow subscriber is screwing up the service and change your ISP.
1 Like
Well … it definitely ran longer, but still failed before completing.
I’ll run another test again in the morning.