Just keeping track of a few things I wanted to change in the systemd service file for spamassassin. I would just go ahead and change them, but I have no way to test, so we're stuck waiting for a systemd user to help out. files/spamassassin.service-r1: 1. Change PIDFile=/run/spamd.pid to PIDFile=/run/spamd/spamd.pid. This is consistent with the OpenRC init script for v3.4.1. 1a. Adjust the --pidfile parameter in ExecStart to reflect the same. 2. Drop the -m 5 parameter from ExecStart. We'll add it to SPAMD_OPTS so that the user can change it easily. 3. Remove the "Restart=always" like; this should only be added in unusual cases where you expect a daemon to crash. files/spamassassin.service.conf: 1. Set SPAMD_OPTS to the same value it has in files/3.4.1-spamd.conf, namely SPAMD_OPTS="--max-children=5 --create-prefs --helper-home-dir".
@Michael: you should NOT remove "Restart" for all long-running daemons, since it is a safety feature and doesn't hurt. But instead of "always", we could use "on-failure" or "on-abnormal".
(In reply to Stefan Briesenick from comment #1) > @Michael: > > you should NOT remove "Restart" for all long-running daemons, since it is a > safety feature and doesn't hurt. But instead of "always", we could use > "on-failure" or "on-abnormal". On the contrary, I would say it's dangerous to restart a network daemon that isn't supposed to crash but that just crashed without understanding why. The SA daemon doesn't crash, and if it does, that's a serious problem that the admin needs to know about ASAP. In the extraordinary event that somebody expects his SA daemon to crash and he has investigated and deemed it safe, the Restart parameter is there to play with. But normal users should see that SA crashed and file a bug, if it ever does.
I would say that in general, people don't want to debug applications. People would rather that the spam filter keeps working all night instead of all their users finding a bunch of spam in the morning. Notification of the failure is definitely a good thing, but daemon's continuing to do their job is the most important to the non-developer.
There's a masked -r14 in the tree with a new service file and configuration. If anyone is actually using systemd with spamd, I would appreciate a thumbs up/down to let me know if it works. It now runs in the foreground, as a restricted user, and the service file is greatly simplified.
Not sure if this is related, but it feels it... I've just upgraded to 3.4.1-r15 which includes a much changed service file... but the service fails to start with: Aug 24 16:40:10 firebrand spamd[16880]: server socket setup failed, retry 9: spamd: could not create IO::Socket::IP socket on [0.0.0.0]:783: Permission denied Aug 24 16:40:11 firebrand spamd[16880]: spamd: could not create IO::Socket::IP socket on [0.0.0.0]:783: Permission denied Aug 24 16:40:11 firebrand systemd[1]: spamassassin.service: Main process exited, code=exited, status=13/n/a I'm assuming this is because the service itself starts as a user that can't open port 783 as opposed to previously starting as root and dropping to user spamd. Is this a bug or is there some config change I should make? Rolled back -r13 and that works fine again. Thanks.
(In reply to Dan Goodliffe from comment #5) > > I'm assuming this is because the service itself starts as a user that can't > open port 783 as opposed to previously starting as root and dropping to user > spamd. > Is this a bug or is there some config change I should make? > > Rolled back -r13 and that works fine again. > Yeah, it's because I screwed up. I didn't notice the low-numbered port. That's why I left -r13 in the tree though. Let me figure out what to do...
Dan, does the service file work if you remove the lines, User=spamd Group=spamd and if you change, ExecStart=/usr/sbin/spamd $SPAMD_OPTS to ExecStart=/usr/sbin/spamd $SPAMD_OPTS --username=spamd --groupname=spamd ? (And does the resulting process actually run as the spamd user/group?)
Hi Michael, Thanks for looking into this. Made the suggested changes. Process starts up fine, ps as follows: UID PID PPID C STIME TTY STAT TIME CMD root 29423 1 2 19:14 ? Ss 0:00 /usr/bin/perl -T -w /usr/sbin/spamd -c -H -i 0.0.0.0 -A 10.10. --username=spamd --groupname=spamd spamd 29430 29423 0 19:14 ? S 0:00 spamd child spamd 29431 29423 0 19:14 ? S 0:00 spamd child Previously those options were in the config file (or in my config file at least, no sure about the supplied one)
To clarify that a bit... this config file: /etc/systemd/system/spamassassin.service.d/00gentoo.conf [Service] Environment="SPAMD_OPTS= -c -H -i 0.0.0.0 -A 10.10. -u spamd -g spamd"
(In reply to Dan Goodliffe from comment #9) > To clarify that a bit... this config file: > > /etc/systemd/system/spamassassin.service.d/00gentoo.conf > > [Service] > Environment="SPAMD_OPTS= -c -H -i 0.0.0.0 -A 10.10. -u spamd -g spamd" That was my mistake... those two options don't belong in the conf file because you shouldn't change them. I moved them into the service file to avoid tempting people, but I moved them into systemd directives (which take effect as the process starts) and not flags to spamd (which take effect after spamd binds to port 783). I'm pushing out an -r16 in a second to fix this, thanks for your help.
-r16 is in the tree and should hit the mirrors within the hour. Please don't hesitate to complain if it doesn't work =)
Got it. Gone with default options across the board with the exception of listening IP address... and all looks good to me. Thanks.
