Radicale is inactive

Support
1

Yesterday, I noticed that radicale was inactive on my rockpro64 with freedombox installed on top of Debian 13, so I disabled and re-enabled it.

Today, radicale was inactive again. After I disabled and re-enabled it, it works again. I ran diagnostics, all are successfull.

Did other people have the same situation?

I did not take the time to look at the journal (rather busy now), but I will do it at some point.

2

Yes, I’m having same issue. Haven’t tried debugging yet. Rebooting only temporarily solves the issue.

3

The new setup with radicale is such that there is a ‘socket’ unit that always keeps listening for new connections and a ‘service’ unit that may (not verified yet) automatically shutdown when not being used. As soon a new connection arrives on /radicale/ URL, systemd should automatically start the radicale service and pass on the incoming connection. All this work transparently to reduce resource usage when services are not being used. Users should not notice it and for them it appears as if service is always running.

But it looks like things are not working as expected. Since you are able to consistently reproduce the issue after a day, I will try to do the same and find out what’s going wrong.

4

Yesterday, what made me notice that radicale was not running was a failed diagnostic. Today, it was that I had evolution fail to access radicale. Both times, on the plinth page for radicale, there was a notification that the service was inactive.

5

We are tracking a bug on why diagnostic test is failing. But evolution failing to access should not happen.

6

This morning, none of my clients complain so radicale probably works but on the plinth page for radicale, there is the warning message that radicale is not working.

7

I’ve also been facing issues with Radicale for a few days now, diagnostics showing errors and the service not being available to clients.

Re-running the setup through plinth (which did try a re-installation) did not solve the issue, so I logged in via SSH to look at the logs.

I saw that the service was disabled and enabled & started it:

kopfkind@fbox:~ $ sudo systemctl status radicale
○ radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server
     Loaded: loaded (/usr/lib/systemd/system/radicale.service; disabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:radicale(1)

kopfkind@fbox:~ $ sudo systemctl enable radicale
Synchronizing state of radicale.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable radicale
Created symlink '/etc/systemd/system/multi-user.target.wants/radicale.service' → '/usr/lib/systemd/system/radicale.service'.

kopfkind@fbox:~ $ sudo systemctl start radicale

kopfkind@fbox:~ $ sudo systemctl status radicale
× radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server
     Loaded: loaded (/usr/lib/systemd/system/radicale.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2026-04-12 11:22:39 CEST; 9s ago
   Duration: 674ms
 Invocation: 79d1fa740a3141dc9205528ab9486deb
       Docs: man:radicale(1)
   Main PID: 788497 (code=exited, status=1/FAILURE)

Apr 12 11:22:39 fbox systemd[1]: radicale.service: Scheduled restart job, restart counter is at 5.
Apr 12 11:22:39 fbox systemd[1]: radicale.service: Start request repeated too quickly.
Apr 12 11:22:39 fbox systemd[1]: radicale.service: Failed with result 'exit-code'.
Apr 12 11:22:39 fbox systemd[1]: Failed to start radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server.

Logs with journalctl -u radicale are showing errors:

Apr 12 11:22:38 fbox radicale[788497]: [788497] [INFO] Storage location: '/var/lib/radicale/collections'
Apr 12 11:22:38 fbox radicale[788497]: [788497] [WARNING] Storage location: '/var/lib/radicale/collections' does not exist, creating now
Apr 12 11:22:38 fbox radicale[788497]: [788497] [CRITICAL] An exception occurred during server startup: [Errno 17] File exists: '/var/lib/radicale'

The storage location did (and does) exist already - I’ve been running radicale for years now. The folder /var/lib/radicale is a symlink to /var/lib/private/radicale, but the radicale user cannot access it:

# folder exists and belongs to radicale user:
root@fbox:~# ls -ld /var/lib/radicale/collections/
drwxr-x--- 3 radicale radicale 4096 Jun 16  2024 /var/lib/radicale/collections/

# But radicale user not allowed to access it:
root@fbox:~# sudo -u radicale ls -ld /var/lib/radicale/collections/
ls: cannot access '/var/lib/radicale/collections/': Permission denied

# folder is a symlink from /var/lib/radicale:
root@fbox:~# ls -l /var/lib/radicale
lrwxrwxrwx 1 root root 16 Apr  1 07:17 /var/lib/radicale -> private/radicale

# 'private' is owned by root and has mod 700:
root@fbox:~# ls -ld /var/lib/private
drwx------ 6 root root 4096 Apr  1 07:17 /var/lib/private

The service somehow does not recognize the existing storage location, and this leads to the error File exists: '/var/lib/radicale' above. I am unsure about the /var/lib/private thing here. I believe this is a systemd ‘DynamicUser’ thing and the permissions are there for a reason, so I would not want to change permissions on it (e. g. by allowing o+x).

Any other ideas?

8

Update after doing some more digging:

uswgi

I did not realize that FB uses uswgi for managing the service via systemd. I stumbled across it in this Salsa issue. I am not familiar with uswgi and how this affects my analysis of standard systemd units above.

However, I noticed that my FB showed bepasty to be installed and broken on the diagnostics, on top of radicale. I never installed not used bepasty on my FB and was quite surprised to see it popping up sometime after FB 26.5.1 - which was installed on April 1 through unattended-upgrades on my machine.

  • Question: Is there some kind of (wrong & broken) dependency that installs bepasty alongside any updates to radicale and/or uwsgi?
9

I’ve not found the root cause, yet. But I’ve managed to get my radicale installation back into working state by doing the following:

  • Make a backup copy of all data from /var/lib/private/radicale
  • Uninstall radicale via plinth web UI
  • Verify that data folders have been purged, nothing remains
  • Reinstall radicale via plinth
  • Check the data folders, they were still missing
    • This is not surprising, since radicale is activated by socket, so without a connecting client, the service will stay disabled.
  • Connect with a client once, connect & refresh, then verify that the data folders are now existing
    • This actually dropped all collections and data from the client since the server-side is blank after reinstallation. But I expected this and I’ve the backup copy made above.
  • Copy back my backed up data files into the (now existing) collection folders.
  • Make sure permissions are correct by running chown -R nobody:nogroup /var/lib/private/radicale/collections/collection-root/*
  • Reload & refresh on the client again. This time, everything is there and synchronization works again :white_check_mark:

One thing I noticed was that previous to the reinstallation all the data files would belong to the radicale user:group. After reinstallation, all the data belonged to nobody:nogroup, so I adopted this in my last step above. Not sure, but maybe this was somehow contributing to my issues.

Cheers & HTH,
Axel