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

Postfix local delivery stops after an hour.

Expand Messages
  • Kevin Stevens
    Hello there - I m having an odd local mailbox delivery problem. I ve recently upgraded my OS X installation from 10.4 (Tiger) to 10.5 (Leopard). In the
    Message 1 of 7 , Nov 1, 2007
    • 0 Attachment
      Hello there -

      I'm having an odd local mailbox delivery problem.

      I've recently upgraded my OS X installation from 10.4 (Tiger) to 10.5
      (Leopard). In the process, my postfix installation, which has been
      stable for many months, was updated. My master.cf and main.cf
      customizations (minor changes to enforce $mydomain, etc. and deliver
      to maildir) were manually edited into the new files, I didn't just
      copy over the old configs. Aliases and other hash tables were rebuilt
      with postmap.

      I'll run postfix start to begin servicing inbound SMTP, and life is
      good. I'll get delivery notices like:

      Oct 30 18:42:37 babelfish postfix/local[2871]: AC70B768FA: to=<kes@...
      >, orig_to=<groups@...>, relay=local, delay=3.2,
      delays=3.2/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)

      After running for about an hour (hard to tell exactly), I'll suddenly
      see a bounce notice like this:

      Oct 30 19:46:42 babelfish postfix/local[2780]: AC02A768D9: to=<kes@...
      >, orig_to=<zixxer@...>, rel
      ay=local, delay=0.56, delays=0.45/0.05/0/0.06, dsn=5.1.1,
      status=bounced (unknown user: "kes")

      All subsequent messages arriving for kes suffer the same fate. When I
      postfix stop/postfix start the mail system, the problem goes away for
      another hour.

      All the other behaviors appear normal; non-local users get rejected
      before delivery, aliases are being translated correctly, etc. It
      looks to my uneducated eye that this is some kind of local delivery
      problem, since the process in charge of permitting delivery in the
      first place reliably allows them in - they just can't be delivered to
      the local mailbox because the user has been forgotten? The kes user
      maildir is located on the same box and is always available. Same
      problem occurs for other users, btw.

      What other info can I provide? This has me completely baffled.

      Tx.

      KeS

      postconf -n output:

      command_directory = /usr/sbin
      config_directory = /etc/postfix
      daemon_directory = /usr/libexec/postfix
      debug_peer_level = 2
      home_mailbox = Maildir/
      html_directory = no
      mail_owner = _postfix
      mailq_path = /usr/bin/mailq
      manpage_directory = /usr/share/man
      message_size_limit = 10485760
      mydestination = $myhostname, $mydomain, localhost, localhost.
      $mydomain, pursued-with.net, localhost.pursued-with.net,mail.pursued-
      with.net, www.pursued-with.net, kevinstevens.info,
      localhost.kevinstevens.info, mail.kevinstevens.info, www.kevinstevens.info
      , babysealclub.org, localhost.babysealclub.org, mail.babysealclub.org, www.babysealclub.org
      ,
      mydomain_fallback = localhost
      myhostname = pursued-with.net
      mynetworks = 10.0.0.0/8, 192.168.168.0/24, 127.0.0.0/8
      newaliases_path = /usr/bin/newaliases
      queue_directory = /private/var/spool/postfix
      readme_directory = /usr/share/doc/postfix
      sample_directory = /usr/share/doc/postfix/examples
      sendmail_path = /usr/sbin/sendmail
      setgid_group = _postdrop
      unknown_local_recipient_reject_code = 550
    • Victor Duchovni
      ... What version of Postfix is shipped with Leopard? $ postconf mail_version mail_release_date ... Sounds like a netinfo problem. Is there some sort of
      Message 2 of 7 , Nov 1, 2007
      • 0 Attachment
        On Thu, Nov 01, 2007 at 01:29:53AM -0700, Kevin Stevens wrote:

        > Hello there -
        >
        > I'm having an odd local mailbox delivery problem.
        >
        > I've recently upgraded my OS X installation from 10.4 (Tiger) to 10.5
        > (Leopard). In the process, my postfix installation, which has been
        > stable for many months, was updated. My master.cf and main.cf
        > customizations (minor changes to enforce $mydomain, etc. and deliver
        > to maildir) were manually edited into the new files, I didn't just
        > copy over the old configs. Aliases and other hash tables were rebuilt
        > with postmap.

        What version of Postfix is shipped with Leopard?

        $ postconf mail_version mail_release_date

        > I'll run postfix start to begin servicing inbound SMTP, and life is
        > good. I'll get delivery notices like:
        >
        > Oct 30 18:42:37 babelfish postfix/local[2871]: AC70B768FA:
        > to=<kes@... >, orig_to=<groups@...>, relay=local,
        > delay=3.2, delays=3.2/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)
        >
        > After running for about an hour (hard to tell exactly), I'll suddenly
        > see a bounce notice like this:
        >
        > Oct 30 19:46:42 babelfish postfix/local[2780]: AC02A768D9:
        > to=<kes@...>, orig_to=<zixxer@...>,
        > relay=local, delay=0.56, delays=0.45/0.05/0/0.06, dsn=5.1.1,
        > status=bounced (unknown user: "kes")

        Sounds like a "netinfo" problem. Is there some sort of "netinfo" listener
        that is recycled each hour? Perhaps the C-library getpwnam(3) fails for
        long-running processes as a result.

        > What other info can I provide? This has me completely baffled.

        Download the Postfix (say 2.4.6) source code, and build it, but don't
        install. Apply the following patch to src/global/mypwd.c, and in the
        src/global directory:

        $ make mypwd
        $ ./mypwd kes postfix nobody

        Let this run until it fails, or many hours later you get tired of waiting
        for a miracle. It will print lookup results for the three users once
        a minute. Report the results here.

        Index: global/mypwd.c
        --- global/mypwd.c 29 Mar 2007 06:20:08 -0000 1.1.1.1
        +++ global/mypwd.c 1 Nov 2007 13:01:55 -0000
        @@ -211,6 +211,7 @@

        mypwd = (struct mypasswd **) mymalloc((argc + 1) * sizeof(*mypwd));

        + for (;;) {
        for (i = 1; i < argc; i++) {
        if (ISDIGIT(argv[i][0]))
        mypwd[i] = mypwuid(atoi(argv[i]));
        @@ -225,6 +226,8 @@
        msg_info("- %s link=%d used=%d used=%d", argv[i], mypwd[i]->refcount,
        mypwcache_name->used, mypwcache_uid->used);
        mypwfree(mypwd[i]);
        }
        + sleep(60);
        + }

        myfree((char *) mypwd);

        --
        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.
      • Kevin Stevens
        ... mail_version = 2.4.3 mail_release_date = 20070531 Not sure what Tiger used, but obviously it was quite a bit older. ... I thought of that, but what s
        Message 3 of 7 , Nov 1, 2007
        • 0 Attachment
          On Nov 1, 2007, at 06:07, Victor Duchovni wrote:

          > On Thu, Nov 01, 2007 at 01:29:53AM -0700, Kevin Stevens wrote:
          >
          >> Hello there -
          >>
          >> I'm having an odd local mailbox delivery problem.
          >>
          >> I've recently upgraded my OS X installation from 10.4 (Tiger) to 10.5
          >> (Leopard). In the process, my postfix installation, which has been
          >> stable for many months, was updated. My master.cf and main.cf
          >> customizations (minor changes to enforce $mydomain, etc. and deliver
          >> to maildir) were manually edited into the new files, I didn't just
          >> copy over the old configs. Aliases and other hash tables were
          >> rebuilt
          >> with postmap.
          >
          > What version of Postfix is shipped with Leopard?
          >
          > $ postconf mail_version mail_release_date

          mail_version = 2.4.3
          mail_release_date = 20070531

          Not sure what Tiger used, but obviously it was quite a bit older.

          >
          >
          >> I'll run postfix start to begin servicing inbound SMTP, and life is
          >> good. I'll get delivery notices like:
          >>
          >> Oct 30 18:42:37 babelfish postfix/local[2871]: AC70B768FA:
          >> to=<kes@... >, orig_to=<groups@...>,
          >> relay=local,
          >> delay=3.2, delays=3.2/0/0/0, dsn=2.0.0, status=sent (delivered to
          >> maildir)
          >>
          >> After running for about an hour (hard to tell exactly), I'll suddenly
          >> see a bounce notice like this:
          >>
          >> Oct 30 19:46:42 babelfish postfix/local[2780]: AC02A768D9:
          >> to=<kes@...>, orig_to=<zixxer@...>,
          >> relay=local, delay=0.56, delays=0.45/0.05/0/0.06, dsn=5.1.1,
          >> status=bounced (unknown user: "kes")
          >
          > Sounds like a "netinfo" problem. Is there some sort of "netinfo"
          > listener
          > that is recycled each hour? Perhaps the C-library getpwnam(3) fails
          > for
          > long-running processes as a result.

          I thought of that, but what's confusing to me there is I thought the
          local daemons were short-lived spinoffs from master anyway, so why
          would it matter? Unless master does the lookup and passes it off to
          local. But in that case, why is the mail accepted for delivery at all?

          >
          >
          >> What other info can I provide? This has me completely baffled.
          >
          > Download the Postfix (say 2.4.6) source code, and build it, but don't
          > install. Apply the following patch to src/global/mypwd.c, and in the
          > src/global directory:
          >
          > $ make mypwd
          > $ ./mypwd kes postfix nobody
          >
          > Let this run until it fails, or many hours later you get tired of
          > waiting
          > for a miracle. It will print lookup results for the three users once
          > a minute. Report the results here.
          >
          > Index: global/mypwd.c
          > --- global/mypwd.c 29 Mar 2007 06:20:08 -0000 1.1.1.1
          > +++ global/mypwd.c 1 Nov 2007 13:01:55 -0000
          > @@ -211,6 +211,7 @@
          >
          > mypwd = (struct mypasswd **) mymalloc((argc + 1) *
          > sizeof(*mypwd));
          >
          > + for (;;) {
          > for (i = 1; i < argc; i++) {
          > if (ISDIGIT(argv[i][0]))
          > mypwd[i] = mypwuid(atoi(argv[i]));
          > @@ -225,6 +226,8 @@
          > msg_info("- %s link=%d used=%d used=%d", argv[i], mypwd[i]->refcount,
          > mypwcache_name->used, mypwcache_uid->used);
          > mypwfree(mypwd[i]);
          > }
          > + sleep(60);
          > + }
          >
          > myfree((char *) mypwd);
          >
          > --
          > Viktor.

          Egad. I'll have to work on that one.

          Tx.

          KeS
        • Victor Duchovni
          ... Yes, substantially more recent, good to see Apple catching up periodically. ... Tiger had 2.1.5. ... They are not that short-lived, if deliveries happen at
          Message 4 of 7 , Nov 1, 2007
          • 0 Attachment
            On Thu, Nov 01, 2007 at 08:51:55AM -0700, Kevin Stevens wrote:

            > >What version of Postfix is shipped with Leopard?
            > >
            > > $ postconf mail_version mail_release_date
            >
            > mail_version = 2.4.3
            > mail_release_date = 20070531

            Yes, substantially more recent, good to see Apple catching up
            periodically.

            > Not sure what Tiger used, but obviously it was quite a bit older.

            Tiger had 2.1.5.

            > >>After running for about an hour (hard to tell exactly), I'll suddenly
            > >>see a bounce notice like this:
            > >>
            > >>Oct 30 19:46:42 babelfish postfix/local[2780]: AC02A768D9:
            > >> to=<kes@...>, orig_to=<zixxer@...>,
            > >> relay=local, delay=0.56, delays=0.45/0.05/0/0.06, dsn=5.1.1,
            > >> status=bounced (unknown user: "kes")
            > >
            > >Sounds like a "netinfo" problem. Is there some sort of "netinfo"
            > >listener
            > >that is recycled each hour? Perhaps the C-library getpwnam(3) fails
            > >for
            > >long-running processes as a result.
            >
            > I thought of that, but what's confusing to me there is I thought the
            > local daemons were short-lived spinoffs from master anyway, so why
            > would it matter?

            They are not that short-lived, if deliveries happen at least 100s
            apart (max_idle) each local(8) daemon can live for up to 100 deliveries
            (max_use), so the total lifetime can be as high as 10,000 seconds, but
            is more likely lower:

            L = 100 * N / M
            L = daemon lifetime
            N = average # of daemons running
            M = message rate

            If you have 10 local delivery agents, and 1 message per second, the
            lifetime is ~1000s.

            > Unless master does the lookup and passes it off to
            > local. But in that case, why is the mail accepted for delivery at all?

            No local(8) is doing its own lookups.

            > > $ make mypwd
            > > $ ./mypwd kes postfix nobody
            >
            > Egad. I'll have to work on that one.

            I don't know a more efficient way to test reliability of password
            lookups. When failure sets in, does it really fail all local recipients
            indefinitely? Is "reload" enough to solve the issue? Once the problem
            happens, you can "ktrace" the local delivery agent and perhaps learn
            what is breaking.

            --
            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
            ... I am very pleased. Now we can look forward to a whole new category of questions from MacOS users (DSN, Milter, ...). ... Maybe you can send him the patched
            Message 5 of 7 , Nov 1, 2007
            • 0 Attachment
              Victor Duchovni:
              > On Thu, Nov 01, 2007 at 08:51:55AM -0700, Kevin Stevens wrote:
              >
              > > >What version of Postfix is shipped with Leopard?
              > > >
              > > > $ postconf mail_version mail_release_date
              > >
              > > mail_version = 2.4.3
              > > mail_release_date = 20070531
              >
              > Yes, substantially more recent, good to see Apple catching up
              > periodically.

              I am very pleased. Now we can look forward to a whole new category
              of questions from MacOS users (DSN, Milter, ...).


              > > > $ make mypwd
              > > > $ ./mypwd kes postfix nobody
              > >
              > > Egad. I'll have to work on that one.
              >
              > I don't know a more efficient way to test reliability of password
              > lookups. When failure sets in, does it really fail all local recipients
              > indefinitely? Is "reload" enough to solve the issue? Once the problem
              > happens, you can "ktrace" the local delivery agent and perhaps learn
              > what is breaking.

              Maybe you can send him the patched mypwd.c file (or tarball).

              Wietse
            • Victor Duchovni
              ... There are a lot dependencies on vstrings, hash tables, ... it is easier to download a Postfix tarball I think... Perhaps before running the test harness we
              Message 6 of 7 , Nov 1, 2007
              • 0 Attachment
                On Thu, Nov 01, 2007 at 01:59:49PM -0400, Wietse Venema wrote:

                > > I don't know a more efficient way to test reliability of password
                > > lookups. When failure sets in, does it really fail all local recipients
                > > indefinitely? Is "reload" enough to solve the issue? Once the problem
                > > happens, you can "ktrace" the local delivery agent and perhaps learn
                > > what is breaking.
                >
                > Maybe you can send him the patched mypwd.c file (or tarball).

                There are a lot dependencies on vstrings, hash tables, ... it is easier
                to download a Postfix tarball I think...

                Perhaps before running the test harness we can learn something from
                ktrace(1) of the local delivery agent that is failing to find a valid
                user.

                --
                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
                ... The typical MacOS uses is not a programmer, so giving them the patched file takes away one barrier. On the other hand, why use a C program for this? A Perl
                Message 7 of 7 , Nov 1, 2007
                • 0 Attachment
                  Victor Duchovni:
                  > On Thu, Nov 01, 2007 at 01:59:49PM -0400, Wietse Venema wrote:
                  >
                  > > > I don't know a more efficient way to test reliability of password
                  > > > lookups. When failure sets in, does it really fail all local recipients
                  > > > indefinitely? Is "reload" enough to solve the issue? Once the problem
                  > > > happens, you can "ktrace" the local delivery agent and perhaps learn
                  > > > what is breaking.
                  > >
                  > > Maybe you can send him the patched mypwd.c file (or tarball).
                  >
                  > There are a lot dependencies on vstrings, hash tables, ... it is easier
                  > to download a Postfix tarball I think...

                  The typical MacOS uses is not a programmer, so giving them
                  the patched file takes away one barrier.

                  On the other hand, why use a C program for this? A Perl script
                  could make the same getpwnam() calls that Postfix makes.

                  Wietse

                  > Perhaps before running the test harness we can learn something from
                  > ktrace(1) of the local delivery agent that is failing to find a valid
                  > user.
                  >
                  > --
                  > 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.
                  >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.