Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 646330 - mail-filter/spamassassin cron script causes amavisd crash
Summary: mail-filter/spamassassin cron script causes amavisd crash
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Philippe Chaintreuil
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-01 17:14 UTC by Nick Wiltshire
Modified: 2018-02-12 17:59 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Wiltshire 2018-02-01 17:14:16 UTC
If you install spamassassin with the cron use flag it gives you a bash script in /etc/cron.daily which runs sa-update and if the update was successful, issues a reload command to amavisd.

This needs to be changed to restart instead, as the reload causes a silent death of amavisd.

Feb  1 03:11:29 number5 amavis[31728]: (31728-18) ...n: 1.3 (0%)100
Feb  1 03:14:12 number5 amavis[3313]: logging initialized, log level 2, syslog: amavis.mail
Feb  1 03:14:12 number5 amavis[3313]: sd_notify (no socket): STATUS=Config files have been read, modules loaded.
Feb  1 03:14:12 number5 amavis[3313]: Valid PID file /var/amavis/amavisd.pid (younger than sys uptime 1 13:32:00)
Feb  1 03:14:12 number5 amavis[3313]: Signalling a SIGHUP to a running daemon [31717]
Feb  1 03:14:12 number5 amavis[31717]: Net::Server: Received a SIG HUP
Feb  1 03:14:12 number5 amavis[31717]: sd_notify (no socket): STOPPING=1\nSTATUS=Server rundown, notifying child processes.
Feb  1 03:14:12 number5 amavis[31717]: Net::Server: 2018/02/01-03:14:12 Server closing!
Feb  1 03:14:12 number5 amavis[31717]: Net::Server: Sending children hup signal
Feb  1 03:14:12 number5 amavis[31717]: sd_notify (no socket): RELOADING=1\nSTATUS=Reloading server, about to re-exec the program.
Feb  1 03:14:12 number5 amavis[31717]: (!)Net::Server: 2018/02/01-03:14:12 Re-exec server during HUP
Feb  1 09:33:34 number5 amavis[15677]: logging initialized, log level 2, syslog: amavis.mail


As you can see, amavis stopped silently at 3:14 AM and did nothing until I restarted it at 9:33.

It's death is silent in that an rc-status will indicate it's running.

Combined with bug 507352 you can not rc-service reload, you must issue a zap, then start.
Comment 1 Michael Orlitzky gentoo-dev 2018-02-05 19:41:07 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.
Comment 2 Nick Wiltshire 2018-02-06 20:45:41 UTC
-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.
Comment 3 Michael Orlitzky gentoo-dev 2018-02-08 22:17:05 UTC
(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.
Comment 4 Nick Wiltshire 2018-02-12 17:59:14 UTC
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!