Dear Maintainer, * What led up to the situation? Some update since 11 March 2026 to the evening of 12 March 2026 has broken /usr/share/doc/radicale/examples/apache2-vhost.conf . I have not modified the previously working configuration for months. * What exactly did you do (or not do) that was effective (or ineffective)? Apache (mostly) works because I can connect to https://localhost/radicale and other directories I set up on Apache. However, now it throws 503 errors. Radicale works from the command line, and I can connect through 127.0.0.1:5232. Unfortunately, I cannot log in to the latter because it's expecting remote_user credentials and any other authentication scheme fails. On the Apache side, every attempt to connect to https://localhost/radicale is getting: No such file or directory: AH02454: uwsgi: attempt to connect to Unix domain socket /run/uwsgi/app/radicale/socket (radicale:0) failed I can create a Hello World uWSGI application by adding an Apache conf file referencing it. * What outcome did you expect instead? I would like to be able to access radicale as I could for the past 3.5 years with largely the same configuration. The radicale conf is largely copied-and- pasted from /usr/share/doc/radicale/examples/apache2-vhost.conf
Sorry for the spam. Further to previous suggestion, /etc/init.d/uwsgi indeed defines UWSGI_RUNDIR="/run/uwsgi" , and `systemctl list-units | grep wsgi` produces no output. So it's likely that the problem lies with another package with incorrect unit files.
Hi,
I would suggest the following changes to the package to fix this bug.
diff --git i/debian/etc/apache2/conf-available/radicale-uwsgi.conf w/debian/etc/apache2/conf-available/radicale-uwsgi.conf
index 6f658a62..93231ca7 100644
--- i/debian/etc/apache2/conf-available/radicale-uwsgi.conf
+++ w/debian/etc/apache2/conf-available/radicale-uwsgi.conf
@@ -48,8 +48,8 @@
</IfDefine>
<LocationMatch "${_RADICALE_LOCATION_MATCH}">
- ProxyPass unix:/run/uwsgi/app/${_RADICALE_APP}/socket|uwsgi://${_RADICALE_APP} retry=0
- ProxyPassReverse unix:/run/uwsgi/app/${_RADICALE_APP}/socket|uwsgi://${_RADICALE_APP}
+ ProxyPass unix:/var/run/uwsgi/${_RADICALE_APP}.socket|uwsgi://${_RADICALE_APP} retry=0
+ ProxyPassReverse unix:/var/run/uwsgi/${_RADICALE_APP}.socket|uwsgi://${_RADICALE_APP}
RequestHeader set X-Forwarded-Port "%{SERVER_PORT}s"
RequestHeader unset X-Forwarded-Proto
<If "%{HTTPS} =~ /on/">
diff --git i/debian/etc/uwsgi/apps-available/radicale.ini w/debian/etc/uwsgi/apps-available/radicale.ini
index 034acbbb..ea375e06 100644
--- i/debian/etc/uwsgi/apps-available/radicale.ini
+++ w/debian/etc/uwsgi/apps-available/radicale.ini
@@ -19,6 +19,9 @@ cheaper = 3
# use 4 threads per worker process - tune memory vs. speed here
threads = 4
+idle = 600
+die-on-idle = True
+
# ressource control
# 1. temporarily gather log info on what is normal use on your system
#memory-report = True
diff --git i/debian/radicale.README.Debian w/debian/radicale.README.Debian
index 6b1d1592..75bb904b 100644
--- i/debian/radicale.README.Debian
+++ w/debian/radicale.README.Debian
@@ -13,12 +13,22 @@ using the file /etc/radicale/config as main configuration file.
Install needed packages:
- apt install uwsgi uwsgi-plugin-python3 apache2 libapache2-mod-authnz-external
+ apt install uwsgi-core uwsgi-plugin-python3 apache2 libapache2-mod-authnz-external
Enable and activate back-end uWSGI service:
- ln -st /etc/uwsgi/apps-enabled/ ../apps-available/radicale.ini
- service uwsgi restart
+ systemctl enable uwsgi-app@radicale.service
+ systemctl edit uwsgi-app@radicale.service
+
+And add the following configuration change to classic uwsgi app setup:
+
+ [Service]
+ StateDirectory=radicale
+
+Then enable socket to communicate between apache2 and uwsgi radicale backend:
+
+ systemctl enable uwsgi-app@radicale.socket
+ systemctl start uwsgi-app@radicale.socket
Setup, enable, and activate front-end service
(details on vhost and SSL/TLS certificate setup is not covered here):
Quoting Borden (2026-03-14 03:59:48) and reporting bugs are certainly requested and appreciated :-) Thanks, that is valuable additional data points. Much appreciated. - Jonas
Per https://uwsgi-docs.readthedocs.io/en/latest/Systemd.html#one-service-per-app-in-systemd and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130481 , of which I'm sure you're well aware, the conversation seems to lean towards "uWSGI provides the templates, the dependent packages need to implement them". I'm not nearly smart enough to understand systemd or init.d, but I tried to follow the instructions. I obviously need lots of hand holding to see this through. # I ran: systemctl enable uwsgi-app@radicale.socket systemctl enable uwsgi-app@radicale.service systemctl start uwsgi-app@radicale.socket # I changed /etc/apache2/conf-available/radicale-uwsgi.conf: 51,52c51,52 < ProxyPass unix:/run/uwsgi/app/${_RADICALE_APP}/socket|uwsgi://${_RADICALE_APP} retry=0 < ProxyPassReverse unix:/run/uwsgi/app/${_RADICALE_APP}/socket|uwsgi://${_RADICALE_APP} --- # to reflect uwsgi-app@radicale.socket After restarting Apache, the error messages change to: chdir() to /var/lib/radicale/collections chdir(): Permission denied [core/uwsgi.c line 3522] I tried changing uwsgi-app@radicale.service to: User=radicale Group=radicale ... to no effect. Apparently uWSGI is weird about permissions: https://serverfault.com/questions/872271/uwsgi-permission-denied-on-chdir-that-does-have-permissions-for-that-uid , and I haven't tried breaking /var/lib/radicale/collections to see if it makes any difference. Anyhow, this is pretty rudimentary stuff, but I hope it helps someone.
You might also want to check out <URL: https://bugs.debian.org/1130481 > which is also about this issue from the uwsgi side.
For further clarity, I tried Alexandre's suggestions in #15, but I get different errors: chdir() to /var/lib/radicale/collections chdir(): No such file or directory [core/uwsgi.c line 3522] ... which is a bald-faced lie. I can ls /var/lib/radicale/collections just fine. I suspect it has something to do with systemd going HAL 9000 on me and not restarting the sockets and services properly because I didn't do it in the right sequence. I'll reboot and see if anything changes.
So whoever fixes this must watch user permissions carefully to avoid more breakage. I tried rolling back using https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130481#61 , but the permissions were still broken on the folders, and I got permission errors on multiple reboots. I had to apt purge and reinstall uWSGI & Radicale to rebuild /var/lib/radicale/collections/ from scratch. My hypothesis is that one of the uwsgi-app units tinkered with folder permissions and broke uWSGI.
Not to be impatient, but is there a working patch or workaround exists for this? An AI bot and I have spent hours trying to figure this out, and it's come up empty. This makes sense as I seem to be the only person on Earth struggling with this. I can create the uwsgi-app@radical socket and service, and I've changed /etc/apache2/conf-available/radicale-uwsgi.conf to use the systemd sockets. I'm getting permission errors like I did 3 months ago. AI believes the file permissions are correct (I haven't changed them since this was last working) but something's going wrong with uWSGI. I've tried to graft https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/2768 into my setup without touching the python files. That's probably part of the problem. Anyhow, is there a known working radicale configuration with systemd?
Hi, The documentation patch I posted above gave me a working installation of radicale. If you still have permission error, maybe I can help you with some clue about the owner of radicale data and the systemd configuration used to run radical (e.g. systemctl cat uwsgi-app@radicale.service) and maybe an explicit error message. Alex
I'm definitely, 100%, never going to understand Linux. systemctl daemon-reload and systemctl restart apache2 apparently don't do what I thought they do. Hard reboot applied whatever I did.
Consistent with your suggestions, I changed:
/etc/apache2/conf-available/radicale-uwsgi.conf
51,52c51,52
- ProxyPass unix:/run/uwsgi/app/${_RADICALE_APP}/socket|uwsgi://${_RADICALE_APP} retry=0
- ProxyPassReverse unix:/run/uwsgi/app/${_RADICALE_APP}/socket|uwsgi://${_RADICALE_APP}
+ ProxyPass unix:/run/uwsgi/${_RADICALE_APP}.socket|uwsgi://${_RADICALE_APP} retry=0
+ ProxyPassReverse unix:/run/uwsgi/${_RADICALE_APP}.socket|uwsgi://${_RADICALE_APP}
# create and enable uwsgi-app@radicale.service & uwsgi-app@radicale.socket
$ systemctl edit uwsgi-app@radicale.service
[Service]
User=radicale
Group=radicale
StateDirectory=radicale
DynamicUser=no
(I look forward to the Internet's feedback about how this is terrible security practice)
Linking /var/lib/radicale/collections/collection-root/${USER} to ${HOMEDIR}/${radicale folder}/... works with the same permissions set under init.d .
Could we change radicale-uwsgi.conf & make uwsgi-app@radicale.{service, socket} during package installation?
Hi,
Great!
This is the particular part of your setup that makes you use DynamicUser=no.
You can also use ReadWritePaths=${HOMEDIR}/${radicale folder}
This would need a package update.
Thanks,
Alex
23 Jun 2026, 05:05 by niol@zincube.net: That change isn't working for me. I added ReadWritePaths, changed DynamicUser=yes, and removed User and Group. After rebooting (because I can't seem to commit the changes when systemctl restart doesn't) radicale broke again. journald output (with duplicate lines removed): systemd[1]: Starting uwsgi-app@radicale.socket - Socket for uWSGI app radicale... systemd[1]: Listening on uwsgi-app@radicale.socket - Socket for uWSGI app radicale. systemd[1]: Starting uwsgi-app@radicale.service - radicale uWSGI app... (uwsgi)[9999]: uwsgi-app@radicale.service: Failed to set up special execution directory in /var/lib: File exists (uwsgi)[9999]: uwsgi-app@radicale.service: Failed at step STATE_DIRECTORY spawning /usr/bin/uwsgi: File exists systemd[1]: uwsgi-app@radicale.service: Main process exited, code=exited, status=238/STATE_DIRECTORY systemd[1]: uwsgi-app@radicale.service: Failed with result 'exit-code'. systemd[1]: Failed to start uwsgi-app@radicale.service - radicale uWSGI app. systemd[1]: uwsgi-app@radicale.service: Start request repeated too quickly. systemd[1]: uwsgi-app@radicale.service: Failed with result 'start-limit-hit'. systemd[1]: uwsgi-app@radicale.socket: Failed with result 'service-start-limit-hit'. uwsgi[9999]: [uWSGI] getting INI configuration from /etc/uwsgi/apps-available/radicale.ini uwsgi[9999]: *** Starting uWSGI 2.0.31-debian (64bit) on [Wed Jun 24 06:00:00 2026] *** uwsgi[9999]: compiled with version: 15.2.0 on 16 January 2026 20:51:30 uwsgi[9999]: os: Linux-7.0.12+deb14.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.0.12-2 (2026-06-12) uwsgi[9999]: nodename: me uwsgi[9999]: machine: x86_64 uwsgi[9999]: clock source: unix uwsgi[9999]: pcre jit disabled uwsgi[9999]: detected number of CPU cores: 4 uwsgi[9999]: current working directory: / uwsgi[9999]: detected binary path: /usr/bin/uwsgi-core uwsgi[9999]: your processes number limit is 63205 uwsgi[9999]: your memory page size is 4096 bytes uwsgi[9999]: detected max file descriptor number: 1024 uwsgi[9999]: lock engine: pthread robust mutexes uwsgi[9999]: thunder lock: disabled (you can enable it with --thunder-lock) uwsgi[9999]: Python version: 3.13.14 (main, Jun 10 2026, 18:10:12) [GCC 15.2.0] uwsgi[9999]: Python main interpreter initialized at 0x7fa593b357c8 uwsgi[9999]: python threads support enabled uwsgi[9999]: The -s/--socket option is missing and stdin is not a socket. systemd[1]: uwsgi-app@radicale.service: Main process exited, code=exited, status=1/FAILURE I found in my troubleshooting is that someone (probably uwsgi) was messing around with the folder and file permissions. It took some effort to revert to my previous uwsgi-app@radicale configuration. A few more reboots and it seems to be co-operating again. Clearly not something you can expect me to get right without a lot of handholding. I hope something is useful there.
Hi,
owned by uid x and the uwsgi radicale service gets a random uid (DynamicUser=yes)
and gets permission denied errors on radicale date.
If a statically allocated user or group of the configured name already
exists, it is used and no dynamic user/group is allocated.
Dynamic users/groups are allocated from the UID/GID range 61184…65519.
systemd will recursively change the ownership of the [state] directory and
everything contained
So your setup needs either:
- a persitent user and ReadWritePaths, or
- DynamicUser=yes and StateDirectory=${HOMEDIR}/${radicale}
Changing conf does not need reboots, only daemon-reload and restart of service
or socket.
Thanks,
Alex
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html?#DynamicUser=
[2] https://0pointer.net/blog/dynamic-users-with-systemd.html