This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
error with starting radicale #894
Comments
|
I was getting that too, can't remember how i fixed it :( |
|
for me, after what seemed like a mostly painless upgrade from ubuntu 16.04 lts to 18, radicale was also not working, with similar errors. |
|
@peter33826 the logs you've provided are just from systemd telling radicale stops and systemd tries to restart it. Can you please enable the radicale logging and paste the radicale logs here (https://radicale.org/logging/). |
|
Hi, thanks for comments. I also actived logging. But my logging folder is still empty. |
|
@peter33826 Please take a look at the systemd logs with |
|
|
|
and
|
|
I had a similar problem and was wondering: Is anyone running Radicale 2.1.10 on Ubuntu 18.04? It was too working fine with executing the After uncommenting After setting |
|
@peter33826 I'm sorry for the late response. I think I can see your problem now. Please remove the You can find an example systemd unit file here: https://radicale.org/setup/ |
|
@mookie- I removed '--daemon' from the 'ExecStart' file, but it did not change anything. Any Ideas what could help? Thanks |
|
This is the output of
● radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server Jan 04 22:36:20 radicale systemd[1]: radicale.service: Service hold-off time over, scheduling restart. |
|
after a few seconds Radicale crashs: at 964ms it works But after 4s it is down |
|
And how does your |
|
This is my |
|
This is what I have: Some days ago I alredy wrote, what I had to change here to get meaningful error messages. |
|
@habubagit please add Then you should get more output. |
|
I can add that radicale.service works if User=root. Currently investigating the cause... |
|
@nja0087 did you double check the owner of the radicale installation and the folders are uses by (i.e.
In your systemd-unit file you start the service with user radicale ( |
|
I, too, am on Ubuntu 18.04 and have the same problem. [ I can also successfully run Radicale manually. ] /var/log/syslog reports: My implementation details:
|
|
For a more exhaustive test, I created the directory: /var/lib/radicale Then the syslog error message changed to: So . . . I created the directory /var/lib/radicale/collections Now the Radicale service starts, but browsing to the relevant:5232 URL reports " Unable to connect " rather than showing a Radicale login page (such as when I run the Radicale command manually) These directories (as well as my actual storage directory for the collections) are chown(ed) radicale:radicale . In theory, this means that either user radicale or user root should be able to run radicale successfully, right? |
|
Based on comments by @nja0087 and @return42, I have also tried setting the service to: Radicale still "runs" [and should I point out the (hopefully) obvious: I am stopping it and starting it after configuration changes] but the URL still shows "Unable to connect" when browsed to . . . Now I am really puzzled as manually running a Radicale "test" instance succeeded using a command similar to: |
|
@FBachofner please post your systemd unit file and your radicale configuration. Else it's hard to help you with this error. |
|
I just noticed:
I wonder whether this is somehow instructive? @mookie -- systemd and radicale.conf files coming up . . . |
|
my radicale.service file (in /etc/systemd/system ) my radicale.conf file (in /etc/radicale ) Note, I have tried both with and without the [auth] section enabled just to see whether it has any "positive" effect |
|
after once again enabling --debug I noticed the following syslog message:
WTF?!@#%*% " Listening to 'localhost' ?!" radicale.conf clearly states " hosts = 0.0.0.0:5232 " ANY computer on my network should be "listened to" Radicale is installed on a headless (and no Desktop Environment -installed) server, so I can NOT test it "locally" |
|
OK,
So I think I am down to one (current) issue: Why does Radicale not allow other hosts on my network to browse to Radicale's web interface when my radicale.conf clearly intends to allow all hosts (i.e. 0.0.0.0:5232)? This may be related to the radicale.service setting "ProtectSystem=strict" I will disable that, retry and report back. |
|
In radicale.service I disabled ProtectSystem=strict This modification still does not allow hosts (other than the local host) to access the Radicale web interface. Then, in radicale.service I disabled the whole "# Optional security settings" section with the exception of " ReadWritePaths=/my/redacted/special/path/to/radicale/collections " which references my data directory These additional modifications still does not allow hosts (other than the local host) to access the Radicale web interface! |
|
To the person who asked:
I'm just as confused as everyone else, but I will note that "/var/lib/radicale" is the home directory of the user radicale. I noticed this, because in attempting the test someone else did above changing User=root, the permission denied error I get suddenly changes to: How is it possible that root is getting a permission denied error? |
|
@cianci You error message shows "Read-only file system". Even root can't write to a Read-only file system. |
|
@FBachofner please try this If you configured 0.0.0.0:5253 and radicale isn't listening on this port, then probably your configuration isn't used. |
Perhaps I should have been more specific: In neither case (/root and /var/lib/radicale) is the filesystem mounted read only. The root user can (obviously) write to both of them (when invoked manually by me at cmdline), and the radicale user can create whatever it wants in /var/lib/radicale, also verified by direct testing. In the end, I gave up and added This seems to make it work for now [Shrug]. |
|
@cianci if it works if you manually start it from command line, then it's properly a problem with the systemd unit file configuration. Unfortunately I don't use systemd and can't help you there. But you could try to remove the "optional security settings" and check if it works then. |
|
I had the authors problem on ubuntu 18.10 as well. What solved the problem was adding |
|
I also had the same problem as the author and nothing really worked. I got |
|
I had the same issue. The |
|
I am using a different directory to store the collections directory in. My fix is to alter the radicale.service file |
|
For those who would face a similar issue on Ubuntu 23 : the service seems to be failing when it's started for the first time with all optional security settings. In my radicale.service file I commented all the settings below , and the service started fine: Optional security settingsPrivateTmp=trueProtectSystem=strictProtectHome=truePrivateDevices=trueProtectKernelTunables=trueProtectKernelModules=trueProtectControlGroups=trueNoNewPrivileges=trueReadWritePaths=/var/lib/radicale/collections Then I uncommented them one by one to check which one would cause me trouble, everything worked fine even with all of them enabled. That solved it for me ! |
|
@GosuJunk GitHub uses markdown to format your post, please wrap your example in back ticks https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#code-and-syntax-highlighting |
No wonder as you disabled now all "Optional security settings", question would be which particular one is causing issues. |
|
looks like systemd example file should be documented somewhere... |
|
I am on debian, just after upgrading from buster to bookworm and I am now getting this error. |
looks like this update had implicit a major upgrade of "radicale" from 2 to 3, where both options were dropped. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Hi,
I have problems starting radicale 2.1 automatically on Lubuntu 18.04.
Directly after reboot
systemctl status radicalesays this:But after a few seconds
systemctl status radicalesays this:Does anyone know what could be the reason?
When I run
python3 -m radicale --config "" --storage-filesystem-folder=/var/lib/radicale/collectionsmanually, radicale works fine.Thanks.
The text was updated successfully, but these errors were encountered: