Discussion:
spamd does not start
Jari Fredrisson
2014-10-07 15:55:39 UTC
Permalink
I built SA 3.4 using cpan to my old Debian Squeeze-lts.

***@hurricane:~# time service spamassassin start
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.

real 0m1.230s
user 0m0.220s
sys 0m0.016s

I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
Axb
2014-10-07 15:58:39 UTC
Permalink
Post by Jari Fredrisson
I built SA 3.4 using cpan to my old Debian Squeeze-lts.
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.
real 0m1.230s
user 0m0.220s
sys 0m0.016s
I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
have you tried to add -D to the init script and see what is says
Jari Fredrisson
2014-10-07 16:50:53 UTC
Permalink
Post by Axb
Post by Jari Fredrisson
I built SA 3.4 using cpan to my old Debian Squeeze-lts.
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.
real 0m1.230s
user 0m0.220s
sys 0m0.016s
I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
have you tried to add -D to the init script and see what is says
***@hurricane:~# service spamassassin start
Starting SpamAssassin Mail Filter Daemon: Oct 7 19:49:52.142 [7498]
dbg: logger: adding facilities: all
Oct 7 19:49:52.146 [7498] dbg: logger: logging level is DBG
Oct 7 19:49:52.275 [7498] dbg: logger: calling setlogsock(unix)
Oct 7 19:49:52.275 [7498] dbg: logger: opening syslog with unix socket
Oct 7 19:49:52.276 [7498] dbg: logger: successfully connected to
syslog/unix
Oct 7 19:49:52.276 [7498] dbg: logger: successfully added syslog method
Oct 7 19:49:52.279 [7498] dbg: spamd: will perform setuids? 0
Oct 7 19:49:52.282 [7498] dbg: spamd: socket module of choice:
IO::Socket::INET 1.31, Socket 2.015, have PF_INET, no PF_INET6, using
Socket::getaddrinfo, AI_ADDRCONFIG is supported
Oct 7 19:49:52.283 [7498] dbg: spamd: socket specification:
"192.168.1.117", IP address: 192.168.1.117, port: 783
Oct 7 19:49:52.283 [7498] dbg: spamd: attempting to listen on IP
addresses: 192.168.1.117, port 783
Oct 7 19:49:52.286 [7498] dbg: spamd: creating IO::Socket::INET socket:
Listen: 128, LocalAddr: 192.168.1.117, LocalPort: 783, Proto: tcp,
ReuseAddr: 1, Type: 1
Oct 7 19:49:52.287 [7498] dbg: spamd: server listen sockets fd bit
field: 00000100
Oct 7 19:49:52.288 [7498] dbg: logger: adding facilities: all
Oct 7 19:49:52.290 [7498] dbg: logger: logging level is DBG
Oct 7 19:49:52.291 [7498] dbg: generic: SpamAssassin version 3.4.0
Oct 7 19:49:52.292 [7498] dbg: generic: Perl 5.010001,
PREFIX=/usr/local, DEF_RULES_DIR=/usr/local/share/spamassassin,
LOCAL_RULES_DIR=/etc/mail/spamassassin,
LOCAL_STATE_DIR=/var/lib/spamassassin
Oct 7 19:49:52.295 [7498] dbg: config: timing enabled
Oct 7 19:49:52.295 [7498] dbg: config: score set 0 chosen.
child process [7500] exited or timed out without signaling production of
a PID file: exit 255 at /usr/local/bin/spamd line 2960.

Nothing new, I'm afraid.
Karsten Bräckelmann
2014-10-07 17:29:27 UTC
Permalink
Post by Jari Fredrisson
I built SA 3.4 using cpan to my old Debian Squeeze-lts.
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.
real 0m1.230s
I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
It states the "child process exited or timed out". Indeed, obviously not
a timeout, so the child process simply exited.

Anything in syslog left by the child?
--
char *t="\10pse\0r\0dtu\***@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Jari Fredrisson
2014-10-07 17:34:52 UTC
Permalink
Post by Karsten Bräckelmann
Post by Jari Fredrisson
I built SA 3.4 using cpan to my old Debian Squeeze-lts.
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.
real 0m1.230s
I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
It states the "child process exited or timed out". Indeed, obviously not
a timeout, so the child process simply exited.
Anything in syslog left by the child?
Thanks!

Oct 7 19:49:52 hurricane spamd[7500]: spamd: successfully daemonized
Oct 7 19:49:52 hurricane spamd[7500]: spamd: Preloading modules with
HOME=/tmp/spamd-7500-init
Oct 7 19:49:52 hurricane spamd[7500]: config: using
"/etc/mail/spamassassin" for site rules pre files
Oct 7 19:49:52 hurricane spamd[7500]: config: read file
/etc/mail/spamassassin/init.pre
Oct 7 19:49:52 hurricane spamd[7500]: config: read file
/etc/mail/spamassassin/v310.pre
Oct 7 19:49:52 hurricane spamd[7500]: config: read file
/etc/mail/spamassassin/v312.pre
Oct 7 19:49:52 hurricane spamd[7500]: config: read file
/etc/mail/spamassassin/v320.pre
Oct 7 19:49:52 hurricane spamd[7500]: config: read file
/etc/mail/spamassassin/v330.pre
Oct 7 19:49:52 hurricane spamd[7500]: config: read file
/etc/mail/spamassassin/v340.pre
Oct 7 19:49:52 hurricane spamd[7500]: config: using
"/usr/local/share/spamassassin" for sys rules pre files
Oct 7 19:49:52 hurricane spamd[7500]: config: using
"/usr/local/share/spamassassin" for default rules dir
Oct 7 19:49:52 hurricane spamd[7500]: config: no rules were found! Do
you need to run 'sa-update'?
Oct 7 19:49:53 hurricane spamd[7498]: child process [7500] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.

Sad me.
Reindl Harald
2014-10-07 17:38:21 UTC
Permalink
Post by Jari Fredrisson
Post by Karsten Bräckelmann
Post by Jari Fredrisson
I built SA 3.4 using cpan to my old Debian Squeeze-lts.
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.
real 0m1.230s
I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
It states the "child process exited or timed out". Indeed, obviously not
a timeout, so the child process simply exited.
Anything in syslog left by the child?
Thanks!
Oct 7 19:49:52 hurricane spamd[7500]: config: no rules were found! Do
you need to run 'sa-update'?
Sad me
well, you need to run "sa-update" if you did not already - the rules are
not part of the package because they are typically updated each day with
the shipped cron script
Jari Fredrisson
2014-10-07 17:45:08 UTC
Permalink
Post by Reindl Harald
Post by Jari Fredrisson
Post by Karsten Bräckelmann
Post by Jari Fredrisson
I built SA 3.4 using cpan to my old Debian Squeeze-lts.
Starting SpamAssassin Mail Filter Daemon: child process [4868] exited or
timed out without signaling production of a PID file: exit 255 at
/usr/local/bin/spamd line 2960.
real 0m1.230s
I read that line in spamd and it talks about two bugs. And a long
timeout needed. But this dies at once, hardly a timeout?
It states the "child process exited or timed out". Indeed, obviously not
a timeout, so the child process simply exited.
Anything in syslog left by the child?
Thanks!
Oct 7 19:49:52 hurricane spamd[7500]: config: no rules were found! Do
you need to run 'sa-update'?
Sad me
well, you need to run "sa-update" if you did not already - the rules
are not part of the package because they are typically updated each day
with the shipped cron script
Yes yes. I ran sa-update & sa-compile. I just wonder how I had not done
so earlier... Same head, same mistakes. Old head.
LuKreme
2014-10-08 03:56:54 UTC
Permalink
Post by Jari Fredrisson
I ran sa-update & sa-compile.
Should sa-compile be run after sa-update?

I have a crontab entry:

16 1 * * * /usr/local/bin/sa-update && /usr/local/etc/rc.d/sa-spamd restart

should I add an sa-compile call?
--
'It's still a lie. Like the lie about masks.' 'What lie about masks?'
'The way people say they hide faces.' 'They do hide faces,' said Nanny
Ogg. 'Only the one on the outside.' --Maskerade
Duane Hill
2014-10-08 10:56:44 UTC
Permalink
Post by LuKreme
Post by Jari Fredrisson
I ran sa-update & sa-compile.
Should sa-compile be run after sa-update?
16 1 * * * /usr/local/bin/sa-update &&
/usr/local/etc/rc.d/sa-spamd restart
should I add an sa-compile call?
I am on FreeBSD here. This is what I use:

Content of sa_update.sh:

#!/bin/sh

/usr/local/bin/sa-update -D --nogpg

if [ $? -eq 0 ] ; then
/usr/local/bin/sa-compile
/usr/local/etc/rc.d/sa-spamd restart
exit 0
else
exit 0
fi

This way, sa-compile is ran and spamd is restarted only when there is
an update. I then use the script in a cron which runs once per day.

I believe the way you have it, spamd will get restarted every time
your cron is ran whether there is an update or not.
--
Duane Hill
***@gmail.com
"If at first you don't succeed, so much for sky diving."
LuKreme
2014-10-08 20:11:06 UTC
Permalink
Post by Duane Hill
Post by LuKreme
Post by Jari Fredrisson
I ran sa-update & sa-compile.
Should sa-compile be run after sa-update?
16 1 * * * /usr/local/bin/sa-update &&
/usr/local/etc/rc.d/sa-spamd restart
should I add an sa-compile call?
#!/bin/sh
/usr/local/bin/sa-update -D --nogpg
if [ $? -eq 0 ] ; then
/usr/local/bin/sa-compile
/usr/local/etc/rc.d/sa-spamd restart
exit 0
else
exit 0
fi
This way, sa-compile is ran and spamd is restarted only when there is
an update. I then use the script in a cron which runs once per day.
I believe the way you have it, spamd will get restarted every time
your cron is ran whether there is an update or not.
It will get restarted if the sa-update process finishes cleanly (that’s what && does) which I think is the same as if [ $? -eq 0];

So, I’ll add an sa-compile in there, thanks.
--
Internet was down last night. Turns out I have two kids. They seem
pretty well-behaved
Duane Hill
2014-10-08 22:23:36 UTC
Permalink
Post by LuKreme
Post by Duane Hill
Post by LuKreme
Post by Jari Fredrisson
I ran sa-update & sa-compile.
Should sa-compile be run after sa-update?
16 1 * * * /usr/local/bin/sa-update &&
/usr/local/etc/rc.d/sa-spamd restart
should I add an sa-compile call?
#!/bin/sh
/usr/local/bin/sa-update -D --nogpg
if [ $? -eq 0 ] ; then
/usr/local/bin/sa-compile
/usr/local/etc/rc.d/sa-spamd restart
exit 0
else
exit 0
fi
This way, sa-compile is ran and spamd is restarted only when there is
an update. I then use the script in a cron which runs once per day.
I believe the way you have it, spamd will get restarted every time
your cron is ran whether there is an update or not.
It will get restarted if the sa-update process finishes cleanly
(that’s what && does) which I think is the same as if [ $? -eq 0];
So, I’ll add an sa-compile in there, thanks.
No. && is a way of chaining commands together. Your cron says run
sa-update and then restart spamd. In other words, when sa-update
finishes running, regardless if there was an update applied or not,
restart spamd.

The part in my shell script you mentioned '[ $? -eq 0]' tests to see
if the exit result of running sa-update is not equal to zero. If the
result is not equal to zero, meaning an update was loaded, run
sa-compile and restart spamd.
--
Duane Hill
***@gmail.com
"If at first you don't succeed, so much for sky diving."
Dave Warren
2014-10-08 22:31:07 UTC
Permalink
Post by Duane Hill
No. && is a way of chaining commands together. Your cron says run
sa-update and then restart spamd. In other words, when sa-update
finishes running, regardless if there was an update applied or not,
restart spamd.
I thought that ; would chain commands together and run both in sequence
regardless of the results, whereas && is a conditional for if the
previous command succeeded and || was a conditional for if the previous
command failed?

At least in bash...
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Duane Hill
2014-10-08 22:44:59 UTC
Permalink
Post by Dave Warren
Post by Duane Hill
No. && is a way of chaining commands together. Your cron says run
sa-update and then restart spamd. In other words, when sa-update
finishes running, regardless if there was an update applied or not,
restart spamd.
I thought that ; would chain commands together and run both in sequence
regardless of the results, whereas && is a conditional for if the
previous command succeeded and || was a conditional for if the previous
command failed?
At least in bash...
I stand corrected. I found this:

&& will automatically run the command on the right, as long as the
command on the left executes without an error return code.

Sorry for the noise.
--
Duane Hill
***@gmail.com
"If at first you don't succeed, so much for sky diving."
John Hardin
2014-10-08 22:38:20 UTC
Permalink
No. && is a way of chaining commands together.
...where the second command is only executed if the first command exited
with a zero status. && stops on failure.

try:

true && echo "was true"
false && echo "was false"

If you want it to execute the subsequent command regardless of exit status
of the first command, use a plain ;

</pedant>
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
***@impsec.org FALaholic #11174 pgpk -a ***@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Rights can only ever be individual, which means that you cannot
gain a right by joining a mob, no matter how shiny the issued
badges are, or how many of your neighbors are part of it. -- Marko
-----------------------------------------------------------------------
860 days since the first successful private support mission to ISS (SpaceX)
Duane Hill
2014-10-08 22:46:26 UTC
Permalink
Post by John Hardin
No. && is a way of chaining commands together.
...where the second command is only executed if the first command exited
with a zero status. && stops on failure.
true && echo "was true"
false && echo "was false"
If you want it to execute the subsequent command regardless of exit status
of the first command, use a plain ;
I stand corrected. I discovered that. Sorry for the noise.
--
Duane Hill
***@gmail.com
"If at first you don't succeed, so much for sky diving."
RW
2014-10-08 22:45:12 UTC
Permalink
On Wed, 8 Oct 2014 17:23:36 -0500
Post by Duane Hill
No. && is a way of chaining commands together.
&& is a logical AND
Post by Duane Hill
Your cron says run
sa-update and then restart spamd. In other words, when sa-update
finishes running, regardless if there was an update applied or not,
restart spamd.
No, it's conditional.

A && B has a logical value, if A is false then A && B can't possibly
be true so B isn't evaluated, this is called short-circuiting.
Amir Caspi
2014-10-08 22:46:24 UTC
Permalink
No. && is a way of chaining commands together. Your cron says run sa-update and then restart spamd. In other words, when sa-update finishes running, regardless if there was an update applied or not, restart spamd.
Unless I am mistaken, I believe this is not correct. On *nix systems, && is the logical "and" operator, and it can be used to chain commands as dependencies. && short-circuits on failure, so if the first command returns zero, the "and" would fail and the second command never runs. The second command is only evaluated if the first returns non-zero ("true"). Hence, spamd is restarted only if sa-update actually loads an update, and not otherwise.

This is the same reason why you can also see commands like:
do_this || die
in perl scripts, because the logical "or" operator || will short-circuit on success, hence the "fallback" command never gets run if the first one succeeded.
Amir Caspi
2014-10-08 22:47:47 UTC
Permalink
Looks like I'm late to the party. :-)

--- Amir
thumbed via iPhone
Post by Amir Caspi
No. && is a way of chaining commands together. Your cron says run sa-update and then restart spamd. In other words, when sa-update finishes running, regardless if there was an update applied or not, restart spamd.
Unless I am mistaken, I believe this is not correct. On *nix systems, && is the logical "and" operator, and it can be used to chain commands as dependencies. && short-circuits on failure, so if the first command returns zero, the "and" would fail and the second command never runs. The second command is only evaluated if the first returns non-zero ("true"). Hence, spamd is restarted only if sa-update actually loads an update, and not otherwise.
do_this || die
in perl scripts, because the logical "or" operator || will short-circuit on success, hence the "fallback" command never gets run if the first one succeeded.
Martin Gregorie
2014-10-08 23:31:08 UTC
Permalink
Post by Amir Caspi
No. && is a way of chaining commands together. Your cron says run sa-update and then restart spamd. In other words, when sa-update finishes running, regardless if there was an update applied or not, restart spamd.
Unless I am mistaken, I believe this is not correct. On *nix systems,
&& is the logical "and" operator, and it can be used to chain commands
as dependencies.
Correct.
Post by Amir Caspi
&& short-circuits on failure, so if the first command returns zero,
the "and" would fail and the second command never runs. The second
command is only evaluated if the first returns non-zero ("true").
Incorrect. sh and its descendants such as bash and ksh reverse the
representation of true and false with respect to C and its descendants:
in shell scripts a value of zero is TRUE and non-zero is FALSE.

This is a necessary feature since, by convention, under UNIX/Linux or
any other POSIX-compliant OS a program returns zero on success and a
non-zero value on failure. The non zero exit code *may* be a value
showing what the error was but this isn't guaranteed: all you can say is
that a non-zero exit code indicates that the program didn't complete its
usual activity.
Post by Amir Caspi
Hence, spamd is restarted only if sa-update actually loads an update,
and not otherwise.
Correct: "a && b" in a shell script means run b iff a was successful
Post by Amir Caspi
do_this || die
in perl scripts, because the logical "or" operator || will
short-circuit on success, hence the "fallback" command never gets run
if the first one succeeded.
True, but be aware that Perl, like C, C++, Java,.... represents false by
zero and true by non-zero values - the reverse of a Unix/Linux/POSIX
shell script.

In all cases there's no danger of confusion as long as you write logical
statements that are either boolean algebra that makes no attempt to
represent the value of a logical variable or only represents it by the
literals TRUE and FALSE.


Martin


Martin
Duane Hill
2014-10-09 04:34:40 UTC
Permalink
Post by Martin Gregorie
Post by Amir Caspi
No. && is a way of chaining commands together. Your cron says run sa-update and then restart spamd. In other words, when sa-update finishes running, regardless if there was an update applied or not, restart spamd.
Unless I am mistaken, I believe this is not correct. On *nix systems,
&& is the logical "and" operator, and it can be used to chain commands
as dependencies.
Correct.
Post by Amir Caspi
&& short-circuits on failure, so if the first command returns zero,
the "and" would fail and the second command never runs. The second
command is only evaluated if the first returns non-zero ("true").
Incorrect. sh and its descendants such as bash and ksh reverse the
in shell scripts a value of zero is TRUE and non-zero is FALSE.
This is a necessary feature since, by convention, under UNIX/Linux or
any other POSIX-compliant OS a program returns zero on success and a
non-zero value on failure. The non zero exit code *may* be a value
showing what the error was but this isn't guaranteed: all you can say is
that a non-zero exit code indicates that the program didn't complete its
usual activity.
Post by Amir Caspi
Hence, spamd is restarted only if sa-update actually loads an update,
and not otherwise.
Correct: "a && b" in a shell script means run b iff a was successful
Post by Amir Caspi
do_this || die
in perl scripts, because the logical "or" operator || will
short-circuit on success, hence the "fallback" command never gets run
if the first one succeeded.
True, but be aware that Perl, like C, C++, Java,.... represents false by
zero and true by non-zero values - the reverse of a Unix/Linux/POSIX
shell script.
In all cases there's no danger of confusion as long as you write logical
statements that are either boolean algebra that makes no attempt to
represent the value of a logical variable or only represents it by the
literals TRUE and FALSE.
Thanks for clarifying everything. So, if I had:

/usr/local/bin/sa-update && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart

the only time spamd would restart is if sa-update AND sa-compile were
successfully completed, correct?
--
Duane Hill
***@gmail.com
"If at first you don't succeed, so much for sky diving."
Olivier Nicole
2014-10-09 04:50:08 UTC
Permalink
Hi,
Post by Duane Hill
/usr/local/bin/sa-update && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart
the only time spamd would restart is if sa-update AND sa-compile were
successfully completed, correct?
Sorry for jumping in the conversation... I have solved that issue by
calling sa-update from a script (perl) and I do a spamassassin -lint
before ever trying to restart spamd (or amavisd in my case), so I am
sure that I will only restart on something clean.

That way, I can also update some rules that are not on sa-update.

And in any case, send myself an email if something went wrong.

Being executed only once a day, the extra load of a Perl script is
neglectible.

Best regards,

Olivier
Martin Gregorie
2014-10-09 10:57:00 UTC
Permalink
Post by Olivier Nicole
Hi,
Post by Duane Hill
/usr/local/bin/sa-update && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart
the only time spamd would restart is if sa-update AND sa-compile were
successfully completed, correct?
Yes, that's correct.
Post by Olivier Nicole
Sorry for jumping in the conversation... I have solved that issue by
calling sa-update from a script (perl) and I do a spamassassin -lint
before ever trying to restart spamd (or amavisd in my case), so I am
sure that I will only restart on something clean.
That way, I can also update some rules that are not on sa-update.
I do something similar on my SA rules development system (I also have SA
installed on this laptop but it is normally not running, which has the
side effect of disabling the standard Fedora sa-update cron job because
this won't run sa-update if it can't find the spamd daemon). My more
complex equivalent is a bash script rather than Perl which starts and
stops SA after a successful update in order to check that all is in
order. This is it. I think the use of the case...esac construct makes it
easier to read:

===========================================================================
#!/bin/bash
#
# Update the Spamassassin rules
#
sau=/usr/bin/sa-update

if [ -x $sau ]
then
$sau
err=$?
case $err in
0) echo "Spamassassin rules update completed.";
service spamassassin restart;
service spamassassin stop;
echo "Spamassassin restarted and then stopped." ;;

1) echo "No Spamassassin rule updates available.";;

2) echo "Spamassassin rules updates available";
echo "Site pre files lint check failed.";
echo "Fix the files and try again.";;

*) echo "Spamassassin rules update failed: error=$err"
esac
else
echo "Error: $sau does not exist"
exit 0
fi
===========================================================================
Post by Olivier Nicole
And in any case, send myself an email if something went wrong.
I get the mail 'for free' because I run logwatch, which picks up
anything logged by crond (i.e. anything sent to stdout and stderr by a
cron job) and mails it to root and, of course, I set up the mail aliases
so mail sent to root is redirected to my usual login.
Post by Olivier Nicole
Being executed only once a day, the extra load of a Perl script is
neglectible.
Agreed.


Martin
Olivier Nicole
2014-10-09 11:08:34 UTC
Permalink
Martin,
Post by Martin Gregorie
I do something similar on my SA rules development system (I also have SA
installed on this laptop but it is normally not running, which has the
side effect of disabling the standard Fedora sa-update cron job because
this won't run sa-update if it can't find the spamd daemon). My more
complex equivalent is a bash script rather than Perl which starts and
stops SA after a successful update in order to check that all is in
order. This is it. I think the use of the case...esac construct makes it
But you don't do a -lint before restarting SA: if an update was to break
SA (like a big Perl syntax error in a rule, or you are working on a
plugin on your production system, you feel safe because as long as you
don't restart spamd, any bad modification you make will not break SA),
you have stoppped the one that is currently working (and that could keep
working despite the update) amd you find yourself trying to restart a
broken version of SA.

Best regards,

Olivier
Post by Martin Gregorie
===========================================================================
#!/bin/bash
#
# Update the Spamassassin rules
#
sau=/usr/bin/sa-update
if [ -x $sau ]
then
$sau
err=$?
case $err in
0) echo "Spamassassin rules update completed.";
service spamassassin restart;
service spamassassin stop;
echo "Spamassassin restarted and then stopped." ;;
1) echo "No Spamassassin rule updates available.";;
2) echo "Spamassassin rules updates available";
echo "Site pre files lint check failed.";
echo "Fix the files and try again.";;
*) echo "Spamassassin rules update failed: error=$err"
esac
else
echo "Error: $sau does not exist"
exit 0
fi
===========================================================================
Post by Olivier Nicole
And in any case, send myself an email if something went wrong.
I get the mail 'for free' because I run logwatch, which picks up
anything logged by crond (i.e. anything sent to stdout and stderr by a
cron job) and mails it to root and, of course, I set up the mail aliases
so mail sent to root is redirected to my usual login.
Post by Olivier Nicole
Being executed only once a day, the extra load of a Perl script is
neglectible.
Agreed.
Martin
--
Martin Gregorie
2014-10-09 11:32:56 UTC
Permalink
Post by Olivier Nicole
But you don't do a -lint before restarting SA: if an update was to break
SA (like a big Perl syntax error in a rule, or you are working on a
plugin on your production system, you feel safe because as long as you
don't restart spamd, any bad modification you make will not break SA),
you have stoppped the one that is currently working (and that could keep
working despite the update) amd you find yourself trying to restart a
broken version of SA.
This isn't my production system: that is updated daily by the standard
RedHat cron job. This copy of SA is only run when I'm writing/modifying
rules or (much less often) working in a plugin. It is stopped 99% of the
time. It goes without saying that I use -lint during rule or plugin
development.

I'm certain that there is a lot in this script you could criticise, but
it does exactly what I need: pulls down any updated rules on a weekly
basis and finds any obvious errors in the download by starting and
stopping spamd and reporting its operation via logwatch. I posted it to
show anybody who doesn't use bash case statements just how readable they
can make a shell script.

Martin
LuKreme
2014-10-10 00:35:07 UTC
Permalink
This post might be inappropriate. Click to display it.
LuKreme
2014-10-10 00:38:12 UTC
Permalink
Post by LuKreme
No, that is not what it says.
$ man 1 bash

The control operators && and || denote AND lists and OR lists, respectively. An AND list has the form
Sorry for duplicating other’s posts, I replied to the original message out of the “replies to me” folder without checking the overall list folder.
--
'The gods,' he said. 'Imprisoned in a thought. And perhaps they were
never more than a dream.' --Sourcery
Jari Fredrisson
2014-10-10 19:40:51 UTC
Permalink
Post by LuKreme
Post by Jari Fredrisson
I ran sa-update & sa-compile.
Should sa-compile be run after sa-update?
Of course it should. I assumed && where I wrote &.

I was writing email, not bash.

RW
2014-10-08 11:17:32 UTC
Permalink
On Tue, 7 Oct 2014 21:56:54 -0600
Post by LuKreme
Post by Jari Fredrisson
I ran sa-update & sa-compile.
Should sa-compile be run after sa-update?
16 1 * * * /usr/local/bin/sa-update
&& /usr/local/etc/rc.d/sa-spamd restart
should I add an sa-compile call?
It's not essential to compile rules, it speeds things up by a
useful amount on busy servers but may not save as many cpu cycles as it
takes to do the compilation on light loads.

You have to uncomment the line:

loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody

in v320.pre for the compiled version to actually be used.

I think most people that compile rules do it after every update. but
AFAIK it's not essential - modified and new rules are just left to perl
if you don't.
Benny Pedersen
2014-10-08 15:55:59 UTC
Permalink
Post by LuKreme
16 1 * * * /usr/local/bin/sa-update && /usr/local/etc/rc.d/sa-spamd restart
should I add an sa-compile call?
If the plugin for precompiled body rules is enabled yes, check plugins in
pre file
Continue reading on narkive:
Loading...