Amavisd isn’t running with Postfix – connection refused to 127.0.0.1

Late last night, I decided to apply some needed updates to my personal mail server, which is running Gentoo Linux (OpenRC) with a mail stack of Postfix & Dovecot with AMaViS (filtering based on SpamAssassin, ClamAV, and Vipul’s Razor). After applying the updates, and restarting the necessary components of the mail stack, I ran my usual test of sending an email from one of my accounts to another one. It went through without a problem.

However, I realised that it isn’t a completely valid test to send an email from one internal account to another because I have amavisd configured to not scan anything coming from my trusted IPs and domains. I noticed several hundred mails in the queue when I ran postqueue -p, and they all had notices similar to:


status=deferred (delivery temporarily suspended:
connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)

That indicated to me that it wasn’t a problem with Postfix (and I knew it wasn’t a problem with Dovecot, because I could connect to my accounts via IMAP). Seeing as amavisd is running on localhost:10024, I figured that that is where the problem had to be. A lot of times, when there is a “connection refused” notification, it is because no service is listening on that port. You can test to see what ports are in a listening state and what processes, applications, or daemons are listening by running:

netstat -tupan | grep LISTEN

When I did that, I noticed that amavisd wasn’t listening on port 10024, which made me think that it wasn’t running at all. That’s when I ran into the strange part of the problem: the init script output:

# /etc/init.d/amavisd start
* WARNING: amavisd has already been started
# /etc/init.d/amavisd stop
The amavisd daemon is not running                [ !! ]
* ERROR: amavisd failed to start

So, apparently it is running and not running at the same time (sounds like a Linux version of Schrödinger’s cat to me)! It was obvious, though, that it wasn’t actually running (which could be verified with ‘ps -elf | grep -i amavis’). So, what to do? I tried manually removing the PID file, but that actually just made matters a bit worse. Ultimately, this combination is what fixed the problem for me:


sa-update
/etc/init.d/amavisd zap
/etc/init.d/amavisd start

It seems that the SpamAssassin rules file had gone missing, and that was causing amavisd to not start properly. Manually updating the rules file (with ‘sa-update’) regenerated it, and then I zapped amavisd completely, and lastly restarted the daemon.

Hope that helps anyone running into the same problem.

Cheers,
Zach

EDIT: I have included a new post about debugging amavisd start-up problems.

9 comments

Skip to comment form

    • Enaya Gad on Monday, 26 February 2018 at 11:40
    • Reply

    Thanks. The commands restarted amavis. Strange how amavis can be running/not running. Still not yet receiving mail. Will check server queue. Maybe do a postfix restart.

    • Anton on Tuesday, 26 May 2015 at 18:41
    • Reply

    So this is a workaround. What is the root cost?
    Users should not read all blogs in the world to run their system smoothly

      • Zach on Wednesday, 27 May 2015 at 10:52
        Author
      • Reply

      I don’t know that I agree that it is a workaround. If the spamd definitions aren’t in place, then AMaViS will not start correctly. This is the first time that I’ve seen it happen, so I considered it a one-off. If you think that it is indicative of a larger problem, then a bug may be in order.

      Cheers,
      Zach

    • Voyageur on Friday, 22 May 2015 at 09:04
    • Reply

    I saw the problem faster as I use spamd directly and it will correctly reports it fails to start (after 3.4.0->3.4.1 update)
    The spamassassin ewarn could be rewritten to highlight this, currently, it looks like only the initial –install step is needed

      • Zach on Friday, 22 May 2015 at 14:06
        Author
      • Reply

      I’ll bet using spamd without AMaViS would have made it easier for me to catch the problem. That being said, overall, I’m fairly pleased with how amavisd binds the products together. Do you use spamd directly for a particular reason? I’m always up for learning new methods of mail filtering! 🙂

      Cheers,
      Zach

    • hydrapolic on Friday, 22 May 2015 at 02:00
    • Reply

    If you have Rule2XSBody plugin enabled, it’s also necessary to run sa-compile.

      • Zach on Friday, 22 May 2015 at 14:04
        Author
      • Reply

      Thanks for the tip regarding Rule2XSBody. I don’t currently use that plugin, but will have to look into it. Do you see significant performance increases with it?

      Cheers,
      Zach

        • hydrapolic on Saturday, 23 May 2015 at 01:21
        • Reply

        I haven’t measured actually. I just trusted the label 🙂
        Rule2XSBody – speedup by compilation of ruleset to native code

          • Zach on Tuesday, 26 May 2015 at 11:23
            Author
          • Reply

          Hahaha, I understand. I may give it a go and see if it helps speed up the processing.

          Thanks!

          Cheers,
          Zach

Leave a Reply to Zach Cancel reply

Your email address will not be published.