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

Re: Why Postfix always complain "unexpected EOF" with my own tcp_table program?

Expand Messages
  • Sam Flint
    ... reply from 127.0.0.1:1234: unexpected EOF (Success) ... But is it the fact that he closes the connection? Keep in mind that any time a network connection
    Message 1 of 7 , Jul 28, 2013
    View Source
    • 0 Attachment


      On Jul 28, 2013 7:25 AM, "Wietse Venema" <wietse@...> wrote:
      >
      > Zhang Huangbin:
      > > Dear all,
      > >
      > > I wrote a simple daemon service in Python, it's used in Postfix transport_maps like this:
      > >
      > > transport_maps = tcp:127.0.0.1:1234
      > >
      > > It always returns '200 my_transport\n' as described in Postfix manual page tcp_table(5), but Postfix always complains "unexpected EOF" like below:
      > >
      > > Jul 27 22:51:53 d7 postfix/trivial-rewrite[4260]: warning: read TCP map reply from 127.0.0.1:1234: unexpected EOF (Success)
      > >
      > > This Python daemon server uses 'asynchat' module, and return '200 my_transport\n' with 'async_chat.push()' method like this:
      > >
      > > self.push('200 my_transport\n')
      > >
      > > Any idea why Postfix always complain "unexpected EOF"?
      >
      > 1) Use a network sniffer to see what Python actually sends. You may
      >    assume that your program sends \n, but Postfix does not receive \n.
      >
      > 2) Unrelated to this bug: closing the connection after one request
      >    is inefficient.

      But is it the fact that he closes the connection? Keep in mind that any time a network connection is closed it sends EOF.   Could it be that Postfix wants to keep a constant connection?

      Sam

      >         Wietse

    • Zhang Huangbin
      ... Thanks Wietse, and John. I think this is the root cause, will try a network sniffer later. ... My program closes the connection immediately.
      Message 2 of 7 , Jul 28, 2013
      View Source
      • 0 Attachment
        On Sunday, July 28, 2013 at 8:24 PM, Wietse Venema wrote:

        >
        > 1) Use a network sniffer to see what Python actually sends. You may
        > assume that your program sends \n, but Postfix does not receive \n.


        Thanks Wietse, and John.
        I think this is the root cause, will try a network sniffer later.
        > 2) Unrelated to this bug: closing the connection after one request
        > is inefficient.


        My program closes the connection immediately.
      • Wietse Venema
        ... Caution: it is not a good idea to close a connection immediately after writing data to it. Some TCP/IP implementations may discard unsent data when a
        Message 3 of 7 , Jul 28, 2013
        View Source
        • 0 Attachment
          Zhang Huangbin:
          > On Sunday, July 28, 2013 at 8:24 PM, Wietse Venema wrote:
          >
          > > 1) Use a network sniffer to see what Python actually sends. You may
          > > assume that your program sends \n, but Postfix does not receive \n.
          >
          > Thanks Wietse, and John.
          > I think this is the root cause, will try a network sniffer later.
          > > 2) Unrelated to this bug: closing the connection after one request
          > > is inefficient.
          >
          > My program closes the connection immediately.

          Caution: it is not a good idea to close a connection immediately
          after writing data to it. Some TCP/IP implementations may discard
          unsent data when a connection is closed.

          In Postfix, I avoid "write-close" bugs by keeping a connection open
          until the receiver closes it (with of course a time limit that
          forces the connection to be closed when things take too long).

          Wietse
        • King Cao
          You can enable the debug mode of postfix smtp daemon ( http://www.postfix.org/DEBUG_README.html). Then you can see the request and response which postfix
          Message 4 of 7 , Jul 28, 2013
          View Source
          • 0 Attachment
            You can enable the debug mode of postfix smtp daemon (http://www.postfix.org/DEBUG_README.html). Then you can see the request and response which postfix talked with your tcp_table script.

            PS:
              From the postfix source code, it seems postfix has not received any response from your tcp_table.  However postfix will retry 10 times for such scenario (sleep 1 sec before each retry).


            2013/7/28 Wietse Venema <wietse@...>
            Zhang Huangbin:
            > On Sunday, July 28, 2013 at 8:24 PM, Wietse Venema wrote:
            >
            > > 1) Use a network sniffer to see what Python actually sends. You may
            > > assume that your program sends \n, but Postfix does not receive \n.
            >
            > Thanks Wietse, and John.
            > I think this is the root cause, will try a network sniffer later.
            > > 2) Unrelated to this bug: closing the connection after one request
            > > is inefficient.
            >
            > My program closes the connection immediately.

            Caution: it is not a good idea to close a connection immediately
            after writing data to it.  Some TCP/IP implementations may discard
            unsent data when a connection is closed.

            In Postfix, I avoid "write-close" bugs by keeping a connection open
            until the receiver closes it (with of course a time limit that
            forces the connection to be closed when things take too long).

                    Wietse

          Your message has been successfully submitted and would be delivered to recipients shortly.