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

We believe that the bug you reported is fixed in the latest version of
radicale, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1130672@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Smedegaard <dr@jones.dk> (supplier of updated radicale package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 12 Aug 2026 23:19:40 +0200
Source: radicale
Binary: python3-radicale radicale radicale-uwsgi
Architecture: source all
Version: 3.7.8+ds-2
Distribution: unstable
Urgency: medium
Maintainer: Jonas Smedegaard <dr@jones.dk>
Changed-By: Jonas Smedegaard <dr@jones.dk>
Description:
 python3-radicale - simple calendar and addressbook server - python3 module
 radicale   - simple calendar and addressbook server - daemon
 radicale-uwsgi - simple calendar and addressbook server - uWSGI Unix socket
Closes: 682017 982762 1130672
Changes:
 radicale (3.7.8+ds-2) unstable; urgency=medium
 .
   * tighten systemd unit file
   * relax uWSGI config file to use fewer workers and threads
   * move initial access rights setup
     from uWSGI config file to postinst script;
     closes: bug#682017, #982762,
     thanks to Konstantin Khomoutov, Martína Ferrari and Rob Browning
   * fix uWSGI-based setup and provide as binary package radicale-uwsgi;
     closes: bug#1130672,
     thanks to Borden, Alexandre Rossi and Petter Reinholdtsen
Checksums-Sha1:
 6ab9cec7b176623ac340a565e54c4299f77df7cc 2948 radicale_3.7.8+ds-2.dsc
 2efe4fde2ecbde71a5f828fa26aee32695426b6e 28900 radicale_3.7.8+ds-2.debian.tar.xz
 64818467cb45b479b232c21ce853cc4bc67e3acb 187852 python3-radicale_3.7.8+ds-2_all.deb
 c71d51c3d57c788d5a9b1d8c81562ad4189bca50 38444 radicale-uwsgi_3.7.8+ds-2_all.deb
 828d948a90cfb36f488c8f7a49f9dc951dfc6f1f 111576 radicale_3.7.8+ds-2_all.deb
 5f74b03c484c24213538dd4d63869d1bb1b6fc95 8643 radicale_3.7.8+ds-2_amd64.buildinfo
Checksums-Sha256:
 02f44ab44694bc6a2830843d9c0770e82408ab036dbcd4072eb99bc62193c41d 2948 radicale_3.7.8+ds-2.dsc
 fdc89e2c9f29a9578f399cb92b426235e17f1f4eab58354f8105477b7de9dd59 28900 radicale_3.7.8+ds-2.debian.tar.xz
 2dd9fc6164151d7d25a572eb4d5f988b96dfcdf5d333f4e37eb240ac3bec39d7 187852 python3-radicale_3.7.8+ds-2_all.deb
 ee44083b6f93f18dcb0d24aab8b55f28adb86cd2d5bb54ccf1e6424fb2752355 38444 radicale-uwsgi_3.7.8+ds-2_all.deb
 6e1938226a3a71064dd85ec2ced3ac0e0c87ed5e787df000f3b1ef6ca77d4840 111576 radicale_3.7.8+ds-2_all.deb
 0ded51f1591a97055d18b7f9b3c2fff17f41c9d0cd6a01b2430fddd2b5c00c4f 8643 radicale_3.7.8+ds-2_amd64.buildinfo
Files:
 2a6f8c1687611ff0d8ebc8f7394a0b0e 2948 net optional radicale_3.7.8+ds-2.dsc
 23e4464c4b5efd0c256baa546ba4f8c9 28900 net optional radicale_3.7.8+ds-2.debian.tar.xz
 9622a14b557bf2d110d1ddeab0aed97f 187852 python optional python3-radicale_3.7.8+ds-2_all.deb
 204e460d041de0760e438a6be5f1744c 38444 net optional radicale-uwsgi_3.7.8+ds-2_all.deb
 7b466408da8be74f9fcfabc06dda2e36 111576 net optional radicale_3.7.8+ds-2_all.deb
 51e0201ad378e7054a2708e1ea323f0a 8643 net optional radicale_3.7.8+ds-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmp887kMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh3W8P/3/CVzz3a0kNm2dgCHrK8ftSRT1hK0sS9UhFwobF
3NWadjYKhMeDbV6iu9STv60apwXJlp+qJr4YbsGY1oqlrn8yT+UQFAgaRQ8RCqzH
YqOdGBPdVxaP10lYA6oT+hqvHjSm7piJddlAHQVewVBIWGbUdt5A2v+a00nD/jMa
1QEO8es2EFA7fawg0aRP9oOGxZWKPU1gVrmWgubmMwgzl7BmO8XD0Za0nnyDpZR0
0cVG+1y1OYvFMxoM0aDIFxaojM0qze4A63t3cctlBjlyqWP5gFXyAi/avNFCbRXF
TdKf/Xw6d2R9Bl7J9PuDp+NFoZfd0vM+Kt2rs5BAnzBLkY3WCK++7d3yqNAM7rbI
V1smnxkgJYP9zuolTH/t6DhfSaIq85BQSnNTJU1WtGD84eNj+qGGeCOW4a4dul5c
3b+Ehomg649ARleAoeSapDvHUKYKnDIjHuAGxfGWwjXQAyUPNaQH0RFxiNtyl5ov
8vZd4i/wcLw2XWlmEEi90sXtIkici5PXTXukH65Oz4XToOjo+RcBAxlUfULU/zdo
+ppm4ZfjWkEe0rvYa/AEOViXyylypZg9bh0M79NTVP3UforuhRP3I3AsYOgLvWTd
vQyj3d3ScNtfBOF1uJzQqRcTA/h5QsyxqbLUSipMV99M+7qL3m9ywSfMjhoTU1w0
hqtu
=OvXI
-----END PGP SIGNATURE-----

This dosen't seem to work out-of-the-box. I believe /etc/apache2/conf-available/radicale-uwsgi.conf should say:
@@ -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:/run/uwsgi/${_RADICALE_APP}.socket|uwsgi://${_RADICALE_APP} retry=0
+	ProxyPassReverse unix:/run/uwsgi/${_RADICALE_APP}.socket|uwsgi://${_RADICALE_APP}
RequestHeader    set X-Forwarded-Port "%{SERVER_PORT}s"
RequestHeader    unset X-Forwarded-Proto
<If "%{HTTPS} =~ /on/">

Quoting Borden (2026-08-20 19:09:52)

That change should be applied:
https://salsa.debian.org/debian/radicale/-/commit/e87cf04#line_ac5485253_A51

Perhaps you did local edits to the file, and chose to keep your changes
instead of replacing with newer version of conffile at some point?

 - Jonas

Almost certainly not. I almost always use the package maintainer's copy when prompted. apt prompted me during the last radicale to overwrite /etc/radicale/config (?) because I need to set type=remote_user . But, yeah, your fix should have taken. I'll keep an eye on the next radicale upgrade.

Quoting Borden (2026-08-20 21:51:36)

Then I guess someone else has tampered with your system, because
although I don't find that likely, I do find it even less likely that
the official Debian package you installed looks like that when the one
I published does not, and even less likely that it was caused by random
bit flips.

 - Jonas