-
Notifications
You must be signed in to change notification settings - Fork 733
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
non fatal error: Address family for hostname not supported #682
Comments
Can you please give me all your network-related env vars. |
Are your Python versions the same? There are several bugs in 3.6, particularly earlier ones like 3.6.1 |
Negative, Python versions are not the same and your hint might make sense: Server not giving the error runs Python 3.7.0 (default, Sep 9 2018, 18:53:14) Server giving the error runs Python 3.6.5rc1 What do you need from network related env vars? should I paste my electrumx.conf file here? Could it be that there's a bug in Python 3.6.5rc1 and nothing needs to be patched to electrumx ? |
It's hard to guess. There is still a bug in address resolution in Python 3.7 that I submitted a few weeks ago: https://bugs.python.org/issue35302 |
RIght. It is in Python 3.7 as well: project-management electrumx_server[7230]: INFO:PeerManager:[electrumx-core.1209k.com:50002 SSL] [Errno -9] error while attempting to bind on address ('MY_IPv4', 0): address family for hostname not supported As I can see, the peer electrumx-core.1209k.com resolves to only AAAA (IPv6): And according to journalctl it tries to bind to my IPv4, instead of my IPv6. I have native IPv6 on the machines, on the same network interface with IPv4 as inet and inet6 of course. But it appears it's the bug in Python you linked.. or it could be. Is it getting close to your case on MAC? |
From initial digging it seams like this is triggered for peers that report a HOST that only resolves to IPv6 address, not dual-stacked ones (IPv4 and IPv6). Keeping an eye on this to further confirm but seams like this is the case. |
I catch also with peers that do not resolve to IPv6 only, and are not even dual-stacked (no IPv6 at all). This is for when a peer triggers it via PeerManager: ERROR:PeerManager:[ip120.ip-54-37-91.eu:50002 SSL] RPC error: unsupported protocol version: ['1.2', '1.4'] (-103) And it is sometimes triggered by connecting clients, but unlike PeerManager here there is no info about the client that is triggering it (like a rDNS hostname or IPv4 or IPv6 address): INFO:ElectrumX:[12577] TCP xx.xx.xx.xx:xx, 212 total |
Just got similar error:
on Debian 9 Arm |
yea I am getting it very heavily as well. I run multiple servers, on Python 3.7 I get it less often (but still get it) than on Python 3.6.x which reports it at least once every 2 minutes. This is an upstream bug in Python itself so we are waiting for that to be fixed, then we'll see how it goes in ElectrumX. |
Oh, thanks for info! Let's wait for the fix then. |
I am getting this as I am starting up my e-x server running 1.8.12:
electrumx_server[581]: ERROR:asyncio:Future exception was never retrieved
electrumx_server[581]: future: <Future finished exception=gaierror(-9, 'Address family for hostname not supported')>
electrumx_server[581]: Traceback (most recent call last):
electrumx_server[581]: File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run
electrumx_server[581]: result = self.fn(*self.args, **self.kwargs)
electrumx_server[581]: File "/usr/lib/python3.6/socket.py", line 745, in getaddrinfo
electrumx_server[581]: for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
electrumx_server[581]: socket.gaierror: [Errno -9] Address family for hostname not supported
I have in my electrumx,.conf dual stack (IPv4 and IPv6) at HOST =, and the IPv6 address is not between [ ] but it works ok as it binds to it and opens the port properly. I also report my Tor host as a v3 onion service address (unlike the legacy ones, these are much longer strings of whole ed25519 public keys base32 encoded) -- but I fail to see as these being the reason triggering this. I have the same setup on a different server where I don't catch this.
The text was updated successfully, but these errors were encountered: