Error while syncing new calendar event
maxigaz opened this issue · comments
On vdirsyncer 0.19.1 and 0.19.0, I receive an error message if I create a new calendar event in ikhal and then run vdirsyncer sync.
error: Unknown error occurred for xandikos_calendar/9140fbad-a217-4dc2-982a-e2597344f7c8: [Errno None] Can not write request body for http://<REDACTED>/user1/calendars/9140fbad-a217-4dc2-982a-e2597344f7c8/6CWKJLONGUG29ILAGD08HZ4AXK95STOCLWOV.ics
If I delete the newly created event in ikhal or downgrade vdirsyncer to 0.18.0 and try running vdirsyncer sync again, I no longer receive the error.
- vdirsyncer version: 0.19.1 or 0.19.0
- Server software: Xandikos 0.2.8
- Python version: 3.10.10
- Operating system: Arch Linux
- Config file: config.txt
vdirsyncer -vdebugoutput: vdirsyncer-log.txt
This is very odd, looks like a network error before vdirsyncer can send the full request.
Do you have access to the server logs? Can you run it with --dump-dav-xml?
I was having issue syncing this morning. Then I realized I can't even reach my Nextcloud service provider in the browser. An hour later I saw there's a new Nextcloud release and I can access the browser again and vidrsyncer works again. Please OP can try again?
@WhyNotHugo I'm using Xandikos with uwsgi (for password-based authentication) and I'm having trouble with passing the argument --dump-dav-xml to Xandikos. Could you provide me with some pointers on how to do that?
This is the content of my /etc/uwsgi/xandikos.ini (with sensitive data removed):
[uwsgi]
http-socket = URL:PORT
umask = 022
master = true
cheaper = 0
processes = 1
plugins = python
route = ^/ basicauth:myrealm,USERNAME:PASSWORD
module = xandikos.wsgi:app
env = XANDIKOSPATH=/home/USERNAME/dav
env = CURRENT_USER_PRINCIPAL=/user1/
env = AUTOCREATE=principal
uid = USERNAME
Currently, uwsgi is run through a systemd service file provided by the Arch Linux package uwsgi, which is enabled with systemctl enable uwsgi@xandikos.service.
I see the same issue with 0.19.1. With Wireshark, what I notice is that uWsgi/xandikos is closing the connection right after PROPFIND and PUT throws an error. It seems to me that aiohttp session might need to be opened after every request. Not sure why uWsgi is closing the session right after sending the response.
Syncing tasks_calendar/calendar
debug: ====================
debug: PROPFIND http://192.168.1.117:8080/dav/user1/calendars/calendar/
debug: {'User-Agent': 'vdirsyncer/0.19.1', 'Content-Type': 'application/xml; charset=UTF-8', 'Depth': '1'}
debug: b'<?xml version="1.0" encoding="utf-8" ?>\n <propfind xmlns="DAV:">\n <prop>\n <resourcetype/>\n <getcontenttype/>\n <getetag/>\n </prop>\n </propfind>\n '
debug: Sending request...
debug: 207
debug: <CIMultiDictProxy('Content-Type': 'text/xml; charset="utf-8"', 'Content-Length': '465')>
debug: <StreamReader 465 bytes eof>
debug: Already normalized: '/dav/user1/calendars/calendar/'
debug: Skipping '/dav/user1/calendars/calendar/', is collection.
Copying (uploading) item HM0EFH6MBHY76Y6E2N8S5AQ62KFSW9SH68OP to tasks_remote/calendar
debug: Normalized URL from 'HM0EFH6MBHY76Y6E2N8S5AQ62KFSW9SH68OP.ics' to '/dav/user1/calendars/calendar/HM0EFH6MBHY76Y6E2N8S5AQ62KFSW9SH68OP.ics'
debug: ====================
debug: PUT http://192.168.1.117:8080/dav/user1/calendars/calendar/HM0EFH6MBHY76Y6E2N8S5AQ62KFSW9SH68OP.ics
debug: {'User-Agent': 'vdirsyncer/0.19.1', 'Content-Type': 'text/calendar', 'If-None-Match': '*'}
debug: b'BEGIN:VCALENDAR\r\nVERSION:2.0\r\nPRODID:-//PIMUTILS.ORG//NONSGML khal / icalendar //EN\r\nBEGIN:VEVENT\r\nSUMMARY:16:30 Test event from Khal\r\nDTSTART;VALUE=DATE:20230718\r\nDTEND;VALUE=DATE:20230719\r\nDTSTAMP:20230717T172436Z\r\nUID:HM0EFH6MBHY76Y6E2N8S5AQ62KFSW9SH68OP\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n'
debug: Sending request...
error: Unknown error occurred for tasks_calendar/calendar: [Errno None] Can not write request body for http://192.168.1.117:8080/dav/user1/calendars/calendar/HM0EFH6MBHY76Y6E2N8S5AQ62KFSW9SH68OP.ics
error: Use `-vdebug` to see the full traceback.
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/cli/utils.py", line 70, in handle_cli_error
debug: raise e
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/sync/__init__.py", line 158, in sync
debug: await action.run(a_info, b_info, conflict_resolution, partial_sync)
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/sync/__init__.py", line 181, in run
debug: await self._run_impl(a, b)
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/sync/__init__.py", line 210, in _run_impl
debug: href, etag = await self.dest.storage.upload(self.item)
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/storage/base.py", line 22, in inner
debug: return await f(self, *args, **kwargs)
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/storage/base.py", line 22, in inner
debug: return await f(self, *args, **kwargs)
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/storage/dav.py", line 601, in upload
debug: rv = await self._put(href, item, None)
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/storage/dav.py", line 569, in _put
debug: response = await self.session.request(
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/storage/dav.py", line 416, in request
debug: return await http.request(method, url, session=session, **more)
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/vdirsyncer/http.py", line 132, in request
debug: response = await session.request(method, url, **kwargs)
debug: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/aiohttp/client.py", line 560, in _request
debug: await resp.start(conn)
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 901, in start
debug: message, payload = await protocol.read() # type: ignore[union-attr]
debug: ^^^^^^^^^^^^^^^^^^^^^
debug: File "/usr/local/Cellar/vdirsyncer/0.19.1/libexec/lib/python3.11/site-packages/aiohttp/streams.py", line 616, in read
debug: await self._waiter
Using gunicorn instead of uwsgi solved this issue for me. Not clear why uwsgi is closing the connection after first request.
I might be wrong here, but it sounds like uwsgi's behaviour is incorrect.
This is likely worth reporting on the uwsgi side.