Forums : Technical Issue Help
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
OpenConnect project not updating
Apparently a code fetch from the git repository failed four months ago. Does that mean it never tries again after a single network outage?
David,
That depends... If the failure is something that can be cured by a reschedule then we retry ten times over a number of months in a staggered schedule to clear the failure.
The error seen: Address family not supported by protocol
hasn't been seen yet (at least by me...). I'll see if I can clear it up then do some research to see if it is a common enough error that it should have its own watcher.
Thanks!
David,
Rescheduled the update successfully (added 179 commits). Analysis is now at July 08, 2014 on code collected on July 08, 2014 and last commit is at July 08, 2014 - about 1 hour ago.
I will try to construct a watcher for this error and see how many I catch from the nearly 2000 failures that haven't been caught by some other watcher. I'll keep you up-to-date here.
Thanks!
Should I have been able to see that error somewhere? All I saw was 'failed'.
That error looks like you're trying to contact the git server over IPv6 but for some reason your client has fallen through a time warp into the 20th century and only has Legacy IP connectivity.
There's a few things wrong there other than the time warp thing, though.
Firstly, your resolver ought to sort getaddrinfo() results according to RFC3484 and you ought to get the Legacy IP address for 'git.infradead.org' first in the list, and not the IPv6 address.
Secondly, even if it tries IPv6 first, your client ought to be falling back to the next address in the list. It certainly shouldn't fail hard with EAFNOSUPPORT, without trying the Legacy IP address for the server.
Actually, perhaps this can happen without 'othing things wrong', if the server is temporarily unreachable by Legacy IP.
Assume the resolver does the right thing and sorts its results by anticipated reachability, and your client does the right thing and falls back to the IPv6 result when it can't connect over Legacy IP. And then the last failure you get will be the EAFNOSUPPORT one, which is presumably what gets fed back as the 'overall' error?
So a transient Legacy IP routing failure (or downtime of the server, perhaps) ends up being reported as 'Address family not supported'.
David,
You will be pleased to note that four additional projects have been updated successfully due to the new watcher you suggested.
Thanks!
David,
I am escalating this up to management to be sure they are aware of the implications.
No, the current manager's tools don't reveal that much of the inner workings of ohloh (the making of the sausages...) We have been working on getting some more info for the managers but it is difficult to balance the needs of the managers with our own needs for security of the processes. It will take additional effort to implement.
Thanks!