etesync / etesync-dav

This is a CalDAV and CardDAV adapter for EteSync
https://www.etesync.com
GNU General Public License v3.0
285 stars 45 forks source link

etesync-dav does not start anymore: "RuntimeError: Failed to start server '[localhost]:37358': unknown address family" #275

Open jlkDE opened 1 year ago

jlkDE commented 1 year ago

I am using etesync-dav via a virtual environment with system-site packages enabled on openSUSE Tumbleweed and therefore keep all packages up-to-date.

After my last update and without changing the configuration etesync-dav failed to start with the following traceback:

[2022-09-11 20:47:14 +0200] [16877] [INFO] Loaded default config
[2022-09-11 20:47:14 +0200] [16877] [INFO] Loaded arguments
[2022-09-11 20:47:14 +0200] [16877] [INFO] Starting Radicale
[2022-09-11 20:47:14 +0200] [16877] [INFO] auth type is 'radicale.auth.htpasswd'
[2022-09-11 20:47:14 +0200] [16877] [INFO] storage type is 'etesync_dav.radicale.storage'
[2022-09-11 20:47:14 +0200] [16877] [INFO] rights type is 'etesync_dav.radicale.rights'
[2022-09-11 20:47:14 +0200] [16877] [INFO] web type is 'etesync_dav.radicale.web'
[2022-09-11 20:47:14 +0200] [16877] [INFO] Listening on '[127.0.0.1]:37358'
[2022-09-11 20:47:14 +0200] [16877] [CRITICAL] An exception occurred during server startup: Failed to start server '[localhost]:37358': unknown address family
Traceback (most recent call last):
  File "/home/jlkDE/.local/share/virtualenv/etesync-dav/lib/python3.8/site-packages/etesync_dav/radicale_main/server.py", line 233, in serve
    server = server_class(configuration, family, address,
  File "/home/jlkDE/.local/share/virtualenv/etesync-dav/lib/python3.8/site-packages/etesync_dav/radicale_main/server.py", line 78, in __init__
    super().__init__(address, RequestHandlerClass)
  File "/usr/lib64/python3.8/socketserver.py", line 452, in __init__
    self.server_bind()
  File "/home/jlkDE/.local/share/virtualenv/etesync-dav/lib/python3.8/site-packages/etesync_dav/radicale_main/server.py", line 85, in server_bind
    super().server_bind()
  File "/usr/lib64/python3.8/wsgiref/simple_server.py", line 50, in server_bind
    HTTPServer.server_bind(self)
  File "/usr/lib64/python3.8/http/server.py", line 138, in server_bind
    socketserver.TCPServer.server_bind(self)
  File "/usr/lib64/python3.8/socketserver.py", line 466, in server_bind
    self.socket.bind(self.server_address)
OSError: unknown address family

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/jlkDE/.local/share/virtualenv/etesync-dav/lib/python3.8/site-packages/etesync_dav/radicale_main/__init__.py", line 166, in run
    server.serve(configuration, shutdown_socket_out)
  File "/home/jlkDE/.local/share/virtualenv/etesync-dav/lib/python3.8/site-packages/etesync_dav/radicale_main/server.py", line 255, in serve
    raise RuntimeError("Failed to start server %r: %s" % (
RuntimeError: Failed to start server '[localhost]:37358': unknown address family

I tried searching for localhost inside of my configuration files without matches, afterwards I changed some hardcoded occurences of localhost inside some the etesync-dav virtual env files, but both led to nothing.

Then I tried to find out which package could have caused the error unknown address family: I was able to grep the string within the packages boltons and dnspython, but they were updated 9 and 6 months ago for me, so not recently.

Lastly I moved the etesync data dir including the configurations and tried to start a clean instance, but the error remained.

These are the packages available inside the venv: pip-list.txt

Workaround

As a workaround I started etesync-dav with the environment variable ETESYNC_LISTEN_ADDRESS=127.0.0.1 (or more specifically I added the line Environment=ETESYNC_LISTEN_ADDRESS=127.0.0.1 to my systemd service unit.

tasn commented 1 year ago

It looks like a bug with radicale. Interesting though, it looks like it's confused between ipv6 and ip4 for localhost for whatever reason (if I had to guess).

jlkDE commented 1 year ago

Ok, sounds plausible. As I have a workaround this does not bug me that much, do you think I should file an issue against radicale?