Summary: | mail-filter/spamassassin cron script causes amavisd crash | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick Wiltshire <nick> |
Component: | Current packages | Assignee: | Philippe Chaintreuil <gentoo_bugs_peep> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | bug, jstein, mjo, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Nick Wiltshire
2018-02-01 17:14:16 UTC
Bug 507352 seems to be about a bug in stop() after amavisd has already crashed. Can you check the permissions on all of the files that amavisd needs? I've been having this problem for years: https://lists.amavis.org/pipermail/amavis-users/2012-July/001738.html (The exact same symptoms as yours, in this case.) If either amavisd.conf or any of the files it needs are unreadable to the amavis user, then a "reload" will crash. A normal "start" works because the files are read as root the first time around. -rw------- 1 root amavis 119433 Jan 29 12:58 amavisd.conf I'm assuming that is the issue. Interestingly this started after a recent update. I hope the ebuild isn't causing it. Also, I've seen other init scripts correct permissions (postgresql comes to mind) when start() is called. That might help at least some users (obviously parsing the config is not realistic.) Either way, thanks for the tip. (In reply to Nick Wiltshire from comment #2) > -rw------- 1 root amavis 119433 Jan 29 12:58 amavisd.conf > > > I'm assuming that is the issue. Interestingly this started after a recent > update. I hope the ebuild isn't causing it. The ebuild looks to be doing the right thing, so who knows. Did the reload work last night after you made it group-readable? > Also, I've seen other init scripts correct permissions (postgresql comes to > mind) when start() is called. That might help at least some users (obviously > parsing the config is not realistic.) I'd really like this to be fixed upstream, because it would be so easy for amavisd to log a warning "hey, I can't read this file you want me to read," and that would work for *every* file mentioned in the config. Nevertheless, I'm not in charge of amavis in Gentoo or otherwise =) It's not obvious why, but fixing the permissions in the init script is a big ol' security risk and there's already one root exploit of that nature for amavisd-new, so I wouldn't recommend it. I found the culprit in another bash script changing permissions on amavisd.conf. I don't think it's possible for init to reasonably determine permissions of all the relevant files without parsing the config. Even the default amavis user can be changed within the config file. I agree with you it'd be best fixed upstream, and am marking this as such. Thanks for your help! |