Loading ...
Sorry, an error occurred while loading the content.

Postifx or some other system timeouts?

Expand Messages
  • Flash Love
    I am running postfix2.2.8 +mysql+sasl+tls+spf and use cyrus, spamassassin-3.1.4, clamav-0.87, dspam-3.6.2, razor-2.82-14, pyzor-0.4.0-9, dcc-1.3.26-1.53, and
    Message 1 of 2 , Aug 1, 2006
    • 0 Attachment
      I am running postfix2.2.8 +mysql+sasl+tls+spf and use cyrus,
      spamassassin-3.1.4, clamav-0.87, dspam-3.6.2, razor-2.82-14, pyzor-0.4.0-9,
      dcc-1.3.26-1.53, and amavis-new 2.4.2 configuration on FC4.

      After upgrading spamassassin and amavis-new, I immediately noticed that
      postfix's mailq began filling up with timeouts on 127.0.0.1[127.0.0.1]. So,
      for the past week, my single focus have been to repair changes to these two
      apps interface with postfix.

      As an interim hack, the only solution to flush the postqueue appeared to be an
      hourly cron that (1) postsuper -r ALL and (2) a kill and restart of amavisd.

      I am still not sure what is causing the timeout errors nor do I fully
      understand why the messages stayed in the queue for hours.

      However, I do know now that when I issue the following (between hourly crons)
      at the command line without restarting amavisd ' postsuper -r ALL; postfix
      flush' the postfix commands will flush all of the postqueue entries with
      timeout complaints that have been lingering. [I have postsuper -s and -p]

      This suggests to me that maybe, I should be assessing postfix, it is the only
      component complainting about timeouts. Maybe someone could explain to me why
      the postsuper and postfix flush combo seems to ignore queue's timeouts
      complaints to process the mail. Or any other pearls of wisdom that I may use
      to troubleshoot the timeout complaints.

      ============================================
      Original postqueue entries troubleshooting after upgrade
      ============================================
      "SPAM (in reply to end of DATA command )

      Note: applied Amavis patch to handle postfix's master.cf LTMP entries.

      Then maillog and postqueue entries changed to:
      =============
      /var/log/maillog
      =============
      Aug 1 07:58:08 kirk postfix/qmgr[4703]: EF1122F608E3:
      to=<flash@...>, relay=none, delay=1, status=deferred
      (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: read
      timeout)
      =============
      postqueue -p
      =============
      -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
      EF1122F608E3 3369 Tue Aug 1 07:58:07
      users-return-00000-flash=hostname.domain.org@...
      (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: read
      timeout) flash@...

      P.S. Maillog attachment of a timeout session was too long to send.

      Regards,
    • mouss
      ... what patch? don t apply patches when they are not needed. amavisd supports lmtp. and even if you don t like how it does, you can still use smtp. ... make
      Message 2 of 2 , Aug 1, 2006
      • 0 Attachment
        Flash Love wrote:
        > I am running postfix2.2.8 +mysql+sasl+tls+spf and use cyrus,
        > spamassassin-3.1.4, clamav-0.87, dspam-3.6.2, razor-2.82-14, pyzor-0.4.0-9,
        > dcc-1.3.26-1.53, and amavis-new 2.4.2 configuration on FC4.
        >
        > After upgrading spamassassin and amavis-new, I immediately noticed that
        > postfix's mailq began filling up with timeouts on 127.0.0.1[127.0.0.1]. So,
        > for the past week, my single focus have been to repair changes to these two
        > apps interface with postfix.
        >
        > As an interim hack, the only solution to flush the postqueue appeared to be an
        > hourly cron that (1) postsuper -r ALL and (2) a kill and restart of amavisd.
        >
        > I am still not sure what is causing the timeout errors nor do I fully
        > understand why the messages stayed in the queue for hours.
        >
        > However, I do know now that when I issue the following (between hourly crons)
        > at the command line without restarting amavisd ' postsuper -r ALL; postfix
        > flush' the postfix commands will flush all of the postqueue entries with
        > timeout complaints that have been lingering. [I have postsuper -s and -p]
        >
        > This suggests to me that maybe, I should be assessing postfix, it is the only
        > component complainting about timeouts. Maybe someone could explain to me why
        > the postsuper and postfix flush combo seems to ignore queue's timeouts
        > complaints to process the mail. Or any other pearls of wisdom that I may use
        > to troubleshoot the timeout complaints.
        >
        > ============================================
        > Original postqueue entries troubleshooting after upgrade
        > ============================================
        > "SPAM (in reply to end of DATA command )
        >
        > Note: applied Amavis patch to handle postfix's master.cf LTMP entries.
        >
        what patch? don't apply patches when they are not needed. amavisd
        supports lmtp. and even if you don't like how it does, you can still use
        smtp.
        > Then maillog and postqueue entries changed to:
        > =============
        > /var/log/maillog
        > =============
        > Aug 1 07:58:08 kirk postfix/qmgr[4703]: EF1122F608E3:
        > to=<flash@...>, relay=none, delay=1, status=deferred
        > (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: read
        > timeout)

        make sure you have enough amavisd listeners for what you configured as
        lmtp clients. this is explained in amavisd docs.

        > =============
        > postqueue -p
        > =============
        > -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
        > EF1122F608E3 3369 Tue Aug 1 07:58:07
        > users-return-00000-flash=hostname.domain.org@...
        > (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: read
        > timeout) flash@...
        >
        > P.S. Maillog attachment of a timeout session was too long to send.
        >
        > Regards,
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.