Description of problem: sa-update doesn't attempt to update when used with spamd Version-Release number of selected component (if applicable): spamassassin-3.3.2-7.fc16.i686 How reproducible: Always Steps to Reproduce: 1.Use default configuration in /etc/sysconfig/sa-update (in particular don't set SAUPDATE=YES 2. Use spamd 3. Execute /usr/share/spamassassin/sa-update.cron Actual results: No update is attempted Expected results: Update attempted, and applied if update available Additional info: The problem is a combination of the /usr/bin/spamd script and using pidof. In /usr/bin/spamd, there is the following code sub daemonize { # Pretty command line in ps $0 = join (' ', $ORIG_ARG0, @ORIG_ARGV) unless would_log("dbg"); The problem with this is that perl sets argv[0] to the whole string with each field space separated, which on my system is: /usr/bin/spamd -d -c --max-children=4 --min-children=0 --max-conn-per-child=10 -H /etc/mail/spamassassin pidof expects each parameter to be separated by a NUL char in /proc/PID/cmdline, but setting $0 in perl has them space separated. The consequence of this is that in /usr/share/spamassassin/sa-update.cron the following code doesn't recognise that spamd is executing, and so it terminates. for daemon in spamd amavisd; do /sbin/pidof $daemon >& /dev/null [ $? -eq 0 ] && SAUPDATE=yes done since pidof doesn't recognise that spamd is running due to the non-standard format of /proc/PID/cmdline.
A workaround is to replace /sbin/pidof with pgrep which is finding running spamd just fine. See also bug 770605 .
Michal: Your recommended work-around from Fedora 16 must still be applied in Fedora 17 with spamassassin 3.3.2-9.fc17.x86_64. Your report and explanation was thorough and easily understood. I would have thought this bug would have been resolved by this time. Many thanks for having reported it, saving me hours of frustration reinventing the solution. George Walsh
After implementing your work-around in the sa-update.cron script, I note that while the successful update is posted to /var/log/sa-update.log as expected, that I also receive notification from /etc/cron.daily/sa-update.cron to the effect that "Redirecting to /bin/systemctl condrestart spamassassin.service" has taken place. Obviously, the sa-update.cron script requires updating to recognize the use of systemctl functionality. Other then the email notification being generated, no other problems have been encountered on my server.
(In reply to comment #3) > ... that I also receive notification from > /etc/cron.daily/sa-update.cron to the effect that "Redirecting to > /bin/systemctl condrestart spamassassin.service" has taken place. That is systemd, after a switch to it, getting noisy. More of an annoyance than anything really broken but an annoyance all right. To turn that off you may modify sa-update.cron somewhat like that (let us hope that bugzilla will not mangle this too badly): --- /usr/share/spamassassin/sa-update.cron.orig 2012-03-20 08:53:33.270524698 -0600 +++ /usr/share/spamassassin/sa-update.cron 2012-08-03 11:36:50.165925159 -0600 @@ -70,10 +70,12 @@ else echo "$now: SpamAssassin: Update processed successfully" >>/var/log/sa-update.log fi - /sbin/service spamassassin condrestart > /dev/null - [ -f /etc/init.d/amavisd ] && /sbin/service amavisd condrestart > /dev/null - [ -f /var/run/mimedefang.pid ] && /sbin/service mimedefang reload > /dev/null - [ -f /etc/init.d/spampd ] && /etc/init.d/spampd condrestart > /dev/null + ( + /sbin/service spamassassin condrestart + [ -f /etc/init.d/amavisd ] && /sbin/service amavisd condrestart + [ -f /var/run/mimedefang.pid ] && /sbin/service mimedefang reload + [ -f /etc/init.d/spampd ] && /etc/init.d/spampd condrestart + ) >& /dev/null exit $status fi if [ $status -eq 1 ]; then That possibly should be another bug report but while this is one is still open and NEW ... How reliable are now or in the future tests for an existence of files /etc/init.d/amavisd and /etc/init.d/spampd is another good question. It looks to me that a simple '/sbin/service amavisd condrestart' with stdout and stderr redirected to /dev/null would work just fine.
Your prompt, thorough and easily understood update for the script is very much appreciated, Michal. I didn't see much point in opening up a "new" bug after previously implementing your work-around with pgrep, since that would have had to be done first anyway. Having taken up the challenge of completely rewriting 2 major web sites for a great friend, and as a labor of love to boot, I have become a bit stretched with applications and decidly script shy. But I can respect the concise, tidy way you made the changes, even getting rid of the repetitive /dev/nulls in the process and making the script easily understood. Back in UNIX days a bug lost its 'NEW' status after a defined span of time. Now, it seems, the term seems to mean 'not resolved', if it means anything. I've documented the script changes on my server in case things are still not addressed when F18 is launched. Again, my sincere thanks for extending a helping hand. Regards, "George"
spamassassin-3.3.2-12.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/spamassassin-3.3.2-12.fc17
spamassassin-3.3.2-12.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/spamassassin-3.3.2-12.fc16
Package spamassassin-3.3.2-12.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spamassassin-3.3.2-12.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-11496/spamassassin-3.3.2-12.fc16 then log in and leave karma (feedback).
spamassassin-3.3.2-12.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
spamassassin-3.3.2-12.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.