You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The boostrap test (e.g. on travis) sometimes fails. It probably is due to a fault in the test, client connection handling (drop a connection before downloading all the data), server connection handling (they drop connection before sending addresses or flushing the stream) or some combination thereof.
It's not exclusively a problem of travis, I'm moving the tests to buildbot and the same happens there. If you retry the test enough it will eventually succeed.
I'll check if the bootstrap servers that I have access to have the latest code, if that doesn't fix it maybe someone can look at it in more detail.
@g1itch In such a case, the server is supposed to send an addr command before dropping the connection. But maybe it wasn't correctly implemented or refactored to asyncore as I don't remember ever testing it.
Update: bootstrap servers don't have the latest code, but there are excessive memory usage problems with the latest code, so I'm postponing upgrades until #1598 is resolved.
So I updated the bootstrap servers and while checking them, only those that I operate appear to be online. All the others probably belonged to former users who don't run a node anymore or their IP changed. One I think belongs to Jonathan Warren but don't know about the others.
I made sure all mine ( 5 ) are up and running with the latest code. There is currently no working IPv6 boostrap, and I haven't checked the tor bootstrap (which also is run by me but it's an weak system so want to setup a different one).
I'll keep rerunning the test job to see if it improves. Maybe this (making sure mine work and have the latest code) is enough to fix it, but over longer period of time more servers run by others would be welcome, and I need to adjust the DNS records accordingly.
Activity
g1itch commentedon Jan 30, 2020
Maybe this is related:
PeterSurda commentedon Jan 31, 2020
@g1itch In such a case, the server is supposed to send an
addrcommand before dropping the connection. But maybe it wasn't correctly implemented or refactored to asyncore as I don't remember ever testing it.PeterSurda commentedon Jan 31, 2020
Update: bootstrap servers don't have the latest code, but there are excessive memory usage problems with the latest code, so I'm postponing upgrades until #1598 is resolved.
PeterSurda commentedon Feb 6, 2020
So I updated the bootstrap servers and while checking them, only those that I operate appear to be online. All the others probably belonged to former users who don't run a node anymore or their IP changed. One I think belongs to Jonathan Warren but don't know about the others.
I made sure all mine ( 5 ) are up and running with the latest code. There is currently no working IPv6 boostrap, and I haven't checked the tor bootstrap (which also is run by me but it's an weak system so want to setup a different one).
I'll keep rerunning the test job to see if it improves. Maybe this (making sure mine work and have the latest code) is enough to fix it, but over longer period of time more servers run by others would be welcome, and I need to adjust the DNS records accordingly.
PeterSurda commentedon Aug 27, 2020
Update: Today I removed non-responding servers from DNS records and updated all those servers that I control to the current v0.6.