You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Rosenbaum, Larry M." <ro...@ornl.gov> on 2005/03/21 21:03:19 UTC

spamd doesn't use syslog after reboot on Solaris 9

SpamAssassin v3.0.2, Perl 5.8.5 on Solaris 9
SunOS spam2 5.9 Generic_118558-02 sun4u sparc SUNW,Ultra-4

We recently installed SpamAssassin 3.0.2 on a Solaris 9 system.  We are
starting spamd from /etc/rc2.d so that it starts up AFTER the syslog
daemon starts, using the following switches (among others):
  --syslog=local2 --syslog-socket=inet

However, after a reboot, spamd doesn't send messages to syslog, and if I
capture the output from the spamd startup, I see the following errors:

getservbyname failed for tcp at /usr/local/bin/spamd line 1746
udp connect: nobody listening at /usr/local/bin/spamd line 1746
failed to setlogsock(inet): no connection to syslog available at
/usr/local/bin/spamd line 1746
reporting logs to stderr


Restarting spamd will make it start using syslog properly.  This problem
does not occur with a similar setup on a Solaris 6 system.  Any idea
what is causing the problem?

Thanks, Larry


Re: spamd doesn't use syslog after reboot on Solaris 9

Posted by Richard Hopkins <Ri...@bristol.ac.uk>.

--On Monday, March 21, 2005 3:03 PM -0500 "Rosenbaum, Larry M." 
<ro...@ornl.gov> wrote:

> SpamAssassin v3.0.2, Perl 5.8.5 on Solaris 9
> SunOS spam2 5.9 Generic_118558-02 sun4u sparc SUNW,Ultra-4
>
> We recently installed SpamAssassin 3.0.2 on a Solaris 9 system.  We are
> starting spamd from /etc/rc2.d so that it starts up AFTER the syslog
> daemon starts, using the following switches (among others):
>   --syslog=local2 --syslog-socket=inet
>
> However, after a reboot, spamd doesn't send messages to syslog, and if I
> capture the output from the spamd startup, I see the following errors:
>
> getservbyname failed for tcp at /usr/local/bin/spamd line 1746
> udp connect: nobody listening at /usr/local/bin/spamd line 1746
> failed to setlogsock(inet): no connection to syslog available at
> /usr/local/bin/spamd line 1746
> reporting logs to stderr
>
>
> Restarting spamd will make it start using syslog properly.  This problem
> does not occur with a similar setup on a Solaris 6 system.  Any idea
> what is causing the problem?
>

I've also been bitten by this (Solaris 8 as well, by the way). I have a 
strong suspicion that when it happens, not only does logging not happen but 
some tests are also not run by SpamAssassin. We had to reboot our primary 
external mail hub on Monday and since then the amount of false negatives 
went through the roof (comparatively). Restarting spamd seems to have fixed 
this (as well as the logging issue).

I've moved my spamd startup from /etc/rc2.d/S78spamd to /etc/rc2.d/S98spamd 
(with my MTA startup at S99 and syslogd remaining at S74) and all now seems 
well.

Cheers,

Richard Hopkins,
Information Services,
Computer Centre,
University of Bristol,
Bristol, BS8 1UD, UK

Tel +44 117 928 7859
Fax +44 117 929 1576


Re: spamd doesn't use syslog after reboot on Solaris 9

Posted by Matt Kettler <mk...@evi-inc.com>.
Rosenbaum, Larry M. wrote:

>SpamAssassin v3.0.2, Perl 5.8.5 on Solaris 9
>SunOS spam2 5.9 Generic_118558-02 sun4u sparc SUNW,Ultra-4
>
>We recently installed SpamAssassin 3.0.2 on a Solaris 9 system.  We are
>starting spamd from /etc/rc2.d so that it starts up AFTER the syslog
>daemon starts, using the following switches (among others):
>  --syslog=local2 --syslog-socket=inet
>
>However, after a reboot, spamd doesn't send messages to syslog, and if I
>capture the output from the spamd startup, I see the following errors:
>
>getservbyname failed for tcp at /usr/local/bin/spamd line 1746
>udp connect: nobody listening at /usr/local/bin/spamd line 1746
>failed to setlogsock(inet): no connection to syslog available at
>/usr/local/bin/spamd line 1746
>reporting logs to stderr
>
>
>Restarting spamd will make it start using syslog properly.  This problem
>does not occur with a similar setup on a Solaris 6 system.  Any idea
>what is causing the problem?
>

The fact that getservbyname failed sounds like you're starting spamd
very early in your boot process and really basic things like service
name resolution (against /etc/services) haven't been started.

Are all your network interfaces up and running before spamd is started?