Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Postfix:postscreen crash using non-shared cachedb when enabled on 2+ interfaces

    Scheduled Pinned Locked Moved pfSense Packages
    4 Posts 2 Posters 2.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      hcoin
      last edited by

      "fatal: btree:/var/db/postfix/postscreen_cache: unable to get exclusive lock: Resource temporarily unavailable"

      "postfix/master[63033]: warning: /usr/local/libexec/postfix/postscreen: bad command startup – throttling"

      "postfix/master[63033]: warning: process /usr/local/libexec/postfix/postscreen pid 10842 exit status 1"

      This occurs whenever the postfix forwarder is enabled on more than one interface, because for each enabled interface we have:

      ip.address.here:25 inet  n      -      n      -      1      postscreen
      -o user=postfix
      -o soft_bounce=yes

      And, being a forwarder, to enable reverse ip lookup success it's also relaying mail from internal senders, so it has to be enabled at least twice, once on the wan, and again on the lan.  So, two postfix instances.  But Wieste, the postfix tsar says:

      "You MUST NOT run more than one postscreen process per
      postscreen cache file. This file cannot be shared.

      To turn on postscreen for SMTP mail, see the configuration instructions
      in http://www.postfix.org/POSTSCREEN_README.html

      Wietse""

      There, one reads of a version v 2.9 upgrade, not available on pfsense.

      " NOTE: To share a postscreen(8) cache between multiple postscreen(8) instances, use "postscreen_cache_map = proxy:btree:$data_directory/postscreen_cache", and disable cache cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8) instances except one that is responsible for cache cleanup.

      postscreen(8) cache sharing requires Postfix 2.9 or later; earlier proxymap(8) implementations don't support cache cleanup. "

      I thought to try mysql and so forth, but the maintainers assert that postscreen can only be used with low latency setups.

      So…. pfsense and postfix 2.9??

      1 Reply Last reply Reply Quote 0
      • marcellocM
        marcelloc
        last edited by

        You can workaround this issue by listening postfix on localhost only and then nat external ips to 127.0.0.1.

        Postfix 2.9 is on todo list. I'll try to include memcache on next release too.

        Treinamentos de Elite: http://sys-squad.com

        Help a community developer! ;D

        1 Reply Last reply Reply Quote 0
        • H
          hcoin
          last edited by

          Success!  Thanks very much.  For me, not deleting the recipient filename on save is needed more than v2.9

          (Note:  The freebsd builds of postfix v 2.9 do not include TLS by default.  With this workaround now I don't have to build and install one myself.  One thing I did notice, there were several  Pcre versions in pkg_info.  Seemed odd.  v2.9 uses a slightly newer one than v2.8)

          1 Reply Last reply Reply Quote 0
          • marcellocM
            marcelloc
            last edited by

            @hcoin:

            Success!  Thanks very much.  For me, not deleting the recipient filename on save is needed more than v2.9

            I've published version 2.3.3_1 with valid recipients fixes and improvements.

            The local file now is remote url fetch and is updated via cron as well.

            To force a update and see if there is no fetch erros, run /usr/local/bin/php -q /usr/local/www/postfix_recipients.php from console

            att,
            Marcello Coutinho

            Treinamentos de Elite: http://sys-squad.com

            Help a community developer! ;D

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.