| Summary: | www-apps/radicale-3.1.5 crashes on start due to missing config file | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tobias Leupold <tl> |
| Component: | Current packages | Assignee: | Henning Schild <henning> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | jstein, proxy-maint |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | The patch I used for the init script | ||
|
Description
Tobias Leupold
2022-04-13 17:23:01 UTC
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 ;-) |