Hi

same problem here, each time a mail is sent to spamd to be checked, I can see some dns requests taking quite some time before time out. This usually adds 6-8 seconds of time out to check 1 mail, which can slow down things a lot when you have hundreds of mail to check.

eg :

Tue Nov 24 17:04:02 2015 [2138] warn:  (available_nameservers: [...] No DNS servers available!)
Tue Nov 24 17:04:03 2015 [2138] warn: spf: lookup failed: available_nameservers: No DNS servers available!
Tue Nov 24 17:04:07 2015 [2138] warn: spf: lookup failed: available_nameservers: No DNS servers available!

Nicolas

CC: (none) => npomarede

There is an upstream patch which fixes this problem, see:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7057

The latest version of spamassassin (as of 2015-04-30) is 3.4.1
which should include the fix.

A workaround is to add a dns_server entry to the file
/etc/mail/spamassassin/local.cf

I used:

dns_server 8.8.8.8

CC: (none) => martin

Updated package uploaded by Oden (thanks!).

Please test the updated packages and report if they fix the issue (and which architecture you tested).

Advisory:
----------------------------------------

The spamassassin package has been updated to version 3.4.1 to fix an
incompatibility with the perl Net::DNS module.

References:
http://spamassassin.apache.org/news.html
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7057
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
spamassassin-3.4.1-1.mga5
spamassassin-sa-compile-3.4.1-1.mga5
spamassassin-tools-3.4.1-1.mga5
spamassassin-spamd-3.4.1-1.mga5
spamassassin-spamc-3.4.1-1.mga5
perl-Mail-SpamAssassin-3.4.1-1.mga5
perl-Mail-SpamAssassin-Spamd-3.4.1-1.mga5

from spamassassin-3.4.1-1.mga5.src.rpm

CC: (none) => oe, remco
Assignee: remco => qa-bugs

Update to 3.4.1 done, but no luck so far.

When I run "systemctl start spamd.service", I get this error after 1 minute :
Job for spamd.service failed. See "systemctl status spamd.service" and "journalctl -xe" for details.

systemctl status spamd.service
â spamd.service - Spamassassin daemon
   Loaded: loaded (/usr/lib/systemd/system/spamd.service; enabled)
   Active: failed (Result: timeout) since jeu. 2016-03-03 16:34:49 CET; 11s ago
  Process: 29578 ExecStart=/usr/bin/spamd --pidfile /run/spamd.pid $SPAMDOPTIONS (code=killed, signal=TERM)
 Main PID: 1787 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/spamd.service

mars 03 16:34:49 pulsar systemd[1]: spamd.service start operation timed out. Terminating.
mars 03 16:34:49 pulsar systemd[1]: Failed to start Spamassassin daemon.
mars 03 16:34:49 pulsar systemd[1]: Unit spamd.service entered failed state.
mars 03 16:34:49 pulsar systemd[1]: spamd.service failed.

in /var/log/spamassassin/spamd.log, I get this :

Thu Mar  3 16:33:20 2016 [29580] warn: config: configuration file "/usr/share/spamassassin/20_porn.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at /usr/lib/perl5/vendor_perl/5.20.1/Mail/SpamAssassin/Conf/Parser.pm line 406.
Thu Mar  3 16:33:20 2016 [29580] info: config: configuration file "/usr/share/spamassassin/20_porn.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file
Thu Mar  3 16:33:20 2016 [29580] warn: config: configuration file "/usr/share/spamassassin/20_uri_tests.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at /usr/lib/perl5/vendor_perl/5.20.1/Mail/SpamAssassin/Conf/Parser.pm line 406.
Thu Mar  3 16:33:20 2016 [29580] info: config: configuration file "/usr/share/spamassassin/20_uri_tests.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file
Thu Mar  3 16:33:20 2016 [29580] warn: config: configuration file "/usr/share/spamassassin/23_bayes.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at /usr/lib/perl5/vendor_perl/5.20.1/Mail/SpamAssassin/Conf/Parser.pm line 406.
Thu Mar  3 16:33:20 2016 [29580] info: config: configuration file "/usr/share/spamassassin/23_bayes.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file
Thu Mar  3 16:33:20 2016 [29580] warn: config: configuration file "/usr/share/spamassassin/72_active.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at /usr/lib/perl5/vendor_perl/5.20.1/Mail/SpamAssassin/Conf/Parser.pm line 406.
Thu Mar  3 16:33:20 2016 [29580] info: config: configuration file "/usr/share/spamassassin/72_active.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file
Thu Mar  3 16:33:20 2016 [29580] warn: config: configuration file "/usr/share/spamassassin/73_sandbox_manual_scores.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file at /usr/lib/perl5/vendor_perl/5.20.1/Mail/SpamAssassin/Conf/Parser.pm line 406.
Thu Mar  3 16:33:20 2016 [29580] info: config: configuration file "/usr/share/spamassassin/73_sandbox_manual_scores.cf" requires version 3.004000 of SpamAssassin, but this is code version 3.004001. Maybe you need to use the -C switch, or remove the old config files? Skipping this file


Thu Mar  3 16:34:49 2016 [29580] info: spamd: server killed by SIGTERM, shutting down
Thu Mar  3 16:34:49 2016 [29580] warn: spamd: cannot unlink /run/spamd.pid: No such file or directory

I think the warning about old rule files might be harmless ; apart from that, the cause of failure is not shown.

Still, we can see that the pid file is not in its correct location ; shouldn't it be /run/spamd/spamd.pid ?

The following processes are running when I start spamd.service :

root     29812  0.0  0.0   7472  1028 pts/4    S+   16:41   0:00 systemctl start spamd.service
root     29814 13.0  0.4  22496 18576 ?        Ss   16:41   0:00 /usr/bin/spamd --pidfile /run/spamd.pid -d -c -m5 -H --syslog=/var/log/spamassassin/spamd.log --listen=/run/spamd/spamd.socket --listen=:783
root     29816 19.0  0.7  38572 31416 ?        Ss   16:41   0:00 /usr/bin/spamd --pidfile /run/spamd.pid -d -c -m5 -H --syslog=/var/log/spamassassin/spamd.log --listen=/run/spamd/spamd.socket --listen=:783


If I strace -p 29816, I can see it timeouts while trying to connect to DNS on port 53 for ipv6/ipv4 :

strace -p 29816
Process 29816 attached
select(16, [8 9], NULL, NULL, {7, 607501}

) = 0 (Timeout)
time(NULL)                              = 1457019725
getpeername(8, 0xa0e73f8, [256])        = -1 ENOTCONN (Transport endpoint is not connected)
sendto(8, "T{\1\0\0\1\0\0\0\0\0\0\1#\5iliad\5local\0\0\1\0\1", 31, 0, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 31
time(NULL)                              = 1457019725
time(NULL)                              = 1457019725
select(16, [8 9], NULL, NULL, {10, 0})  = 0 (Timeout)
time(NULL)                              = 1457019735
select(16, [8 9], NULL, NULL, {10, 0})  = 0 (Timeout)
time(NULL)                              = 1457019745
getpeername(9, 0xa0e73f8, [256])        = -1 ENOTCONN (Transport endpoint is not connected)
sendto(9, "T{\1\0\0\1\0\0\0\0\0\0\1#\5iliad\5local\0\0\1\0\1", 31, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 31
time(NULL)                              = 1457019745
time(NULL)                              = 1457019745


So, I don't see any improvement with this version 3.4.1 ; this is with mga5 i586 mode (32 bits)

Seems I found where the problem comes from : I'm using a VPN at work, started with ppp.
When the vpn is not started, my /etc/resolv.conf file is :

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.100.11
nameserver 192.168.100.26
nameserver 192.168.100.12
search perso.local

With this resolv.conf, spamd starts correctly.

Once the vpn is started (using interface ppp0),
 /etc/resolv.conf becomes :

nameserver 192.168.100.11
nameserver 192.168.100.26
nameserver 192.168.100.12
search perso.local
nameserver 172.18.25.200 # ppp temp entry
nameserver 172.18.25.200 # ppp temp entry

At this point, spamd service will timeout when trying to resolv DNS. But as far as I know, nameserver are used from top to bottom in /etc/resolv.conf. Here, it seems spamassasin / perl-Net-DNS-0.770.0-4.mga5 will use 172.18.25.200, but this server is local to the vpn and can't resolv public domainname.

Is this a known problem in perl-Net-DNS-0.770.0-4.mga5 ?

@Nicolas, I think this is not a new/known problem as of this perl-Net-DNS version. That said, it might be a bug indeed in perl-Net-DNS that needs to be reported if indeed it uses the last nameserver of the list instead of the first. If you wish to report this, please do so at https://rt.cpan.org/Public/Dist/Display.html?Name=Net-DNS

That said, your changes with VPN made to /etc/resolv.conf seem buggy too. According to the man page of resolv.conf, it will store only up to 3 nameservers, you have 5, of which two are identical to each other.

I think your problem is a genuine one, but not addressed in this update. In situations with a valid /etc/resolv.conf and nameservers capable of resolving queries, this update should lead to an improvement over the existing situation with the old package.

@oden, many thanks for updating this package!

Guys as you use this package, can you verify the fix please as per the advisory in comment 3. Thanks.

@Remco, I agree resolv.conf contains too many entries, but as each vpn using ppp might get 2 DNS entries returned by the vpn server, you might end up with many entries, some of them might not be used, as resolver should use nameserver from top to bottom when reading resolv.conf. At least, this used to work under mga4, so maybe Net::DNS changed it's behaviour with recent version.

I made several tests by mixing 2 nameservers in resolv.conf ; 192.168.100.11 is a working dns, 172.18.25.200 is a non working dns (from the vpn).
Whatever combination / order I try, spamd will never start :

nameserver 192.168.100.11
nameserver 172.18.25.200
nameserver 192.168.100.11

or 
nameserver 172.18.25.200
nameserver 192.168.100.11

or
nameserver 192.168.100.11
nameserver 172.18.25.200

Only working case is when 172.18.25.200 is not in resolv.conf

So, my conclusion would be that order does not matter, but that Net::DNS (or spamassassin ?) try all the nameserver entries at once, instead of trying the 1st one, then trying the 2nd one only if 1st one timeouts and so on.

This looks like a bug to me, at least it's not consistent with the usual resolver behaviour ; or maybe there's an option to disable this and only use them one after the other ?

OK, found the problem :)
I used dig @172.18.25.200, and it turns out that this vpn dns is responding, so the problem is not there, the problem is that when ppp adds the DNS entries to resolv.conf, a comment is added :

nameserver 172.18.25.200 # ppp temp entry

If I remove the comment, then spamd starts correctly.

And as reported here too, comments are not handled in Net::DNS 0.777 : https://lists.freebsd.org/pipermail/freebsd-ports/2014-June/093630.html

A patch was proposed, which was included in Net::DNS 0.78

Looking at the changelog http://cpansearch.perl.org/src/NLNETLABS/Net-DNS-0.78/Changes, it would seem safe to upgrade mga5 / cauldron to use version 0.78 which is a bugfix version.

This is assigned to QA but doesn't seem QA ready. 

Is there a need for this update?

Hi

I think the update was needed, because in all cases spamassasin 3.4.0 was reported in several distribs as being not compatible with perl net dns 0.77 that is shipped with mga5 and that uses a different API. This was fixed in 3.4.1

Now, it seems there's a second problem that affects net dns 0.77 and that was fixed in 0.78. So, an update of net::dns to at least 0.78 would be needed too (latest maintenance version is net::dns 0.83)

Adding feedback marker then until a complete resolution is decided.

Whiteboard: (none) => feedback

CC'ing packagers who have worked on perl-Net-DNS.

CC: (none) => jquelin, mageia, shlomif

(In reply to Nicolas Pomarède from comment #11)
> Hi
> 
> I think the update was needed, because in all cases spamassasin 3.4.0 was
> reported in several distribs as being not compatible with perl net dns 0.77
> that is shipped with mga5 and that uses a different API. This was fixed in
> 3.4.1
> 
> Now, it seems there's a second problem that affects net dns 0.77 and that
> was fixed in 0.78. So, an update of net::dns to at least 0.78 would be
> needed too (latest maintenance version is net::dns 0.83)

perl-Net-DNS-0.830.0-1.mga5 was submitted to mga v5 core/updates_testing .

Just updated to perl-Net-DNS-0.830.0-1.mga5 and I confirm this fixes the problem of the comments in /etc/resolv.conf.
spamd now starts correctly and after receiving a few mails, they were correctly sorted as spam or not.

So, these 2 updates of spamassassin-3.4.1-1.mga5 and perl-Net-DNS-0.830.0-1.mga5 fixes the issues I had with spam assassin after upgrading from mga4 to mga5. I think this bug report can be closed as "resolved".

(In reply to Nicolas Pomarède from comment #15)
> Just updated to perl-Net-DNS-0.830.0-1.mga5 and I confirm this fixes the
> problem of the comments in /etc/resolv.conf.
> spamd now starts correctly and after receiving a few mails, they were
> correctly sorted as spam or not.
> 
> So, these 2 updates of spamassassin-3.4.1-1.mga5 and
> perl-Net-DNS-0.830.0-1.mga5 fixes the issues I had with spam assassin after
> upgrading from mga4 to mga5. I think this bug report can be closed as
> "resolved".

Before we do this, shouldn't the updates be propagated from core/updates_testing to core/updates (possibly with an advisory)?

Yes (Absolutely with an advisory). Should all know how updates work by now..

I guess I have to do everything around here :o)

SRPMS:
perl-Net-DNS-0.830.0-1.mga5.src.rpm
spamassassin-3.4.1-1.mga5.src.rpm

Advisory:
----------------------------------------

The spamassassin package has been updated to version 3.4.1 to fix an
incompatibility with the perl Net::DNS module.

The perl-Net-DNS package has also been updated to version 0.83 to fix some
bugs which affect its usage with spamassassin.

References:
http://spamassassin.apache.org/news.html
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7057
https://www.net-dns.org/blog/2015/02/26/netdns-0-83-released/

Whiteboard: feedback => MGA5-32-OK

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2016-0036.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

The perl-Net-DNS update was not shipped.  Please add it to the advisory in SVN and push the package.  The advisory should appear as in Comment 18.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Sorry, I missed that there was an updated advisory. Now added to the advisory
in svn 16308.adv. I'm not sure if that can be pushed or if we need to open
a new bug report for it.

It doesn't need a new bug, it'll get pushed when the sysadmins get to it.

The script is upset about it because 5/core/spamassassin-3.4.1-1.mga5 is gone from testing, I'll manually run things later.

CC: (none) => pterjan

Package manually moved:

$ mga-adv-move-pkg --sync 5/core/perl-Net-DNS
The following SRPMs (and their corresponding binaries) will be moved:
- perl-Net-DNS-0.830.0-1.mga5.src.rpm

Are you sure? [Y/n] 

Moving binary and source rpms:
- i586:
    perl-Net-DNS-0.830.0-1.mga5.i586.rpm
    perl-Net-DNS-debuginfo-0.830.0-1.mga5.i586.rpm
- x86_64:
    perl-Net-DNS-0.830.0-1.mga5.x86_64.rpm
    perl-Net-DNS-debuginfo-0.830.0-1.mga5.x86_64.rpm
- source:
    perl-Net-DNS-0.830.0-1.mga5.src.rpm

I don't know why the advisory did not get updated on the website.

I'm seeing a number of rules being skipped now (17 out of 56, 30%) due to the newer version of spamassassin, just like Nicolas Pomarède shows in comment #4. This is a bit worrying. Seems like a newer version of spamassassin-rules is needed here?

CC: (none) => mageia824

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2016-0036.html

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED