With SA-3 (2.6X is ok), when using the conf option to run as another user, the spamd pid file is created after the user is changed. In my case, I choose to run spamd as user "cyrus". However the user "cyrus" cannot create any file in /var/run. Reproducible: Always Steps to Reproduce: 1. My conf.d/spam file contains: SPAMD_OPTS="-x -u cyrus" 2. 3. Actual Results: After a reboot, spamd seems to be running (and it is) but there is no pid file. If you try and stop it, its says its not running. If you start it again, it will start another instance on a different port. Then things get a bit confused. Expected Results: Its needs to write the pid file before changing UID. I didn't have this problem before SA-3. My workaround is to change the perms of /var/run to 1777.
Changing permissions for the whole of /var/run like that is not a very secure solution. Much better would be to create the directory /var/run/spamd, own it to the user you are running spamd as (in my case, spamd:root) and change $pidfile in /etc/init.d/spamd to reflect this. This does fix the issue, however it seems that for the first few seconds of spamd running it uses a large amount of CPU and cannot be restarted (start-stop-daemon will report "No process in pidfile `/var/run/spamd/spamd.pid' found running; none killed." if you remove --quiet). Whilst there is obviously still an intermittent issue with the init script here if you wait for a few seconds after spamd is started it can be stopped/restarted correctly. This fixes things like the cronjob for my_rules_du_jour (which will restart spamd if rules change) without affecting security. Unfortunately I cannot see that this can be incorporated into an ebuild very easily as every end-user will run spamd as a different UID, or possibly omit the -u flag to spamd altogether. The best solution might be an ewarn in the ebuild and a comment in /etc/conf.d/spamd.
Created attachment 45779 [details, diff] A patch to add a warning regarding -u flag to the ebuild Assuming this issue is not fixed by other means (e.g. the code is modified to create the PID before changing UID) this patch will add a simple ewarn to the ebuild. I attach it because the manpage (man 1 spamd) states that the location for the pidfile should be writable by the user running spamd, therefore I cannot see that the "problem" here is actually a bug.
Created attachment 45780 [details, diff] A patch to /etc/conf.d/spamd to add a warning regarding -u flag As attachment 45779 [details, diff], a warning added to the config file regarding the use of the -u flag.
I got bit by this too. Why not just add "-u cyrus" to SPAMD_OPTS in /etc/conf.d/spamd and create /var/run/spamd with the appropriate ownership if it doesn't exist? At least that's a reasonable default that allows things to work out of the box. It's done this way for all the other daemons (e.g. named), so why not spamd?
SpamAssassin isn't directly tied to cyrus, therefore it would probably be better to give a warning instead. Personally, I run spamd as the user spamd. spamd does work out of the box, as long as you do not use the -u flag as an option in /etc/conf.d/spamd.
Can the ebuild be updated to use /var/run/spamd/spamd.pid by default? Otherwise we have to edit the init script every time spamassassin is emerged.
*** Bug 75738 has been marked as a duplicate of this bug. ***
Ebuild also doesnt create spamd user. It would be fine if it could create it.
(In reply to comment #6) > Can the ebuild be updated to use /var/run/spamd/spamd.pid by default? Otherwise we have to edit the init script every time spamassassin is emerged. PIDFILE is set in /etc/conf.d/spamd. Change it there if you want to customize it. A sane user will be checking what they are replacing in an etc-update and correct accordingly ;) Same goes for the -u option. I'll apply the patch in attachment 45779 [details, diff] and 45780 (thanks David :)
*** Bug 77787 has been marked as a duplicate of this bug. ***
Mass re-assign.
*old bug cleaning bump* we fix this?
I suggest we close and forget it.
The notes I supplied were added to /etc/conf.d/spamd so users should have all the information they need to fix this issue if it arises. I suggest we close it too.
I just noticed that the information I supplied offers this: "You will then need to edit $pidfile in /etc/init.d/spamd" Which should now be: "You will then need to edit PIDFILE below."
The fix is "dont do that, then" goodby, bug..
