Starting radicale 3.1.5 via the init script fails with the following error: Apr 13 19:08:32 apu2 radicale: [2022-04-13 19:08:32 +0200] [5385] [CRITICAL] Invalid configuration: Failed to load config file '/dev/null/.config/radicale/config': [Errno 20] Not a directory: '/dev/null/.config/radicale/config' Apparenly, radicale now always tries to read ~/.config/radicale/config and crashes if this file doesn't exist. Well, this also seems like an upstream bug to me, it should check if this file exists and simply go on if not. However, as the radicale user's home directory created by acct-user/radicale is set to /dev/null, this file can't exist. I worked around this by modifying the init script. I added "-C /etc/radicale/config" to the "--exec /usr/bin/radicale" call. This makes radicale skipping searching for other config files. I'll also file an upstream bug report about this, but I think we have to work around this in Gentoo until this is fixed upstream.
PS: My upstream bug report can be found at https://github.com/Kozea/Radicale/issues/1234
Created attachment 770732 [details, diff] The patch I used for the init script Just for the sake of completeness: This is the change I did to the init script. This is not a proper fix (just a workaround), as this will bypass using ~/.config/radicale/config completely. Maybe, thinking of the possibility of setting a config file explicitely, we should introduce a /etc/conf.d/radicale file, with something like RADICALE_OPTS="-C /etc/radicale/config" which then will be used by the init script?
Okay, thinking about the patch again, this is still a proper fix, as ~/.config/radicale/config can't exist on a Gentoo system with /dev/null set as radicale's home. Using other configuration file could be realized by symlinking them to /etc/radicale/config. Nevertheless, I would add a /etc/conf.d/radicale to leave the -C setting up to user, also if upstream fixes this.
Sorry for the spam ;-) But: I just did a fresh install of radicale on another machine to track this down and noticed the following message: * Adding user 'radicale' to your system ... * - Userid: 327 * - Shell: /sbin/nologin * - Home: /var/lib/radicale * - Groups: radicale * - GECOS: added by portage for radicale * Updating comment for user 'radicale' ... * - Comment: User for www-apps/radicale Apparently, the radicale user DOES get a valid home directory on a fresh install. I tried to stop radicale on my production server, deinstalled acct-user/radicale and re-emerged it. After that, I only had to re-add the radicale user to the "letsenc" group I added it to manually before (to grant it read access to the Let's Encrypt certificate I use), and the startup error was gone. So maybe, this only affects updated older installations. I'm not completely sure if acct-user/radicale already existed when I did the first installation, or if I manually added it with /dev/null as home. If some older version of acct-user/radicale set /dev/null as home, I think this is an update problem, as the home directory wasn't updated. If not, it's still an update problem, as a possibly existing radicale user collided with the acct-user/radicale one. Well, still, a /etc/conf.d/radicale should be introduced imo ;-) And we do have some problem with acct-user/radicale, if this is not a fesh installation.
Upstream already fixed it :-)
Thanks for the report. I also found the need for a homedir when i took over the package. This https://github.com/gentoo/gentoo/commit/3ee7c679b887a4bfe0f2ce2fbf7229ac8f21866e introduced the setting of it. Not sure how the updates of the acct-user/ ebuilds work out in the end. The following commit https://github.com/gentoo/gentoo/commit/2e58ff40e404b0212c4f24c03b004171905f3680 clearly says that it wants ">=acct-user/radicale-0-r2" ... so it wants an account with a HOME set. I assume there must have been a "dispatch-conf" update of "/etc/passwd" which maybe was not merged correctly. In fact i would want to close this. But if you want to go and repro it and explain how to reach that state ... i would be happy to look into what went wrong. Otherwise i would just keep that in mind, in case anyone else comes with the same problem in the future.
I would not exclude this could be due to some incomplete/failed update. IIRC, I played around with different versions back then, maybe, this f**ked up something ...
i played a bit with docker to try and repro what might have happened docker run --rm -t -i gentoo/stage3 echo "MAKEOPTS=\"-j$( nproc )\"" >> /etc/portage/make.conf echo "FEATURES=\"parallel-fetch -ipc-sandbox -network-sandbox -pid-sandbox -sandbox -usersandbox\"" >> /etc/portage/make.conf emerge-webrsync emerge -n --quiet-build dev-vcs/git rm -rf /var/db/repos/gentoo/ git clone https://github.com/gentoo-mirror/gentoo.git /var/db/repos/gentoo/ --depth=20000 git -C /var/db/repos/gentoo/ checkout 3ee7c679b887a4bfe0f2ce2fbf7229ac8f21866e^ emerge --autounmask --autounmask-write y acct-user/radicale getent passwd radicale > radicale:x:327:327:User for www-apps/radicale:/dev/null:/sbin/nologin git -C /var/db/repos/gentoo/ checkout 2e58ff40e404b0212c4f24c03b004171905f3680 emerge --autounmask --autounmask-write y acct-user/radicale getent passwd radicale > radicale:x:327:327:User for www-apps/radicale:/var/lib/radicale:/sbin/nologin there was no need to merge changes on /etc/passwd in that docker setup, it just worked ... so i will have to close this, please reach out if you find a way to repro my guess is still that there must have been a user mistake on merging etc updates
Thanks so much for getting in touch with upstream! Even if there might have been mistakes on your side or in gentoo, the merged changes improve the quality anyways! That is just what we need!
I loved to ;-)
