connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused

I notice that every time i get a email i have one error reporting in "/var/log/maillog":

Jun 22 13:53:51 jenkins spamc[2802]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused

followed by next line:

Jun 22 13:53:51 jenkins spamd[20736]: spamd: connection from localhost.localdomain [127.0.0.1]:37294 to port 783, fd 5

It looks like spamassassin is working because i can see traces in email headers but this error start to be annoying so i try to figure out the solution:

Create the file "/etc/mail/spamassassin/spamc.conf" (this file is not present on Centos 7) and fill with:
-d 127.0.0.1

Before the fix:

Jul 12 13:59:16 jenkins spamc[2664]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection timed out
Jul 12 13:59:16 jenkins spamd[1242]: spamd: connection from localhost.localdomain [127.0.0.1]:33463 to port 783, fd 5
Jul 12 13:59:16 jenkins spamd[1242]: spamd: setuid to cunicellus succeeded
Jul 12 13:59:16 jenkins spamd[1242]: spamd: processing message <92b5f0bf-30fd-c457-c9de-1dde6a1cbdd4@gmail.com> for cunicellus:500
Jul 12 13:59:16 jenkins spamd[1242]: spamd: clean message (-0.1/5.0) for cunicellus:500 in 0.1 seconds, 3371 bytes.
Jul 12 13:59:16 jenkins spamd[1242]: spamd: result: . 0 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM scantime=0.1,size=3371,user=cunicellus,uid=500,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=33463,mid=<92b5f0bf-30fd-c457-c9de-1dde6a1cbdd4@gmail.com>,autolearn=ham autolearn_force=no

After i applied the fix:

Jul 12 14:12:53 jenkins spamd[3448]: spamd: connection from localhost.localdomain [127.0.0.1]:52115 to port 783, fd 5
Jul 12 14:12:53 jenkins spamd[3448]: spamd: setuid to cunicellus succeeded
Jul 12 14:12:53 jenkins spamd[3448]: spamd: processing message <8ab88152-03aa-c3b3-cb6b-3fd384f5c26c@gmail.com> for cunicellus:500
Jul 12 14:12:53 jenkins spamd[3448]: spamd: clean message (-0.1/5.0) for cunicellus:500 in 0.2 seconds, 3375 bytes.
Jul 12 14:12:53 jenkins spamd[3448]: spamd: result: . 0 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM scantime=0.2,size=3375,user=cunicellus,uid=500,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=52115,mid=<8ab88152-03aa-c3b3-cb6b-3fd384f5c26c@gmail.com>,autolearn=ham autolearn_force=no

For now it works and no more errors but i would like a confirmation from you guys. If i'm not mistaken ClamAV and spamassassin are pulled from Vmin repo and not sure if you changed spamassassin as you did with ClamAV.

(OpenVZ) Centos 7 / Vmin / Wmin / Umin ... all up to date.

Status: 
Active

Comments

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 08:31

Just to clarify in "Spam and Virus Scanning" i have selected:

  • spamc (Client for SpamAssassin filter server spamd)
  • server scanner (clamdscan)

Both are up and running regardless if the fix is applied or not.

Can you post the /etc/hosts file from your system? I suspect that localhost is mapping to an IPv6 address only.

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 08:57

127.0.0.1 localhost.localdomain localhost localhost4.localdomain4 localhost4
# Auto-generated hostname. Please do not remove this comment.
xxx.xxx.xxx.xxx jenkins.xxxxxxxx.com  jenkins
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

I'm pretty sure i disabled IPv6 from everywhere but looks like it stay in "/etc/hosts". Any suggestions?

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 08:59

Based on that error it could be that spamd is looking first at IPv6 and then proceed with IPv4? To be honest now i'm little confused.

Try commenting out the line :

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 09:41

Didnt help, the error still show up with every incoming email. Based on this link http://man.he.net/man1/spamassassin-run:

        --ipv4only, --ipv4-only, --ipv4
           Do not use IPv6 for DNS tests. Normally, SpamAssassin will try to
           detect if IPv6 is available, using only IPv4 if it is not. Use if
           the existing tests for IPv6 availability produce incorrect results
           or crashes.

So i try to add in "/etc/sysconfig/spamassassin" --ipv4only, --ipv4-only, --ipv4 but with same result.

This bug started with 3.4.0 when spamassassin introduced native IPv6 support. So far only solution that works is one mentioned in my first post, the rest do nothing.

Re-reading your initial post -- just a heads up that SpamAssassin comes from CentOS:

http://mirror.centos.org/centos/7/os/x86_64/Packages/spamassassin-3.4.0-...

ClamAV we do indeed provide, though we grabbed that from EPEL, and provide it essentially as-is (I believe -- I've asked Joe for more input there).

I'll look into whether anyone else has filed bugs with CentOS about that, I'm curious if others are seeing that same problem.

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 10:28

I'll look into whether anyone else has filed bugs with CentOS about that,

When i was looking for alternative solution i think i saw quite a lot people with same or similar problem so i'm sure someone filled bug report. For now i'm going back to my first solution but it would be nice if Joe can take a look and see if something else can be done.

I only asked Joe about ClamAV packaging details for CentOS. We hadn't run into the issue you're describing there with SpamAssassin, though I'll look deeper into that to see what we can figure out.

Out of curiosity, when not using the "-d" parameter you added, what does this command on your system show:

netstat -an | grep :783

On our CentOS 7 system here, that shows the following:

tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN    
tcp6       0      0 ::1:783                 :::*                    LISTEN 

Also, what is the output of "iptables -L -n"?

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 10:42

With ClamAV there are two bugs with Centos 7

  • Unable to start ClamAV from Vmin
  • ClamAV is not set to run after server reboot

First problem can be fixed by starting manually (SSH) ClamAV and second can be fixed to go in "Bootup and Shutdown" and change settings for ClamAV daemon. But Joe said this should be fixed with next Vmin version.

This problem is entirely connected with SpamAssassin and only today i notice this error. Looking at old logs it was present all the time.

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 10:50

[root@jenkins ~]# netstat -an | grep :783
tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN

Keep in mind that i applied my first solution so tcp6 will not show up.

[root@jenkins ~]# iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination
f2b-apache-livewhale  all  --  0.0.0.0/0            0.0.0.0/0
f2b-wordpress  all  --  0.0.0.0/0            0.0.0.0/0
f2b-postfix-sasl  all  --  0.0.0.0/0            0.0.0.0/0
f2b-dovecot  all  --  0.0.0.0/0            0.0.0.0/0
f2b-postfix-rbl  all  --  0.0.0.0/0            0.0.0.0/0
f2b-postfix  all  --  0.0.0.0/0            0.0.0.0/0
f2b-proftpd  all  --  0.0.0.0/0            0.0.0.0/0
f2b-webmin-auth  all  --  0.0.0.0/0            0.0.0.0/0
f2b-php-url-fopen  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-shellshock  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-fakegooglebot  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-botsearch  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-nohome  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-overflows  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-noscript  all  --  0.0.0.0/0            0.0.0.0/0
f2b-apache-badbots  all  --  0.0.0.0/0            0.0.0.0/0
f2b-sshd   all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp flags:0x10/0x10
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp XXXXXX
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 0 limit: avg 1/sec burst 1
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 3 limit: avg 1/sec burst 1
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 4 limit: avg 1/sec burst 1
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 11 limit: avg 1/sec burst 1
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 12 limit: avg 1/sec burst 1
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 1
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp XXXXXX
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:113
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,587
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp XXXXXX
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp multiport dports 110,995
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp multiport dports 143,220,993
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp XXXXXX
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp XXXXXX

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain f2b-apache-badbots (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-botsearch (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-fakegooglebot (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-livewhale (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-nohome (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-noscript (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-overflows (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-apache-shellshock (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-dovecot (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-php-url-fopen (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-postfix (1 references)
target     prot opt source               destination
REJECT     all  --  xxx.xxx.xxx.xxx       0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-postfix-rbl (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-postfix-sasl (1 references)
target     prot opt source               destination
REJECT     all  --  xxx.xxx.xxx.xxx        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  xxx.xxx.xxx.xxx        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  xxx.xxx.xxx.xxx        0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-proftpd (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-sshd (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-webmin-auth (1 references)
target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain f2b-wordpress (1 references)
target     prot opt source               destination
REJECT     all  --  xxx.xxx.xxx.xxx        0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

I replaced some data with X'es to cover sensitive ports or to mask banned IP's.

If you could temporarily undo your fix and re-run that netstat command, that'd be great... essentially, I just wanted to ensure it really was listening on that port on the IPv6 interface.

It could be a problem with the Perl dependencies for IPv6 -- if it's not listening on that interface when IPv6 support is enabled, that's what we'd need to look at.

Another possibility is that the firewall is blocking connections.

Regarding iptables, I think I goofed -- I suspect we should actually be looking at "ip6tables -L -n" rather than just "iptables".

However, what you could always try is to disable the firewall entirely... temporarily anyhow, and then see if that resolves the issue.

Regarding ClamAV -- we can certainly look into that, could you start a new request for that though? In there, we'll review which packages you have installed (I know Joe attempted to make some updates to handle that, but it's possible they aren't working properly).

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 11:37

If you could temporarily undo your fix and re-run that netstat command, that'd be great... essentially, I just wanted to ensure it really was listening on that port on the IPv6 interface.

[root@jenkins ~]# netstat -an | grep :783
tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN

Looks like this problem is more complicated than i originally thought. This is the result without my fix.

Regarding iptables, I think I goofed -- I suspect we should actually be looking at "ip6tables -L -n" rather than just "iptables".

[root@jenkins ~]# ip6tables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination

However, what you could always try is to disable the firewall entirely... temporarily anyhow, and then see if that resolves the issue.

[root@jenkins ~]# systemctl status iptables
* iptables.service - IPv4 firewall with iptables
   Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2016-07-12 18:32:49 CEST; 59s ago
  Process: 12275 ExecStop=/usr/libexec/iptables/iptables.init stop (code=exited, status=0/SUCCESS)
  Process: 110 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited, status=0/SUCCESS)
Main PID: 110 (code=exited, status=0/SUCCESS)
[root@jenkins ~]# systemctl status ip6tables
* ip6tables.service - IPv6 firewall with ip6tables
   Loaded: loaded (/usr/lib/systemd/system/ip6tables.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2016-07-12 18:32:53 CEST; 8s ago
  Process: 12340 ExecStop=/usr/libexec/iptables/ip6tables.init stop (code=exited, status=0/SUCCESS)
  Process: 111 ExecStart=/usr/libexec/iptables/ip6tables.init start (code=exited, status=0/SUCCESS)
Main PID: 111 (code=exited, status=0/SUCCESS)

Disabling iptables and ip6tables didnt help:

Jul 12 18:34:23 jenkins spamc[12503]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused

Regarding ClamAV -- we can certainly look into that, could you start a new request for that though? In there, we'll review which packages you have installed (I know Joe attempted to make some updates to handle that, but it's possible they aren't working properly).

I did and you closed the report: https://www.virtualmin.com/node/41197

Joe mentioned that we may end up needing to do a new Virtualmin release to fix some of the ClamAV issues... but yeah if you could start up a new thread for that, that'd be fantastic. Then we can review what all you''re seeing, and make sure the fixes he has planned will indeed resolve that.

Oops my apologies I just saw the last sentence of your comment above. Okay I'll take a look at that.

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 11:50

Ok, i will now bring back both iptables as i hate to have unsecure server. I hope Joe can find something from all the data i posted in this bug report.

For ClamAV i will start new bug report, not now but you can expect in next few hours.

Regarding SpamAssassin, it looks like there may be two problems.

So long as "ip6tables -L -n" shows that all policies are set to DROP by default with no "ACCEPT" lines, that should prevent any attempt to connect to any IPv6 service. So that could be a problem in the future.

However, the more immediate problem is that it also looks like SpamAssassin isn't listening on an IPv6 interface.

We can ensure that two of the IPv6 Perl modules are installed and working -- to do that, what is the output of these commands:

perl -e 'use IO::Socket::INET6'
perl -e 'use Socket6'

Also, just to verify -- what is the output of this command:

/sbin/ifconfig

Regarding ClamAV, reviewing your other thread that you posted, we really were getting a lot of similar ClamAV issues back then. Some of the issues were dependency related -- some necessary ClamAV packages weren't being pulled in. Joe released an updated virtualmin-base package that should have helped, and we also tweaked the install.sh script to ensure they were being brought in on newer systems.

However, Joe still thinks there's some config issues that will be resolved with a new release. He's saying we'll be pushing one out soon.

Can you let us know if that works better for you on the new release?

Edit: tweaked some wording and whatnot above

Diabolico's picture
Submitted by Diabolico on Tue, 07/12/2016 - 21:47

perl -e 'use IO::Socket::INET6'
perl -e 'use Socket6'

No output from this two lines.

So long as "ip6tables -L -n" shows that all policies are set to DROP by default with no "ACCEPT" lines, that should prevent any attempt to connect to any IPv6 service. So that could be a problem in the future.

That was intentionally because i wanted to block IPv6 on this server. I didnt limit only ip6tables, i disabled IPv6 in any service what was configured by default to use it, e.g. like Named, SSH, Postfix, etc..., but i didnt touch SpamAssassin until today when i saw that problem in mail log. The reason is clear and lets be honest, right now IPv6 is big pile of crap and mostly used by people who buy cheap garbage of VPS and they get 1 or few IPv6 for "free". We know for what are used this kind of servers so i dont have any wish to enable IPv6. Honestly just disabling IPv6 i eliminated quite large number of port scaning, postfix/dovecot brute force, flood on named trying to exploit recursion for DDoS amplification and so on.

Until big ISP dont fully support IPv6 we are not going anywhere and based on the current situation this will not happen for at least 3-5 years and i'm generous here.

[root@jenkins ~]# /sbin/ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 3678  bytes 587297 (573.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3678  bytes 587297 (573.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500
        inet 127.0.0.1  netmask 255.255.255.255  broadcast 0.0.0.0  destination 127.0.0.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)
        RX packets 26182  bytes 3177208 (3.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 31305  bytes 19764729 (18.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

venet0:0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500
        inet IP4.xxx.xxx.xxx  netmask 255.255.255.255  broadcast IP4.xxx.xxx.xxx  destination IP4.xxx.xxx.xxx
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)

The point is i dont want to use IPv6. I have IPv6 enabled from my host but i disabled them in SolusVM so my OS and Vmin dont see them and i did this before Centos 7 and Vmin installation.

I do hear you about IPv6, I don't use that on my personal servers either.

Jamie and I have been digging into the issue you're seeing.

You do have an IPv6 address setup on the "lo" interface.

Under normal circumstances, SpamAssassin should listen on both the IPv4 and IPv6 addresses, if both are present.

Jamie and I have both reviewed your output above, along with the SpamAssassin documentation regarding how it's supposed to work, and we're both puzzled as to why it's not listening on the IPv6 address you have there, except for one possible case --

I don't imagine that the "-4" flag is being passed into the spamd daemon when it's starting? That should be the only thing that would cause it not to listen on both interfaces.

It might be worth double-checking that.

Other than that, we unfortunately haven't been able to reproduce a case where that would occur.

And the two Perl commands you ran above, that didn't produce any output -- that's good, that indicates that you have the correct Perl dependencies for running SpamAssassin on an IPv6 interface, and that they aren't throwing an error when being run.

Other than that, the only other thing I can offer would be to review /var/log/maillog when the spamd service is starting, just to verify that it's not throwing an error or warning of some sort.

Diabolico's picture
Submitted by Diabolico on Wed, 07/13/2016 - 14:44

I don't imagine that the "-4" flag is being passed into the spamd daemon when it's starting? That should be the only thing that would cause it not to listen on both interfaces.

I try that and few other similar solution but it doesnt work. Looks like whatever i do it will not change the outcome and only thing that works is the solution from my first post, e.g. to create "/etc/mail/spamassassin/spamc.conf" and fill with "-d 127.0.0.1".

Well i made a little mistake thinking you guys changed SpamAssassin in the same way you did with ClamAV (i think Joe was talking about this in some topic).

I check the logs many times and there is nothing what would indicate any problem during SA restart, actually even with SA failing for IPv6 it still checks the emal. At least the logs show that and there is few SA lines in email headers. Looking again at the log files it looks like SA is always trying to first connect by IPv6 and when it fails switch to IPv4. For now i will keep my solution, maybe next SA update will solve this problem.

Yeah it's good to ask, as if it were a package we maintained, or we were seeing a lot of that, we might be able to help out.

Jamie and I went back and forth on this a bit, trying to sort out what the issue might be, but ultimately we're stumped.

It does seem like something outside of our realm is going on.

Your suggestion seems like a good one -- that your current fix is doing the trick, but maybe the next SpamAssassin version will resolve it entirely.

Regarding your earlier mention of ClamAV -- Joe is aware of those issues, and is looking into fixes for that in the next release.

I found this thread and have fallen into the same problem. My environment is that I moved all my virtualmin hosts to another cloud server and this problem started. Not that this maybe caused the problem but some weird things have happened when I install virtualmin on the new machine and moved every client virtual instance from my old machine using Backup and Restore > backup virtual servers one big problem was related to this: https://www.virtualmin.com/node/25539 reply #12 was my fix

anyways

virtualmin .sh script was different from my old one to my new one both spamassassin are the same version on both VM's both centos7 are identical saying: centos-release-7-5.1804.el7.centos.2.x86_64

I have used Diabolico solution that did work for me as well. So thanks! I did fiddle with the network and compared stuff from my old and new since I have access to my old until end of billing. I haven't gotten anywhere and nothing important to write about.

If there is any headway on this I would be interested to know. I found that receiving mail does hang a bit when it disconnects from mailer its getting the mail from ie. (postfix/smtpd[27707]: disconnect from mail-io0-f176.google.com[209.85.223.176]) and the first spamd, but they both kind of hang time with the error spamc[27742]: connect to spamd on ::1 failed or without (using Diabolico's fix) spamd[27542]: spamd: connection from localhost

One possible work-around would be to comment out the line starting with ::1 in /etc/hosts , to force connections to localhost to be IPv4.

thanks for the update. Unfortunately that does not work. I did try it and restarted networking, removed the spamc.conf and restart spamassassin to see but that error in the logs is still there.