Bug 755644 - sa-update doesn't execute update
Summary: sa-update doesn't execute update
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spamassassin
Version: 16
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-21 17:06 UTC by Quentin Armitage
Modified: 2012-08-14 01:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-14 01:01:16 UTC


Attachments (Terms of Use)

Description Quentin Armitage 2011-11-21 17:06:12 UTC
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.

Comment 1 Michal Jaegermann 2011-12-27 23:44:54 UTC
A workaround is to replace /sbin/pidof with pgrep which is finding running spamd just fine.

See also bug 770605 .

Comment 2 George Walsh 2012-08-02 00:33:47 UTC
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

Comment 3 George Walsh 2012-08-03 17:04:40 UTC
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.

Comment 4 Michal Jaegermann 2012-08-03 17:56:53 UTC
(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.

Comment 5 George Walsh 2012-08-03 18:49:56 UTC
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"

Comment 6 Fedora Update System 2012-08-03 20:55:24 UTC
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

Comment 7 Fedora Update System 2012-08-03 21:06:24 UTC
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

Comment 8 Fedora Update System 2012-08-05 21:25:29 UTC
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).

Comment 9 Fedora Update System 2012-08-14 01:01:16 UTC
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.

Comment 10 Fedora Update System 2012-08-14 01:02:03 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.