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

Re: Closing policy connections to smtp causes smtps in CLOSE_WAIT

Expand Messages
  • Victor Duchovni
    ... Unlike SIP, TCP requires both sides to close the connection before the state is completely released. ... Idle SMTP servers don t do anything until they get
    Message 1 of 4 , Apr 2, 2006
    • 0 Attachment
      On Sun, Apr 02, 2006 at 07:47:09PM +0200, Robert Felber wrote:

      > Hello,
      >
      > I'm trying now since 4 days to solve an annoying issue.
      >
      > smtpd opens a connection to a policy server.
      > Communication is done, attributes shared, actions done.
      >
      > Now smtp leaves the connection open, the policy server is fine
      > with that.
      >
      > Now if either the user, or the policy server decides to close
      > a idle connction, we have smtps in CLOSE_WAIT state.

      Unlike SIP, TCP requires both sides to close the connection before
      the state is completely released.

      > The smtps are hanging in a flock.

      Idle SMTP servers don't do anything until they get an SMTP connection.

      > On BSD it seems, that the connection will be closed and reopened
      > as soon if a new policy request is requested,

      When the SMTP server discovers that the connection is closed, it
      will reconnect.

      > on linux 2.6 it seems to hang.

      Show a system call trace? Sounds like a Linux bug. Is a TCP policy
      service, or a unix-domain socket policy service?

      > I've tried shutdown(2) (with argument 2) as well as close()
      >
      > How can I ensure that an idle connection may not only be closed
      > by postfix.
      >

      TCP connections are closed one end at a time. The until the
      other end sends its FIN the connection is still open, though
      data transfer may not be possible (will result in a RST).

      --
      Viktor.

      Disclaimer: off-list followups get on-list replies or get ignored.
      Please do not ignore the "Reply-To" header.

      To unsubscribe from the postfix-users list, visit
      http://www.postfix.org/lists.html or click the link below:
      <mailto:majordomo@...?body=unsubscribe%20postfix-users>

      If my response solves your problem, the best way to thank me is to not
      send an "it worked, thanks" follow-up. If you must respond, please put
      "It worked, thanks" in the "Subject" so I can delete these quickly.
    • Wietse Venema
      ... No problem. The SMTPD processes will discover that the connection is gone when they try to use it. ... ALL SMTPD daemons are waiting in flock or fcntl (for
      Message 2 of 4 , Apr 2, 2006
      • 0 Attachment
        Robert Felber:
        > Hello,
        >
        > I'm trying now since 4 days to solve an annoying issue.
        >
        > smtpd opens a connection to a policy server.
        > Communication is done, attributes shared, actions done.
        >
        > Now smtp leaves the connection open, the policy server is fine
        > with that.
        >
        > Now if either the user, or the policy server decides to close
        > a idle connction, we have smtps in CLOSE_WAIT state.

        No problem. The SMTPD processes will discover that the connection
        is gone when they try to use it.

        > The smtps are hanging in a flock.

        ALL SMTPD daemons are waiting in flock or fcntl (for an exclusive
        lock on their PID file), except for the SMTPD daemons that are
        serving a client, and for the one SMTPD daemon that is waiting for
        a new client. On some platforms this is needed to prevent massive
        wakeup of multiple daemons when one client connects.

        Wietse
      • Robert Felber
        ... I meant a policy server on tcp. trace of syscalls: I m trying that right now. I was not able to trace that with strace -f -p $MASTERPID strace.out 2 &1.
        Message 3 of 4 , Apr 3, 2006
        • 0 Attachment
          On Sun, Apr 02, 2006 at 04:14:47PM -0400, Victor Duchovni wrote:
          > > on linux 2.6 it seems to hang.
          >
          > Show a system call trace? Sounds like a Linux bug. Is a TCP policy
          > service, or a unix-domain socket policy service?

          I meant a policy server on tcp.

          trace of syscalls:

          I'm trying that right now. I was not able to trace that with
          strace -f -p $MASTERPID > strace.out 2>&1.

          After I've avoided some inheritance of some own sockets to a forked cache
          (which did not have the inet socket anyway) it appears to work.
          (leaving still CLOSE_WAIT smtpds, but it seems the smtpd reconnects upon
          failure successfully now.)

          Before my changes I had such messages in log:

          Apr 2 17:47:27 maus postfix/smtpd[25448]: warning: premature end-of-input on 127.0.0.1:12525 while reading input attribute name
          Apr 2 17:47:27 maus postfix/smtpd[25448]: warning: problem talking to server 127.0.0.1:12525: Success

          (in that order, I'm not sure how far I trust this order, as this syslog has
          sometimes mixed timestamps (past after present, specially on fast code and
          load)).

          I'm very sure it was a problem with a inherited socket, which seems to be solved
          now.



          --
          Robert Felber (PGP: 896CF30B)
          Munich, Germany
        Your message has been successfully submitted and would be delivered to recipients shortly.