You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2007/05/21 15:47:36 UTC

[Bug 5473] New: spamd behavior modification when sent SIGHUP

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5473

           Summary: spamd behavior modification when sent SIGHUP
           Product: Spamassassin
           Version: 3.2.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: spamc/spamd
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: blentz@channing-bete.com


I have grown accustomed to sending a SIGHUP signal to spamd after running
sa-update or manually modifying my rules. The documentation suggests using
$(/etc/init.d/spamassassin reload), and while the SpamAssassin-provided reload
function doesn't even exist for my platform (in ./spamd/redhat-rc-script.sh), it
is suggested in other platforms' scripts and in the spamd documentation that
this is the proper thing to do:

Note: If "spamd" receives a SIGHUP, it internally reloads itself, which means
that it will change its pid and might not restart at all if its environment
changed  (ie. if it can�t change back into its own directory).  If you plan to
use SIGHUP, you should always start "spamd" with the -r switch to know its
current pid.

After upgrading from 3.1.8 to 3.2.0, something has changed... the pgrep utility
can no longer find the process as "spamd" and instead finds it as "perl".

Before a sighup:
# cat /proc/9135/status | grep 'Name'
Name:   spamd
# cat /proc/9135/cmdline
/usr/bin/spamd -d -m15 -H

After a sighup:
# cat /proc/10540/status | grep 'Name'
Name:   perl
# cat /proc/10540/cmdline
/usr/bin/spamd -d -m15 -H

This breaks the vendor-provided initscripts, since the "status" function no
longer works after spamd is sent a SIGHUP. The status function uses pgrep. pgrep
does offer a -f parameter which forces pgrep to search through the cmdline
parameter, and will produce a successful match.

This also breaks using $(killall -s SIGHUP spamd), since killall can no longer
locate the spamd processes by name.

Since this report is loaded with optional, vendor-specific errata, I'll set
Severity to minor. However, this change was not noted explicitly in the release
notes as an intended design change, and it would be good to understand what's
going on.

This may very well be a duplicate of #5419, however, I'm not certain of the
status (marked "deferable") or activity of this bug.

Thanks



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 5473] spamd behavior modification when sent SIGHUP

Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5473


spamassassin@dostech.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Additional Comments From spamassassin@dostech.ca  2007-05-24 11:34 -------
For now at least, you're best off stopping and starting spamd... ie. 'restart'
via the RedHat script.

*** This bug has been marked as a duplicate of 5419 ***



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.