You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michael Heuberger <mi...@binarykitchen.com> on 2016/11/23 03:11:32 UTC
Weird Spamassassin startup behaviour on Ubuntu 16.10
Hello folks
New here :)
I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10 server
together with Monit (and Postfix of course). Each time server restarts,
Monit says first that the spamd process is not running (no PID) but in
three minutes later it says the opposite, that it is back up running.
There is the /etc/init.d/spamassassin file that boots Spamassassin on
start. But somehow it does not seem to get executed asap but 3 mins
later. No idea why.
The PID under /var/run/spamassassin.pid is owned by root and is
monitored under Monit with these configs:
# (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
$ cat spamassassin
check process spamd with pidfile /var/run/spamassassin.pid
group mail
start program = "/etc/init.d/spamassassin start" with timeout 180
seconds
stop program = "/etc/init.d/spamassassin stop"
if 5 restarts within 5 cycles then timeout
if cpu usage > 79% for 5 cycles then alert
if mem usage > 79% for 5 cycles then alert
depends on spamd_bin
depends on spamd_rc
check file spamd_rc with path /etc/init.d/spamassassin
group mail
if failed checksum then unmonitor
if failed permission 755 then unmonitor
if failed uid root then unmonitor
if failed gid root then unmonitor
check file spamd_bin with path /usr/sbin/spamd
group mail
if failed checksum then unmonitor
if failed permission 755 then unmonitor
if failed uid root then unmonitor
if failed gid root then unmonitor
Not sure what the problem is here. Could be one of these:
- a bug in /etc/init.d/spamassassin?
- a bad config in the above monit config
- something in postfix or another lib blocking spamassassin
No idea how to investigate. And there is no spamassassin log showing how
it starts up.
Any clues welcome
Cheers
Michael
--
Binary Kitchen
Michael Heuberger
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Marc Stürmer <ma...@marc-stuermer.de>.
Am 2016-11-23 04:11, schrieb Michael Heuberger:
> I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10
> server together with Monit (and Postfix of course). Each time server
> restarts, Monit says first that the spamd process is not running (no
> PID) but in three minutes later it says the opposite, that it is back
> up running.
>
> There is the /etc/init.d/spamassassin file that boots Spamassassin on
> start. But somehow it does not seem to get executed asap but 3 mins
> later. No idea why.
You are using SystemdD in conjunction with Monit. SystemD itself has
builtin daemon monitoring mechanisms, including automated restarts if a
daemon crashs.
So you want to make sure that not SystemD is in your case handling this
stuff, but Monit alone, otherwise the two different tools might be
interfering with each other.
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
many thanks, much appreciated shawn!
On 9/12/16 04:48, Shawn Bakhtiar wrote:
> I believe in order for that to be true you need to use do-release-upgrade
>
> https://help.ubuntu.com/lts/serverguide/installing-upgrading.html
>
> Which also handles the migration of the startup scripts etc....
> (regardless upgrades like these always tend to leave loose threads).
>
> For now thought I would simply focus on what's wrong, by adding the
> missing after directive in the [unit] section of your systemD SA
> config and see if that solves the problem.
>
> OT:
> I would also at this point think about disabling the monit, by doing
> an inventory of daemons you need running on that system, and verifying
> that systemD is aware of them. SysV init scripts can easily be
> integrated into SystemD, for any custom modules, or products that are
> not yet systemD integrated.
>
>
>> On Dec 7, 2016, at 12:37 PM, Michael Heuberger
>> <michael.heuberger@binarykitchen.com
>> <ma...@binarykitchen.com>> wrote:
>>
>> Right, it was upgraded from Ubuntu 14.10
>>
>> I thought apt-get dist-upgrade + update + upgrade is supposed to
>> migrate that stuff?
>>
>>
>> On 8/12/16 06:39, Shawn Bakhtiar wrote:
>>> Good point. Although since ubuntu 16.x systemD is the default init
>>> system, which begs the question, was the system upgraded or is this
>>> a fresh install?
>>>
>>>> On Dec 7, 2016, at 7:59 AM, shanew@shanew.net
>>>> <ma...@shanew.net> wrote:
>>>>
>>>> Since you appear to have both kinds of init files (sysV and systemd),
>>>> you may want to doublecheck which init system is actually running.
>>>> I'm pretty sure you can figure it out by running "dpkg -S /sbin/init"
>>>> (this tells you which package owns that file). It will probably say
>>>> systemd-sysv, in which case you'll want to follow Shawn's
>>>> instruction. If it says upstart, then you'll most likely need to edit
>>>> /etc/init.d/spamassassin instead.
>>>>
>>>> On Wed, 7 Dec 2016, Shawn Bakhtiar wrote:
>>>>
>>>>> Yeah... it's missing the "after" directive in the [unit] section,
>>>>> which
>>>>> would have systemD wait until the other services (targets) are up.
>>>>> But also
>>>>> as Marc mentioned not sure why you would use Monit since systemD
>>>>> (for all
>>>>> it's issues) does monitor daemons and makes sure to spawn them
>>>>> again if they
>>>>> die for any reason.
>>>>> although according to the Monit wiki you can run it with systemD
>>>>> (https://mmonit.com/wiki/Monit/Systemd), just not sure what the
>>>>> advantages
>>>>> are.
>>>>> You should have something like this:
>>>>> [unit]
>>>>> ...
>>>>> After=syslog.target network.target
>>>>> ...
>>>>> You can add any target to after directive in [unit] to make sure
>>>>> it's up
>>>>> before SA starts.
>>>>>
>>>>> On Dec 6, 2016, at 8:39 PM, Michael Heuberger
>>>>> <michael.heuberger@binarykitchen.com
>>>>> <ma...@binarykitchen.com>> wrote:
>>>>> Thanks Shawn
>>>>> Here the contents on my server:
>>>>> michael.heuberger@binarykitchen /l/s/system \u276f\u276f\u276f cat
>>>>> spamassassin.service
>>>>> [Unit]
>>>>> Description=Perl-based spam filter using text analysis
>>>>> [Service]
>>>>> Type=forking
>>>>> PIDFile=/var/run/spamassassin.pid
>>>>> EnvironmentFile=-/etc/default/spamassassin
>>>>> ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid
>>>>> $OPTIONS
>>>>> ExecReload=/bin/kill -HUP $MAINPID
>>>>> [Install]
>>>>> WantedBy=multi-user.target
>>>>> Does this seem to be outdated and wrong?
>>>>> - Michael
>>>>> On 7/12/16 09:29, Shawn Bakhtiar wrote:
>>>>> With Ubuntu 16.10 you should be using systemd.
>>>>> you can enable dependencies (after directive) which can make
>>>>> sure that all the services you need are started prior to (in the
>>>>> case of SA) the service you want.
>>>>> Check your systemD service configuration file:
>>>>> /usr/lib/systemd/system/spamassassin.service (or wherever your
>>>>> systemD config files are stored on Ubuntu.
>>>>> The content should be something like:
>>>>> [Unit]
>>>>> Description=Spamassassin daemon
>>>>> After=syslog.target network.target
>>>>> Wants=sa-update.timer
>>>>> [Service]
>>>>> EnvironmentFile=-/etc/sysconfig/spamassassin
>>>>> ExecStart=/usr/bin/spamd $SPAMDOPTIONS
>>>>> StandardOutput=null
>>>>> StandardError=null
>>>>> Restart=always
>>>>> [Install]
>>>>> WantedBy=multi-user.target
>>>>> Notice that systemd waits for syslog and network to complete
>>>>> before it launches spamassassin.
>>>>> Checkout this document if you have not and are still using
>>>>> upstart.
>>>>> https://wiki.ubuntu.com/SystemdForUpstartUsers
>>>>>
>>>>> On Dec 6, 2016, at 9:40 AM, shanew@shanew.net wrote:
>>>>> I recently set up an email server on Ubuntu 14.10 and kept
>>>>> being
>>>>> frustrated that on boot various filter software and
>>>>> related milters
>>>>> were regularly starting after sendmail, sometimes by as
>>>>> much as five
>>>>> minutes. We don't reboot that server very often, so it
>>>>> took a while
>>>>> to test various fixes, but in the end I added the
>>>>> following lines to
>>>>> the INIT INFO section of various milters (it's really only
>>>>> the first
>>>>> one that matters for startup):
>>>>> # X-Start-Before: sendmail
>>>>> # X-Stop-After: sendmail
>>>>> If postfix uses an /etc/init.d script like sendmail does
>>>>> on 14.10,
>>>>> check to see what the "Provides:" part of the INIT INFO is
>>>>> (probably
>>>>> postfix), and add an X-Start-Before line with tha value to
>>>>> the
>>>>> spamassassin init script. Or, if you just want to make
>>>>> sure that SA
>>>>> starts before monit, use whatever the "Provides:" is set
>>>>> to in the
>>>>> monit init script.
>>>>> If you have a mixture of SysV (regular) and upstart
>>>>> script, things get
>>>>> more complicated (unless 16.10 introduces functionality to
>>>>> make
>>>>> dependencies interoperable that doesn't exist in 14.10).
>>>>> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>>>>>
>>>>> Hi David
>>>>>
>>>>> I dont know. Not sure how I can find this out
>>>>> whether it does some DNS/network stuff.
>>>>>
>>>>> In my other response to John you can see that
>>>>> it takes about 5.69 sec to start spamassassin.
>>>>>
>>>>> And no idea how to configure a SA startup
>>>>> dependency on the network being up. And
>>>>> shouldn't that come along with the package
>>>>> when installed via apt-get?
>>>>>
>>>>> - Michael
>>>>>
>>>>> On 6/12/16 11:47, David B Funk wrote:
>>>>>
>>>>> Could it be some kind if
>>>>> interaction with other system
>>>>> services startup?
>>>>> (in particular this feels like a
>>>>> network timeout issue).
>>>>>
>>>>> One of the things SA does during
>>>>> its startup process is check to
>>>>> see if
>>>>> DNS/network stuff is available.
>>>>> If the system hasn't yet brought
>>>>> up the network stack when SA
>>>>> starts, it
>>>>> may hang waiting for the network
>>>>> to stabilize.
>>>>>
>>>>> On a running system, if you
>>>>> stop/restart SA do you see the
>>>>> same delay or
>>>>> is it only on a cold start of the
>>>>> system?
>>>>>
>>>>> Is it possible to configure a SA
>>>>> starup dependency on the network
>>>>> being
>>>>> up?
>>>>> --
>>>>> Public key #7BBC68D9 at | Shane
>>>>> Williams
>>>>> http://pgp.mit.edu/ | System Admin -
>>>>> UT CompSci
>>>>> =----------------------------------+-------------------------------
>>>>> All syllogisms contain three lines |
>>>>> shanew@shanew.net
>>>>> Therefore this is not a syllogism |
>>>>> www.ischool.utexas.edu/~shanew
>>>>>
>>>> --
>>>> Public key #7BBC68D9 at | Shane Williams
>>>> http://pgp.mit.edu/ | System Admin - UT CompSci
>>>> =----------------------------------+-------------------------------
>>>> All syllogisms contain three lines | shanew@shanew.net
>>>> <ma...@shanew.net>
>>>> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
>>>> <http://www.ischool.utexas.edu/%7Eshanew>
>>
>> --
>>
>> Binary Kitchen
>> Michael Heuberger
>> 1/33 Parrish Road
>> Sandringham
>> Auckland 1025
>> (New Zealand)
>>
>> Mobile (text only) ... +64 21 261 89 81
>> Email ................ michael@binarykitchen.com
>> <ma...@binarykitchen.com>
>> Website .............. http://www.binarykitchen.com
>>
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Shawn Bakhtiar <sh...@hotmail.com>.
I believe in order for that to be true you need to use do-release-upgrade
https://help.ubuntu.com/lts/serverguide/installing-upgrading.html
Which also handles the migration of the startup scripts etc.... (regardless upgrades like these always tend to leave loose threads).
For now thought I would simply focus on what's wrong, by adding the missing after directive in the [unit] section of your systemD SA config and see if that solves the problem.
OT:
I would also at this point think about disabling the monit, by doing an inventory of daemons you need running on that system, and verifying that systemD is aware of them. SysV init scripts can easily be integrated into SystemD, for any custom modules, or products that are not yet systemD integrated.
On Dec 7, 2016, at 12:37 PM, Michael Heuberger <mi...@binarykitchen.com>> wrote:
Right, it was upgraded from Ubuntu 14.10
I thought apt-get dist-upgrade + update + upgrade is supposed to migrate that stuff?
On 8/12/16 06:39, Shawn Bakhtiar wrote:
Good point. Although since ubuntu 16.x systemD is the default init system, which begs the question, was the system upgraded or is this a fresh install?
On Dec 7, 2016, at 7:59 AM, shanew@shanew.net<ma...@shanew.net> wrote:
Since you appear to have both kinds of init files (sysV and systemd),
you may want to doublecheck which init system is actually running.
I'm pretty sure you can figure it out by running "dpkg -S /sbin/init"
(this tells you which package owns that file). It will probably say
systemd-sysv, in which case you'll want to follow Shawn's
instruction. If it says upstart, then you'll most likely need to edit
/etc/init.d/spamassassin instead.
On Wed, 7 Dec 2016, Shawn Bakhtiar wrote:
Yeah... it's missing the "after" directive in the [unit] section, which
would have systemD wait until the other services (targets) are up. But also
as Marc mentioned not sure why you would use Monit since systemD (for all
it's issues) does monitor daemons and makes sure to spawn them again if they
die for any reason.
although according to the Monit wiki you can run it with systemD
(https://mmonit.com/wiki/Monit/Systemd), just not sure what the advantages
are.
You should have something like this:
[unit]
...
After=syslog.target network.target
...
You can add any target to after directive in [unit] to make sure it's up
before SA starts.
On Dec 6, 2016, at 8:39 PM, Michael Heuberger
<mi...@binarykitchen.com>> wrote:
Thanks Shawn
Here the contents on my server:
michael.heuberger@binarykitchen /l/s/system ❯❯❯ cat
spamassassin.service
[Unit]
Description=Perl-based spam filter using text analysis
[Service]
Type=forking
PIDFile=/var/run/spamassassin.pid
EnvironmentFile=-/etc/default/spamassassin
ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid
$OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
Does this seem to be outdated and wrong?
- Michael
On 7/12/16 09:29, Shawn Bakhtiar wrote:
With Ubuntu 16.10 you should be using systemd.
you can enable dependencies (after directive) which can make
sure that all the services you need are started prior to (in the
case of SA) the service you want.
Check your systemD service configuration file:
/usr/lib/systemd/system/spamassassin.service (or wherever your
systemD config files are stored on Ubuntu.
The content should be something like:
[Unit]
Description=Spamassassin daemon
After=syslog.target network.target
Wants=sa-update.timer
[Service]
EnvironmentFile=-/etc/sysconfig/spamassassin
ExecStart=/usr/bin/spamd $SPAMDOPTIONS
StandardOutput=null
StandardError=null
Restart=always
[Install]
WantedBy=multi-user.target
Notice that systemd waits for syslog and network to complete
before it launches spamassassin.
Checkout this document if you have not and are still using
upstart.
https://wiki.ubuntu.com/SystemdForUpstartUsers
On Dec 6, 2016, at 9:40 AM, shanew@shanew.net wrote:
I recently set up an email server on Ubuntu 14.10 and kept
being
frustrated that on boot various filter software and
related milters
were regularly starting after sendmail, sometimes by as
much as five
minutes. We don't reboot that server very often, so it
took a while
to test various fixes, but in the end I added the
following lines to
the INIT INFO section of various milters (it's really only
the first
one that matters for startup):
# X-Start-Before: sendmail
# X-Stop-After: sendmail
If postfix uses an /etc/init.d script like sendmail does
on 14.10,
check to see what the "Provides:" part of the INIT INFO is
(probably
postfix), and add an X-Start-Before line with tha value to
the
spamassassin init script. Or, if you just want to make
sure that SA
starts before monit, use whatever the "Provides:" is set
to in the
monit init script.
If you have a mixture of SysV (regular) and upstart
script, things get
more complicated (unless 16.10 introduces functionality to
make
dependencies interoperable that doesn't exist in 14.10).
On Tue, 6 Dec 2016, Michael Heuberger wrote:
Hi David
I dont know. Not sure how I can find this out
whether it does some DNS/network stuff.
In my other response to John you can see that
it takes about 5.69 sec to start spamassassin.
And no idea how to configure a SA startup
dependency on the network being up. And
shouldn't that come along with the package
when installed via apt-get?
- Michael
On 6/12/16 11:47, David B Funk wrote:
Could it be some kind if
interaction with other system
services startup?
(in particular this feels like a
network timeout issue).
One of the things SA does during
its startup process is check to
see if
DNS/network stuff is available.
If the system hasn't yet brought
up the network stack when SA
starts, it
may hang waiting for the network
to stabilize.
On a running system, if you
stop/restart SA do you see the
same delay or
is it only on a cold start of the
system?
Is it possible to configure a SA
starup dependency on the network
being
up?
--
Public key #7BBC68D9 at | Shane
Williams
http://pgp.mit.edu/ | System Admin -
UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines |
shanew@shanew.net
Therefore this is not a syllogism |
www.ischool.utexas.edu/~shanew
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net<ma...@shanew.net>
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew<http://www.ischool.utexas.edu/~shanew>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com<ma...@binarykitchen.com>
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Right, it was upgraded from Ubuntu 14.10
I thought apt-get dist-upgrade + update + upgrade is supposed to migrate
that stuff?
On 8/12/16 06:39, Shawn Bakhtiar wrote:
> Good point. Although since ubuntu 16.x systemD is the default init system, which begs the question, was the system upgraded or is this a fresh install?
>
>> On Dec 7, 2016, at 7:59 AM, shanew@shanew.net wrote:
>>
>> Since you appear to have both kinds of init files (sysV and systemd),
>> you may want to doublecheck which init system is actually running.
>> I'm pretty sure you can figure it out by running "dpkg -S /sbin/init"
>> (this tells you which package owns that file). It will probably say
>> systemd-sysv, in which case you'll want to follow Shawn's
>> instruction. If it says upstart, then you'll most likely need to edit
>> /etc/init.d/spamassassin instead.
>>
>> On Wed, 7 Dec 2016, Shawn Bakhtiar wrote:
>>
>>> Yeah... it's missing the "after" directive in the [unit] section, which
>>> would have systemD wait until the other services (targets) are up. But also
>>> as Marc mentioned not sure why you would use Monit since systemD (for all
>>> it's issues) does monitor daemons and makes sure to spawn them again if they
>>> die for any reason.
>>> although according to the Monit wiki you can run it with systemD
>>> (https://mmonit.com/wiki/Monit/Systemd), just not sure what the advantages
>>> are.
>>> You should have something like this:
>>> [unit]
>>> ...
>>> After=syslog.target network.target
>>> ...
>>> You can add any target to after directive in [unit] to make sure it's up
>>> before SA starts.
>>>
>>> On Dec 6, 2016, at 8:39 PM, Michael Heuberger
>>> <mi...@binarykitchen.com> wrote:
>>> Thanks Shawn
>>> Here the contents on my server:
>>> michael.heuberger@binarykitchen /l/s/system \u276f\u276f\u276f cat
>>> spamassassin.service
>>> [Unit]
>>> Description=Perl-based spam filter using text analysis
>>> [Service]
>>> Type=forking
>>> PIDFile=/var/run/spamassassin.pid
>>> EnvironmentFile=-/etc/default/spamassassin
>>> ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid
>>> $OPTIONS
>>> ExecReload=/bin/kill -HUP $MAINPID
>>> [Install]
>>> WantedBy=multi-user.target
>>> Does this seem to be outdated and wrong?
>>> - Michael
>>> On 7/12/16 09:29, Shawn Bakhtiar wrote:
>>> With Ubuntu 16.10 you should be using systemd.
>>> you can enable dependencies (after directive) which can make
>>> sure that all the services you need are started prior to (in the
>>> case of SA) the service you want.
>>> Check your systemD service configuration file:
>>> /usr/lib/systemd/system/spamassassin.service (or wherever your
>>> systemD config files are stored on Ubuntu.
>>> The content should be something like:
>>> [Unit]
>>> Description=Spamassassin daemon
>>> After=syslog.target network.target
>>> Wants=sa-update.timer
>>> [Service]
>>> EnvironmentFile=-/etc/sysconfig/spamassassin
>>> ExecStart=/usr/bin/spamd $SPAMDOPTIONS
>>> StandardOutput=null
>>> StandardError=null
>>> Restart=always
>>> [Install]
>>> WantedBy=multi-user.target
>>> Notice that systemd waits for syslog and network to complete
>>> before it launches spamassassin.
>>> Checkout this document if you have not and are still using
>>> upstart.
>>> https://wiki.ubuntu.com/SystemdForUpstartUsers
>>>
>>> On Dec 6, 2016, at 9:40 AM, shanew@shanew.net wrote:
>>> I recently set up an email server on Ubuntu 14.10 and kept
>>> being
>>> frustrated that on boot various filter software and
>>> related milters
>>> were regularly starting after sendmail, sometimes by as
>>> much as five
>>> minutes. We don't reboot that server very often, so it
>>> took a while
>>> to test various fixes, but in the end I added the
>>> following lines to
>>> the INIT INFO section of various milters (it's really only
>>> the first
>>> one that matters for startup):
>>> # X-Start-Before: sendmail
>>> # X-Stop-After: sendmail
>>> If postfix uses an /etc/init.d script like sendmail does
>>> on 14.10,
>>> check to see what the "Provides:" part of the INIT INFO is
>>> (probably
>>> postfix), and add an X-Start-Before line with tha value to
>>> the
>>> spamassassin init script. Or, if you just want to make
>>> sure that SA
>>> starts before monit, use whatever the "Provides:" is set
>>> to in the
>>> monit init script.
>>> If you have a mixture of SysV (regular) and upstart
>>> script, things get
>>> more complicated (unless 16.10 introduces functionality to
>>> make
>>> dependencies interoperable that doesn't exist in 14.10).
>>> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>>>
>>> Hi David
>>>
>>> I dont know. Not sure how I can find this out
>>> whether it does some DNS/network stuff.
>>>
>>> In my other response to John you can see that
>>> it takes about 5.69 sec to start spamassassin.
>>>
>>> And no idea how to configure a SA startup
>>> dependency on the network being up. And
>>> shouldn't that come along with the package
>>> when installed via apt-get?
>>>
>>> - Michael
>>>
>>> On 6/12/16 11:47, David B Funk wrote:
>>>
>>> Could it be some kind if
>>> interaction with other system
>>> services startup?
>>> (in particular this feels like a
>>> network timeout issue).
>>>
>>> One of the things SA does during
>>> its startup process is check to
>>> see if
>>> DNS/network stuff is available.
>>> If the system hasn't yet brought
>>> up the network stack when SA
>>> starts, it
>>> may hang waiting for the network
>>> to stabilize.
>>>
>>> On a running system, if you
>>> stop/restart SA do you see the
>>> same delay or
>>> is it only on a cold start of the
>>> system?
>>>
>>> Is it possible to configure a SA
>>> starup dependency on the network
>>> being
>>> up?
>>> --
>>> Public key #7BBC68D9 at | Shane
>>> Williams
>>> http://pgp.mit.edu/ | System Admin -
>>> UT CompSci
>>> =----------------------------------+-------------------------------
>>> All syllogisms contain three lines |
>>> shanew@shanew.net
>>> Therefore this is not a syllogism |
>>> www.ischool.utexas.edu/~shanew
>>>
>> --
>> Public key #7BBC68D9 at | Shane Williams
>> http://pgp.mit.edu/ | System Admin - UT CompSci
>> =----------------------------------+-------------------------------
>> All syllogisms contain three lines | shanew@shanew.net
>> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Shawn Bakhtiar <sh...@hotmail.com>.
Good point. Although since ubuntu 16.x systemD is the default init system, which begs the question, was the system upgraded or is this a fresh install?
> On Dec 7, 2016, at 7:59 AM, shanew@shanew.net wrote:
>
> Since you appear to have both kinds of init files (sysV and systemd),
> you may want to doublecheck which init system is actually running.
> I'm pretty sure you can figure it out by running "dpkg -S /sbin/init"
> (this tells you which package owns that file). It will probably say
> systemd-sysv, in which case you'll want to follow Shawn's
> instruction. If it says upstart, then you'll most likely need to edit
> /etc/init.d/spamassassin instead.
>
> On Wed, 7 Dec 2016, Shawn Bakhtiar wrote:
>
>> Yeah... it's missing the "after" directive in the [unit] section, which
>> would have systemD wait until the other services (targets) are up. But also
>> as Marc mentioned not sure why you would use Monit since systemD (for all
>> it's issues) does monitor daemons and makes sure to spawn them again if they
>> die for any reason.
>> although according to the Monit wiki you can run it with systemD
>> (https://mmonit.com/wiki/Monit/Systemd), just not sure what the advantages
>> are.
>> You should have something like this:
>> [unit]
>> ...
>> After=syslog.target network.target
>> ...
>> You can add any target to after directive in [unit] to make sure it's up
>> before SA starts.
>>
>> On Dec 6, 2016, at 8:39 PM, Michael Heuberger
>> <mi...@binarykitchen.com> wrote:
>> Thanks Shawn
>> Here the contents on my server:
>> michael.heuberger@binarykitchen /l/s/system ❯❯❯ cat
>> spamassassin.service
>> [Unit]
>> Description=Perl-based spam filter using text analysis
>> [Service]
>> Type=forking
>> PIDFile=/var/run/spamassassin.pid
>> EnvironmentFile=-/etc/default/spamassassin
>> ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid
>> $OPTIONS
>> ExecReload=/bin/kill -HUP $MAINPID
>> [Install]
>> WantedBy=multi-user.target
>> Does this seem to be outdated and wrong?
>> - Michael
>> On 7/12/16 09:29, Shawn Bakhtiar wrote:
>> With Ubuntu 16.10 you should be using systemd.
>> you can enable dependencies (after directive) which can make
>> sure that all the services you need are started prior to (in the
>> case of SA) the service you want.
>> Check your systemD service configuration file:
>> /usr/lib/systemd/system/spamassassin.service (or wherever your
>> systemD config files are stored on Ubuntu.
>> The content should be something like:
>> [Unit]
>> Description=Spamassassin daemon
>> After=syslog.target network.target
>> Wants=sa-update.timer
>> [Service]
>> EnvironmentFile=-/etc/sysconfig/spamassassin
>> ExecStart=/usr/bin/spamd $SPAMDOPTIONS
>> StandardOutput=null
>> StandardError=null
>> Restart=always
>> [Install]
>> WantedBy=multi-user.target
>> Notice that systemd waits for syslog and network to complete
>> before it launches spamassassin.
>> Checkout this document if you have not and are still using
>> upstart.
>> https://wiki.ubuntu.com/SystemdForUpstartUsers
>>
>> On Dec 6, 2016, at 9:40 AM, shanew@shanew.net wrote:
>> I recently set up an email server on Ubuntu 14.10 and kept
>> being
>> frustrated that on boot various filter software and
>> related milters
>> were regularly starting after sendmail, sometimes by as
>> much as five
>> minutes. We don't reboot that server very often, so it
>> took a while
>> to test various fixes, but in the end I added the
>> following lines to
>> the INIT INFO section of various milters (it's really only
>> the first
>> one that matters for startup):
>> # X-Start-Before: sendmail
>> # X-Stop-After: sendmail
>> If postfix uses an /etc/init.d script like sendmail does
>> on 14.10,
>> check to see what the "Provides:" part of the INIT INFO is
>> (probably
>> postfix), and add an X-Start-Before line with tha value to
>> the
>> spamassassin init script. Or, if you just want to make
>> sure that SA
>> starts before monit, use whatever the "Provides:" is set
>> to in the
>> monit init script.
>> If you have a mixture of SysV (regular) and upstart
>> script, things get
>> more complicated (unless 16.10 introduces functionality to
>> make
>> dependencies interoperable that doesn't exist in 14.10).
>> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>>
>> Hi David
>>
>> I dont know. Not sure how I can find this out
>> whether it does some DNS/network stuff.
>>
>> In my other response to John you can see that
>> it takes about 5.69 sec to start spamassassin.
>>
>> And no idea how to configure a SA startup
>> dependency on the network being up. And
>> shouldn't that come along with the package
>> when installed via apt-get?
>>
>> - Michael
>>
>> On 6/12/16 11:47, David B Funk wrote:
>>
>> Could it be some kind if
>> interaction with other system
>> services startup?
>> (in particular this feels like a
>> network timeout issue).
>>
>> One of the things SA does during
>> its startup process is check to
>> see if
>> DNS/network stuff is available.
>> If the system hasn't yet brought
>> up the network stack when SA
>> starts, it
>> may hang waiting for the network
>> to stabilize.
>>
>> On a running system, if you
>> stop/restart SA do you see the
>> same delay or
>> is it only on a cold start of the
>> system?
>>
>> Is it possible to configure a SA
>> starup dependency on the network
>> being
>> up?
>> --
>> Public key #7BBC68D9 at | Shane
>> Williams
>> http://pgp.mit.edu/ | System Admin -
>> UT CompSci
>> =----------------------------------+-------------------------------
>> All syllogisms contain three lines |
>> shanew@shanew.net
>> Therefore this is not a syllogism |
>> www.ischool.utexas.edu/~shanew
>>
>
> --
> Public key #7BBC68D9 at | Shane Williams
> http://pgp.mit.edu/ | System Admin - UT CompSci
> =----------------------------------+-------------------------------
> All syllogisms contain three lines | shanew@shanew.net
> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by sh...@shanew.net.
Since you appear to have both kinds of init files (sysV and systemd),
you may want to doublecheck which init system is actually running.
I'm pretty sure you can figure it out by running "dpkg -S /sbin/init"
(this tells you which package owns that file). It will probably say
systemd-sysv, in which case you'll want to follow Shawn's
instruction. If it says upstart, then you'll most likely need to edit
/etc/init.d/spamassassin instead.
On Wed, 7 Dec 2016, Shawn Bakhtiar wrote:
> Yeah... it's missing the "after" directive in the [unit] section, which
> would have systemD wait until the other services (targets) are up. But also
> as Marc mentioned not sure why you would use Monit since systemD (for all
> it's issues) does monitor daemons and makes sure to spawn them again if they
> die for any reason.�
> although according to the Monit wiki you can run it with systemD
> (https://mmonit.com/wiki/Monit/Systemd), just not sure what the advantages
> are.
>
> You should have something like this:
> [unit]
> ...
> After=syslog.target network.target
> ...
>
> You can add any target to after directive in [unit] to make sure it's up
> before SA starts.
>
>
> On Dec 6, 2016, at 8:39 PM, Michael Heuberger
> <mi...@binarykitchen.com> wrote:
>
> Thanks Shawn
>
> Here the contents on my server:
>
> michael.heuberger@binarykitchen /l/s/system \u276f\u276f\u276f cat
> spamassassin.service
> [Unit]
> Description=Perl-based spam filter using text analysis
>
> [Service]
> Type=forking
> PIDFile=/var/run/spamassassin.pid
> EnvironmentFile=-/etc/default/spamassassin
> ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid
> $OPTIONS
> ExecReload=/bin/kill -HUP $MAINPID
>
> [Install]
> WantedBy=multi-user.target
>
> Does this seem to be outdated and wrong?
>
> - Michael
>
>
> On 7/12/16 09:29, Shawn Bakhtiar wrote:
> With Ubuntu 16.10 you should be using systemd.�
> you can enable dependencies (after directive) which can make
> sure that all the services you need are started prior to (in the
> case of SA) the service you want. �
>
> Check your systemD service configuration file:
> /usr/lib/systemd/system/spamassassin.service (or wherever your
> systemD config files are stored on Ubuntu.
>
> The content should be something like:
>
> [Unit]
> Description=Spamassassin daemon
> After=syslog.target network.target
> Wants=sa-update.timer
>
> [Service]
> EnvironmentFile=-/etc/sysconfig/spamassassin
> ExecStart=/usr/bin/spamd $SPAMDOPTIONS
> StandardOutput=null
> StandardError=null
> Restart=always
>
> [Install]
> WantedBy=multi-user.target
>
>
> Notice that systemd waits for syslog and network to complete
> before it launches spamassassin.�
>
> Checkout this document if you have not and are still using
> upstart.
> https://wiki.ubuntu.com/SystemdForUpstartUsers
>
>
> On Dec 6, 2016, at 9:40 AM, shanew@shanew.net wrote:
>
> I recently set up an email server on Ubuntu 14.10 and kept
> being
> frustrated that on boot various filter software and
> related milters
> were regularly starting after sendmail, sometimes by as
> much as five
> minutes. �We don't reboot that server very often, so it
> took a while
> to test various fixes, but in the end I added the
> following lines to
> the INIT INFO section of various milters (it's really only
> the first
> one that matters for startup):
>
> # X-Start-Before: ���sendmail
> # X-Stop-After: �����sendmail
>
> If postfix uses an /etc/init.d script like sendmail does
> on 14.10,
> check to see what the "Provides:" part of the INIT INFO is
> (probably
> postfix), and add an X-Start-Before line with tha value to
> the
> spamassassin init script. �Or, if you just want to make
> sure that SA
> starts before monit, use whatever the "Provides:" is set
> to in the
> monit init script.
>
> If you have a mixture of SysV (regular) and upstart
> script, things get
> more complicated (unless 16.10 introduces functionality to
> make
> dependencies interoperable that doesn't exist in 14.10).
>
> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>
> Hi David
>
> I dont know. Not sure how I can find this out
> whether it does some DNS/network stuff.
>
> In my other response to John you can see that
> it takes about 5.69 sec to start spamassassin.
>
> And no idea how to configure a SA startup
> dependency on the network being up. And
> shouldn't that come along with the package
> when installed via apt-get?
>
> - Michael
>
>
> On 6/12/16 11:47, David B Funk wrote:
>
> Could it be some kind if
> interaction with other system
> services startup?
> (in particular this feels like a
> network timeout issue).
>
> One of the things SA does during
> its startup process is check to
> see if
> DNS/network stuff is available.
> If the system hasn't yet brought
> up the network stack when SA
> starts, it
> may hang waiting for the network
> to stabilize.
>
> On a running system, if you
> stop/restart SA do you see the
> same delay or
> is it only on a cold start of the
> system?
>
> Is it possible to configure a SA
> starup dependency on the network
> being
> up?
>
>
>
>
> --
> Public key #7BBC68D9 at �����������| ����������������Shane
> Williams
> http://pgp.mit.edu/ ���������������| �����System Admin -
> UT CompSci
> =----------------------------------+-------------------------------
> All syllogisms contain three lines |
> �������������shanew@shanew.net
> Therefore this is not a syllogism �|
> www.ischool.utexas.edu/~shanew
>
>
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Shawn Bakhtiar <sh...@hotmail.com>.
Yeah... it's missing the "after" directive in the [unit] section, which would have systemD wait until the other services (targets) are up. But also as Marc mentioned not sure why you would use Monit since systemD (for all it's issues) does monitor daemons and makes sure to spawn them again if they die for any reason.
although according to the Monit wiki you can run it with systemD (https://mmonit.com/wiki/Monit/Systemd), just not sure what the advantages are.
You should have something like this:
[unit]
...
After=syslog.target network.target
...
You can add any target to after directive in [unit] to make sure it's up before SA starts.
On Dec 6, 2016, at 8:39 PM, Michael Heuberger <mi...@binarykitchen.com>> wrote:
Thanks Shawn
Here the contents on my server:
michael.heuberger@binarykitchen /l/s/system ❯❯❯ cat spamassassin.service
[Unit]
Description=Perl-based spam filter using text analysis
[Service]
Type=forking
PIDFile=/var/run/spamassassin.pid
EnvironmentFile=-/etc/default/spamassassin
ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
Does this seem to be outdated and wrong?
- Michael
On 7/12/16 09:29, Shawn Bakhtiar wrote:
With Ubuntu 16.10 you should be using systemd.
you can enable dependencies (after directive) which can make sure that all the services you need are started prior to (in the case of SA) the service you want.
Check your systemD service configuration file:
/usr/lib/systemd/system/spamassassin.service (or wherever your systemD config files are stored on Ubuntu.
The content should be something like:
[Unit]
Description=Spamassassin daemon
After=syslog.target network.target
Wants=sa-update.timer
[Service]
EnvironmentFile=-/etc/sysconfig/spamassassin
ExecStart=/usr/bin/spamd $SPAMDOPTIONS
StandardOutput=null
StandardError=null
Restart=always
[Install]
WantedBy=multi-user.target
Notice that systemd waits for syslog and network to complete before it launches spamassassin.
Checkout this document if you have not and are still using upstart.
https://wiki.ubuntu.com/SystemdForUpstartUsers
On Dec 6, 2016, at 9:40 AM, shanew@shanew.net<ma...@shanew.net> wrote:
I recently set up an email server on Ubuntu 14.10 and kept being
frustrated that on boot various filter software and related milters
were regularly starting after sendmail, sometimes by as much as five
minutes. We don't reboot that server very often, so it took a while
to test various fixes, but in the end I added the following lines to
the INIT INFO section of various milters (it's really only the first
one that matters for startup):
# X-Start-Before: sendmail
# X-Stop-After: sendmail
If postfix uses an /etc/init.d script like sendmail does on 14.10,
check to see what the "Provides:" part of the INIT INFO is (probably
postfix), and add an X-Start-Before line with tha value to the
spamassassin init script. Or, if you just want to make sure that SA
starts before monit, use whatever the "Provides:" is set to in the
monit init script.
If you have a mixture of SysV (regular) and upstart script, things get
more complicated (unless 16.10 introduces functionality to make
dependencies interoperable that doesn't exist in 14.10).
On Tue, 6 Dec 2016, Michael Heuberger wrote:
Hi David
I dont know. Not sure how I can find this out whether it does some DNS/network stuff.
In my other response to John you can see that it takes about 5.69 sec to start spamassassin.
And no idea how to configure a SA startup dependency on the network being up. And shouldn't that come along with the package when installed via apt-get?
- Michael
On 6/12/16 11:47, David B Funk wrote:
Could it be some kind if interaction with other system services startup?
(in particular this feels like a network timeout issue).
One of the things SA does during its startup process is check to see if
DNS/network stuff is available.
If the system hasn't yet brought up the network stack when SA starts, it
may hang waiting for the network to stabilize.
On a running system, if you stop/restart SA do you see the same delay or
is it only on a cold start of the system?
Is it possible to configure a SA starup dependency on the network being
up?
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net<ma...@shanew.net>
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew<http://www.ischool.utexas.edu/%7Eshanew>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com<ma...@binarykitchen.com>
Website .............. http://www.binarykitchen.com<http://www.binarykitchen.com/>
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Thanks Shawn
Here the contents on my server:
michael.heuberger@binarykitchen /l/s/system \u276f\u276f\u276f cat spamassassin.service
[Unit]
Description=Perl-based spam filter using text analysis
[Service]
Type=forking
PIDFile=/var/run/spamassassin.pid
EnvironmentFile=-/etc/default/spamassassin
ExecStart=/usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
Does this seem to be outdated and wrong?
- Michael
On 7/12/16 09:29, Shawn Bakhtiar wrote:
> With Ubuntu 16.10 you should be using systemd.
>
> you can enable dependencies (after directive) which can make sure that
> all the services you need are started prior to (in the case of SA) the
> service you want.
>
> Check your systemD service configuration file:
> /usr/lib/systemd/system/spamassassin.service (or wherever your systemD
> config files are stored on Ubuntu.
>
> The content should be something like:
>
> [Unit]
> Description=Spamassassin daemon
> After=syslog.target network.target
> Wants=sa-update.timer
>
> [Service]
> EnvironmentFile=-/etc/sysconfig/spamassassin
> ExecStart=/usr/bin/spamd $SPAMDOPTIONS
> StandardOutput=null
> StandardError=null
> Restart=always
>
> [Install]
> WantedBy=multi-user.target
>
>
> Notice that systemd waits for syslog and network to complete before it
> launches spamassassin.
>
> Checkout this document if you have not and are still using upstart.
> https://wiki.ubuntu.com/SystemdForUpstartUsers
>
>
>> On Dec 6, 2016, at 9:40 AM, shanew@shanew.net
>> <ma...@shanew.net> wrote:
>>
>> I recently set up an email server on Ubuntu 14.10 and kept being
>> frustrated that on boot various filter software and related milters
>> were regularly starting after sendmail, sometimes by as much as five
>> minutes. We don't reboot that server very often, so it took a while
>> to test various fixes, but in the end I added the following lines to
>> the INIT INFO section of various milters (it's really only the first
>> one that matters for startup):
>>
>> # X-Start-Before: sendmail
>> # X-Stop-After: sendmail
>>
>> If postfix uses an /etc/init.d script like sendmail does on 14.10,
>> check to see what the "Provides:" part of the INIT INFO is (probably
>> postfix), and add an X-Start-Before line with tha value to the
>> spamassassin init script. Or, if you just want to make sure that SA
>> starts before monit, use whatever the "Provides:" is set to in the
>> monit init script.
>>
>> If you have a mixture of SysV (regular) and upstart script, things get
>> more complicated (unless 16.10 introduces functionality to make
>> dependencies interoperable that doesn't exist in 14.10).
>>
>> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>>
>>> Hi David
>>>
>>> I dont know. Not sure how I can find this out whether it does some
>>> DNS/network stuff.
>>>
>>> In my other response to John you can see that it takes about 5.69
>>> sec to start spamassassin.
>>>
>>> And no idea how to configure a SA startup dependency on the network
>>> being up. And shouldn't that come along with the package when
>>> installed via apt-get?
>>>
>>> - Michael
>>>
>>>
>>> On 6/12/16 11:47, David B Funk wrote:
>>>>
>>>> Could it be some kind if interaction with other system services
>>>> startup?
>>>> (in particular this feels like a network timeout issue).
>>>>
>>>> One of the things SA does during its startup process is check to see if
>>>> DNS/network stuff is available.
>>>> If the system hasn't yet brought up the network stack when SA
>>>> starts, it
>>>> may hang waiting for the network to stabilize.
>>>>
>>>> On a running system, if you stop/restart SA do you see the same
>>>> delay or
>>>> is it only on a cold start of the system?
>>>>
>>>> Is it possible to configure a SA starup dependency on the network being
>>>> up?
>>>
>>>
>>
>> --
>> Public key #7BBC68D9 at | Shane Williams
>> http://pgp.mit.edu/ | System Admin - UT CompSci
>> =----------------------------------+-------------------------------
>> All syllogisms contain three lines | shanew@shanew.net
>> <ma...@shanew.net>
>> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
>> <http://www.ischool.utexas.edu/%7Eshanew>
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Shawn Bakhtiar <sh...@hotmail.com>.
With Ubuntu 16.10 you should be using systemd.
you can enable dependencies (after directive) which can make sure that all the services you need are started prior to (in the case of SA) the service you want.
Check your systemD service configuration file:
/usr/lib/systemd/system/spamassassin.service (or wherever your systemD config files are stored on Ubuntu.
The content should be something like:
[Unit]
Description=Spamassassin daemon
After=syslog.target network.target
Wants=sa-update.timer
[Service]
EnvironmentFile=-/etc/sysconfig/spamassassin
ExecStart=/usr/bin/spamd $SPAMDOPTIONS
StandardOutput=null
StandardError=null
Restart=always
[Install]
WantedBy=multi-user.target
Notice that systemd waits for syslog and network to complete before it launches spamassassin.
Checkout this document if you have not and are still using upstart.
https://wiki.ubuntu.com/SystemdForUpstartUsers
On Dec 6, 2016, at 9:40 AM, shanew@shanew.net<ma...@shanew.net> wrote:
I recently set up an email server on Ubuntu 14.10 and kept being
frustrated that on boot various filter software and related milters
were regularly starting after sendmail, sometimes by as much as five
minutes. We don't reboot that server very often, so it took a while
to test various fixes, but in the end I added the following lines to
the INIT INFO section of various milters (it's really only the first
one that matters for startup):
# X-Start-Before: sendmail
# X-Stop-After: sendmail
If postfix uses an /etc/init.d script like sendmail does on 14.10,
check to see what the "Provides:" part of the INIT INFO is (probably
postfix), and add an X-Start-Before line with tha value to the
spamassassin init script. Or, if you just want to make sure that SA
starts before monit, use whatever the "Provides:" is set to in the
monit init script.
If you have a mixture of SysV (regular) and upstart script, things get
more complicated (unless 16.10 introduces functionality to make
dependencies interoperable that doesn't exist in 14.10).
On Tue, 6 Dec 2016, Michael Heuberger wrote:
Hi David
I dont know. Not sure how I can find this out whether it does some DNS/network stuff.
In my other response to John you can see that it takes about 5.69 sec to start spamassassin.
And no idea how to configure a SA startup dependency on the network being up. And shouldn't that come along with the package when installed via apt-get?
- Michael
On 6/12/16 11:47, David B Funk wrote:
Could it be some kind if interaction with other system services startup?
(in particular this feels like a network timeout issue).
One of the things SA does during its startup process is check to see if
DNS/network stuff is available.
If the system hasn't yet brought up the network stack when SA starts, it
may hang waiting for the network to stabilize.
On a running system, if you stop/restart SA do you see the same delay or
is it only on a cold start of the system?
Is it possible to configure a SA starup dependency on the network being
up?
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net<ma...@shanew.net>
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew<http://www.ischool.utexas.edu/~shanew>
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Thanks for that David.
Had a look here:
michael.heuberger@binarykitchen /e/init.d \u276f\u276f\u276f head spamassassin
#! /bin/sh
### BEGIN INIT INFO
# Provides: spamassassin
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Should-Start: $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
...
Does this seem right for you for an Ubuntu 16.10 server?
- Michael
On 7/12/16 06:40, shanew@shanew.net wrote:
> I recently set up an email server on Ubuntu 14.10 and kept being
> frustrated that on boot various filter software and related milters
> were regularly starting after sendmail, sometimes by as much as five
> minutes. We don't reboot that server very often, so it took a while
> to test various fixes, but in the end I added the following lines to
> the INIT INFO section of various milters (it's really only the first
> one that matters for startup):
>
> # X-Start-Before: sendmail
> # X-Stop-After: sendmail
>
> If postfix uses an /etc/init.d script like sendmail does on 14.10,
> check to see what the "Provides:" part of the INIT INFO is (probably
> postfix), and add an X-Start-Before line with tha value to the
> spamassassin init script. Or, if you just want to make sure that SA
> starts before monit, use whatever the "Provides:" is set to in the
> monit init script.
>
> If you have a mixture of SysV (regular) and upstart script, things get
> more complicated (unless 16.10 introduces functionality to make
> dependencies interoperable that doesn't exist in 14.10).
>
> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>
>> Hi David
>>
>> I dont know. Not sure how I can find this out whether it does some
>> DNS/network stuff.
>>
>> In my other response to John you can see that it takes about 5.69 sec
>> to start spamassassin.
>>
>> And no idea how to configure a SA startup dependency on the network
>> being up. And shouldn't that come along with the package when
>> installed via apt-get?
>>
>> - Michael
>>
>>
>> On 6/12/16 11:47, David B Funk wrote:
>>>
>>> Could it be some kind if interaction with other system services
>>> startup?
>>> (in particular this feels like a network timeout issue).
>>>
>>> One of the things SA does during its startup process is check to
>>> see if
>>> DNS/network stuff is available.
>>> If the system hasn't yet brought up the network stack when SA
>>> starts, it
>>> may hang waiting for the network to stabilize.
>>>
>>> On a running system, if you stop/restart SA do you see the same
>>> delay or
>>> is it only on a cold start of the system?
>>>
>>> Is it possible to configure a SA starup dependency on the network
>>> being
>>> up?
>>>
>>
>>
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by sh...@shanew.net.
I recently set up an email server on Ubuntu 14.10 and kept being
frustrated that on boot various filter software and related milters
were regularly starting after sendmail, sometimes by as much as five
minutes. We don't reboot that server very often, so it took a while
to test various fixes, but in the end I added the following lines to
the INIT INFO section of various milters (it's really only the first
one that matters for startup):
# X-Start-Before: sendmail
# X-Stop-After: sendmail
If postfix uses an /etc/init.d script like sendmail does on 14.10,
check to see what the "Provides:" part of the INIT INFO is (probably
postfix), and add an X-Start-Before line with tha value to the
spamassassin init script. Or, if you just want to make sure that SA
starts before monit, use whatever the "Provides:" is set to in the
monit init script.
If you have a mixture of SysV (regular) and upstart script, things get
more complicated (unless 16.10 introduces functionality to make
dependencies interoperable that doesn't exist in 14.10).
On Tue, 6 Dec 2016, Michael Heuberger wrote:
> Hi David
>
> I dont know. Not sure how I can find this out whether it does some
> DNS/network stuff.
>
> In my other response to John you can see that it takes about 5.69 sec to
> start spamassassin.
>
> And no idea how to configure a SA startup dependency on the network being up.
> And shouldn't that come along with the package when installed via apt-get?
>
> - Michael
>
>
> On 6/12/16 11:47, David B Funk wrote:
>>
>> Could it be some kind if interaction with other system services startup?
>> (in particular this feels like a network timeout issue).
>>
>> One of the things SA does during its startup process is check to see if
>> DNS/network stuff is available.
>> If the system hasn't yet brought up the network stack when SA starts, it
>> may hang waiting for the network to stabilize.
>>
>> On a running system, if you stop/restart SA do you see the same delay or
>> is it only on a cold start of the system?
>>
>> Is it possible to configure a SA starup dependency on the network being
>> up?
>>
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Hi David
I dont know. Not sure how I can find this out whether it does some
DNS/network stuff.
In my other response to John you can see that it takes about 5.69 sec to
start spamassassin.
And no idea how to configure a SA startup dependency on the network
being up. And shouldn't that come along with the package when installed
via apt-get?
- Michael
On 6/12/16 11:47, David B Funk wrote:
>
> Could it be some kind if interaction with other system services startup?
> (in particular this feels like a network timeout issue).
>
> One of the things SA does during its startup process is check to see
> if DNS/network stuff is available.
> If the system hasn't yet brought up the network stack when SA starts,
> it may hang waiting for the network to stabilize.
>
> On a running system, if you stop/restart SA do you see the same delay
> or is it only on a cold start of the system?
>
> Is it possible to configure a SA starup dependency on the network
> being up?
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 6 Dec 2016, Michael Heuberger wrote:
> Anyone?
>
>
> On 23/11/16 16:11, Michael Heuberger wrote:
>> Hello folks
>>
>> New here :)
>>
>> I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10 server
>> together with Monit (and Postfix of course). Each time server restarts,
>> Monit says first that the spamd process is not running (no PID) but in
>> three minutes later it says the opposite, that it is back up running.
>>
>> There is the /etc/init.d/spamassassin file that boots Spamassassin on
>> start. But somehow it does not seem to get executed asap but 3 mins later.
>> No idea why.
>>
>> The PID under /var/run/spamassassin.pid is owned by root and is monitored
>> under Monit with these configs:
>>
>> # (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
>> $ cat spamassassin
>> check process spamd with pidfile /var/run/spamassassin.pid
>> group mail
>> start program = "/etc/init.d/spamassassin start" with timeout 180
>> seconds
>> stop program = "/etc/init.d/spamassassin stop"
>> if 5 restarts within 5 cycles then timeout
>> if cpu usage > 79% for 5 cycles then alert
>> if mem usage > 79% for 5 cycles then alert
>> depends on spamd_bin
>> depends on spamd_rc
>>
>> check file spamd_rc with path /etc/init.d/spamassassin
>> group mail
>> if failed checksum then unmonitor
>> if failed permission 755 then unmonitor
>> if failed uid root then unmonitor
>> if failed gid root then unmonitor
>>
>> check file spamd_bin with path /usr/sbin/spamd
>> group mail
>> if failed checksum then unmonitor
>> if failed permission 755 then unmonitor
>> if failed uid root then unmonitor
>> if failed gid root then unmonitor
>>
>> Not sure what the problem is here. Could be one of these:
>> - a bug in /etc/init.d/spamassassin?
>> - a bad config in the above monit config
>> - something in postfix or another lib blocking spamassassin
>>
>> No idea how to investigate. And there is no spamassassin log showing how it
>> starts up.
>>
>> Any clues welcome
>>
>> Cheers
>> Michael
Could it be some kind if interaction with other system services startup?
(in particular this feels like a network timeout issue).
One of the things SA does during its startup process is check to see if
DNS/network stuff is available.
If the system hasn't yet brought up the network stack when SA starts, it may
hang waiting for the network to stabilize.
On a running system, if you stop/restart SA do you see the same delay or is
it only on a cold start of the system?
Is it possible to configure a SA starup dependency on the network being up?
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Thanks John for the commands. Here the results
michael.heuberger@binarykitchen /v/log \u276f\u276f\u276f sudo time
/etc/init.d/spamassassin start \u23ce
Starting spamassassin (via systemctl): spamassassin.service.
0.00user 0.00system 0:05.69elapsed 0%CPU (0avgtext+0avgdata
4904maxresident)k
0inputs+0outputs (0major+1844minor)pagefaults 0swaps
Hope this helps investigating my problem?
On 6/12/16 14:42, John Hardin wrote:
> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>
>> Thanks John
>>
>> What commands would you use for shutting down SA properly and to
>> time-measure its restart procedure?
>
> Hrm. Based on the start/stop commands in what you pasted earlier:
>
> /etc/init.d/spamassassin stop
> time /etc/init.d/spamassassin start
>
>
>> - Michael
>>
>>
>> On 6/12/16 11:15, John Hardin wrote:
>>> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>>>
>>> > Anyone?
>>>
>>> If you shut down SA and run the /etc/init.d/spamassassin script to
>>> restart
>>> it, how long does that take to complete?
>>>
>>> Is there something like a rules recompile built into that?
>>>
>>>
>>> > On 23/11/16 16:11, Michael Heuberger wrote:
>>> > > Hello folks
>>> > > > > New here :)
>>> > > > > I'm running Spamassassin v3.4.1 here on an headless Ubuntu
>>> 16.10 > > server
>>> > > together with Monit (and Postfix of course). Each time server >
>>> > restarts,
>>> > > Monit says first that the spamd process is not running (no
>>> PID) but > > in
>>> > > three minutes later it says the opposite, that it is back up
>>> running.
>>> > > > > There is the /etc/init.d/spamassassin file that boots
>>> Spamassassin on
>>> > > start. But somehow it does not seem to get executed asap but 3
>>> mins > > later.
>>> > > No idea why.
>>> > > > > The PID under /var/run/spamassassin.pid is owned by root
>>> and is > > monitored
>>> > > under Monit with these configs:
>>> > > > > # (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
>>> > > $ cat spamassassin
>>> > > check process spamd with pidfile /var/run/spamassassin.pid
>>> > > group mail
>>> > > start program = "/etc/init.d/spamassassin start" with
>>> timeout 180
>>> > > seconds
>>> > > stop program = "/etc/init.d/spamassassin stop"
>>> > > if 5 restarts within 5 cycles then timeout
>>> > > if cpu usage > 79% for 5 cycles then alert
>>> > > if mem usage > 79% for 5 cycles then alert
>>> > > depends on spamd_bin
>>> > > depends on spamd_rc
>>> > > > > check file spamd_rc with path /etc/init.d/spamassassin
>>> > > group mail
>>> > > if failed checksum then unmonitor
>>> > > if failed permission 755 then unmonitor
>>> > > if failed uid root then unmonitor
>>> > > if failed gid root then unmonitor
>>> > > > > check file spamd_bin with path /usr/sbin/spamd
>>> > > group mail
>>> > > if failed checksum then unmonitor
>>> > > if failed permission 755 then unmonitor
>>> > > if failed uid root then unmonitor
>>> > > if failed gid root then unmonitor
>>> > > > > Not sure what the problem is here. Could be one of these:
>>> > > - a bug in /etc/init.d/spamassassin?
>>> > > - a bad config in the above monit config
>>> > > - something in postfix or another lib blocking spamassassin
>>> > > > > No idea how to investigate. And there is no spamassassin
>>> log showing > > how
>>> > > it starts up.
>>> > > > > Any clues welcome
>>>
>>
>> --
>>
>> Binary Kitchen
>> Michael Heuberger
>> 1/33 Parrish Road
>> Sandringham
>> Auckland 1025
>> (New Zealand)
>>
>> Mobile (text only) ... +64 21 261 89 81
>> Email ................ michael@binarykitchen.com
>> Website .............. http://www.binarykitchen.com
>>
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by John Hardin <jh...@impsec.org>.
On Tue, 6 Dec 2016, Michael Heuberger wrote:
> Thanks John
>
> What commands would you use for shutting down SA properly and to time-measure
> its restart procedure?
Hrm. Based on the start/stop commands in what you pasted earlier:
/etc/init.d/spamassassin stop
time /etc/init.d/spamassassin start
> - Michael
>
>
> On 6/12/16 11:15, John Hardin wrote:
>> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>>
>> > Anyone?
>>
>> If you shut down SA and run the /etc/init.d/spamassassin script to restart
>> it, how long does that take to complete?
>>
>> Is there something like a rules recompile built into that?
>>
>>
>> > On 23/11/16 16:11, Michael Heuberger wrote:
>> > > Hello folks
>> > >
>> > > New here :)
>> > >
>> > > I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10
>> > > server
>> > > together with Monit (and Postfix of course). Each time server
>> > > restarts,
>> > > Monit says first that the spamd process is not running (no PID) but
>> > > in
>> > > three minutes later it says the opposite, that it is back up running.
>> > >
>> > > There is the /etc/init.d/spamassassin file that boots Spamassassin on
>> > > start. But somehow it does not seem to get executed asap but 3 mins
>> > > later.
>> > > No idea why.
>> > >
>> > > The PID under /var/run/spamassassin.pid is owned by root and is
>> > > monitored
>> > > under Monit with these configs:
>> > >
>> > > # (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
>> > > $ cat spamassassin
>> > > check process spamd with pidfile /var/run/spamassassin.pid
>> > > group mail
>> > > start program = "/etc/init.d/spamassassin start" with timeout 180
>> > > seconds
>> > > stop program = "/etc/init.d/spamassassin stop"
>> > > if 5 restarts within 5 cycles then timeout
>> > > if cpu usage > 79% for 5 cycles then alert
>> > > if mem usage > 79% for 5 cycles then alert
>> > > depends on spamd_bin
>> > > depends on spamd_rc
>> > >
>> > > check file spamd_rc with path /etc/init.d/spamassassin
>> > > group mail
>> > > if failed checksum then unmonitor
>> > > if failed permission 755 then unmonitor
>> > > if failed uid root then unmonitor
>> > > if failed gid root then unmonitor
>> > >
>> > > check file spamd_bin with path /usr/sbin/spamd
>> > > group mail
>> > > if failed checksum then unmonitor
>> > > if failed permission 755 then unmonitor
>> > > if failed uid root then unmonitor
>> > > if failed gid root then unmonitor
>> > >
>> > > Not sure what the problem is here. Could be one of these:
>> > > - a bug in /etc/init.d/spamassassin?
>> > > - a bad config in the above monit config
>> > > - something in postfix or another lib blocking spamassassin
>> > >
>> > > No idea how to investigate. And there is no spamassassin log showing
>> > > how
>> > > it starts up.
>> > >
>> > > Any clues welcome
>>
>
> --
>
> Binary Kitchen
> Michael Heuberger
> 1/33 Parrish Road
> Sandringham
> Auckland 1025
> (New Zealand)
>
> Mobile (text only) ... +64 21 261 89 81
> Email ................ michael@binarykitchen.com
> Website .............. http://www.binarykitchen.com
>
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Our government wants to do everything it can "for the children,"
except sparing them crushing tax burdens.
-----------------------------------------------------------------------
10 days until Bill of Rights day
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Thanks John
What commands would you use for shutting down SA properly and to
time-measure its restart procedure?
- Michael
On 6/12/16 11:15, John Hardin wrote:
> On Tue, 6 Dec 2016, Michael Heuberger wrote:
>
>> Anyone?
>
> If you shut down SA and run the /etc/init.d/spamassassin script to
> restart it, how long does that take to complete?
>
> Is there something like a rules recompile built into that?
>
>
>> On 23/11/16 16:11, Michael Heuberger wrote:
>>> Hello folks
>>>
>>> New here :)
>>>
>>> I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10
>>> server
>>> together with Monit (and Postfix of course). Each time server
>>> restarts,
>>> Monit says first that the spamd process is not running (no PID) but in
>>> three minutes later it says the opposite, that it is back up running.
>>>
>>> There is the /etc/init.d/spamassassin file that boots Spamassassin on
>>> start. But somehow it does not seem to get executed asap but 3 mins
>>> later.
>>> No idea why.
>>>
>>> The PID under /var/run/spamassassin.pid is owned by root and is
>>> monitored
>>> under Monit with these configs:
>>>
>>> # (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
>>> $ cat spamassassin
>>> check process spamd with pidfile /var/run/spamassassin.pid
>>> group mail
>>> start program = "/etc/init.d/spamassassin start" with timeout 180
>>> seconds
>>> stop program = "/etc/init.d/spamassassin stop"
>>> if 5 restarts within 5 cycles then timeout
>>> if cpu usage > 79% for 5 cycles then alert
>>> if mem usage > 79% for 5 cycles then alert
>>> depends on spamd_bin
>>> depends on spamd_rc
>>>
>>> check file spamd_rc with path /etc/init.d/spamassassin
>>> group mail
>>> if failed checksum then unmonitor
>>> if failed permission 755 then unmonitor
>>> if failed uid root then unmonitor
>>> if failed gid root then unmonitor
>>>
>>> check file spamd_bin with path /usr/sbin/spamd
>>> group mail
>>> if failed checksum then unmonitor
>>> if failed permission 755 then unmonitor
>>> if failed uid root then unmonitor
>>> if failed gid root then unmonitor
>>>
>>> Not sure what the problem is here. Could be one of these:
>>> - a bug in /etc/init.d/spamassassin?
>>> - a bad config in the above monit config
>>> - something in postfix or another lib blocking spamassassin
>>>
>>> No idea how to investigate. And there is no spamassassin log
>>> showing how
>>> it starts up.
>>>
>>> Any clues welcome
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by John Hardin <jh...@impsec.org>.
On Tue, 6 Dec 2016, Michael Heuberger wrote:
> Anyone?
If you shut down SA and run the /etc/init.d/spamassassin script to restart
it, how long does that take to complete?
Is there something like a rules recompile built into that?
> On 23/11/16 16:11, Michael Heuberger wrote:
>> Hello folks
>>
>> New here :)
>>
>> I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10 server
>> together with Monit (and Postfix of course). Each time server restarts,
>> Monit says first that the spamd process is not running (no PID) but in
>> three minutes later it says the opposite, that it is back up running.
>>
>> There is the /etc/init.d/spamassassin file that boots Spamassassin on
>> start. But somehow it does not seem to get executed asap but 3 mins later.
>> No idea why.
>>
>> The PID under /var/run/spamassassin.pid is owned by root and is monitored
>> under Monit with these configs:
>>
>> # (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
>> $ cat spamassassin
>> check process spamd with pidfile /var/run/spamassassin.pid
>> group mail
>> start program = "/etc/init.d/spamassassin start" with timeout 180
>> seconds
>> stop program = "/etc/init.d/spamassassin stop"
>> if 5 restarts within 5 cycles then timeout
>> if cpu usage > 79% for 5 cycles then alert
>> if mem usage > 79% for 5 cycles then alert
>> depends on spamd_bin
>> depends on spamd_rc
>>
>> check file spamd_rc with path /etc/init.d/spamassassin
>> group mail
>> if failed checksum then unmonitor
>> if failed permission 755 then unmonitor
>> if failed uid root then unmonitor
>> if failed gid root then unmonitor
>>
>> check file spamd_bin with path /usr/sbin/spamd
>> group mail
>> if failed checksum then unmonitor
>> if failed permission 755 then unmonitor
>> if failed uid root then unmonitor
>> if failed gid root then unmonitor
>>
>> Not sure what the problem is here. Could be one of these:
>> - a bug in /etc/init.d/spamassassin?
>> - a bad config in the above monit config
>> - something in postfix or another lib blocking spamassassin
>>
>> No idea how to investigate. And there is no spamassassin log showing how
>> it starts up.
>>
>> Any clues welcome
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
You do not examine legislation in the light of the benefits it
will convey if properly administered, but in the light of the
wrongs it would do and the harms it would cause if improperly
administered. -- Lyndon B. Johnson
-----------------------------------------------------------------------
10 days until Bill of Rights day
Re: Weird Spamassassin startup behaviour on Ubuntu 16.10
Posted by Michael Heuberger <mi...@binarykitchen.com>.
Anyone?
On 23/11/16 16:11, Michael Heuberger wrote:
> Hello folks
>
> New here :)
>
> I'm running Spamassassin v3.4.1 here on an headless Ubuntu 16.10
> server together with Monit (and Postfix of course). Each time server
> restarts, Monit says first that the spamd process is not running (no
> PID) but in three minutes later it says the opposite, that it is back
> up running.
>
> There is the /etc/init.d/spamassassin file that boots Spamassassin on
> start. But somehow it does not seem to get executed asap but 3 mins
> later. No idea why.
>
> The PID under /var/run/spamassassin.pid is owned by root and is
> monitored under Monit with these configs:
>
> # (hidden) @ (hidden) in /etc/monit/conf.d [14:00:04] C:1
> $ cat spamassassin
> check process spamd with pidfile /var/run/spamassassin.pid
> group mail
> start program = "/etc/init.d/spamassassin start" with timeout 180
> seconds
> stop program = "/etc/init.d/spamassassin stop"
> if 5 restarts within 5 cycles then timeout
> if cpu usage > 79% for 5 cycles then alert
> if mem usage > 79% for 5 cycles then alert
> depends on spamd_bin
> depends on spamd_rc
>
> check file spamd_rc with path /etc/init.d/spamassassin
> group mail
> if failed checksum then unmonitor
> if failed permission 755 then unmonitor
> if failed uid root then unmonitor
> if failed gid root then unmonitor
>
> check file spamd_bin with path /usr/sbin/spamd
> group mail
> if failed checksum then unmonitor
> if failed permission 755 then unmonitor
> if failed uid root then unmonitor
> if failed gid root then unmonitor
>
> Not sure what the problem is here. Could be one of these:
> - a bug in /etc/init.d/spamassassin?
> - a bad config in the above monit config
> - something in postfix or another lib blocking spamassassin
>
> No idea how to investigate. And there is no spamassassin log showing
> how it starts up.
>
> Any clues welcome
>
> Cheers
> Michael
>
--
Binary Kitchen
Michael Heuberger
1/33 Parrish Road
Sandringham
Auckland 1025
(New Zealand)
Mobile (text only) ... +64 21 261 89 81
Email ................ michael@binarykitchen.com
Website .............. http://www.binarykitchen.com