On 30 Nov 2016, at 22:18, Stefan Monnier wrote:

Don't chroot the Postfix smtp delivery agent.  It will then notice
changes in /etc/resolv.conf, rather than using a stale copy in
the chroot jail.  Better don't use chroot at all, unless it is
very carefully and robustly built.


Ha!

    # find /var -name resolv.conf
    /var/spool/postfix/etc/resolv.conf
    # cat /var/spool/postfix/etc/resolv.conf
    # Generated by NetworkManager
    #

That explains the behavior!  Thank you very much.

I'm not sure why /var/spool/postfix/etc/resolv.conf is empty: the only
time it should be empty is "right when I suspend/wake-up", since it's
the only time the wifi connection is not up. So apparently some part of Debian somehow refreshes /var/spool/postfix/etc/resolv.conf when waking
up, which ends up doing exactly the wrong thing.

The "some part" is identified in the comment at the top of resolv.conf.

NetworkMangler is a menace to any persistent network daemon. Having a Postfix instance running on a machine that goes through suspend/resume cycles and relies on WiFi for basic connectivity creates a fragile circumstance because he most common Postfix configurations on real servers don't expect labile networking under the control of a tool designed for personal computers, not servers.

Beyond Viktor's recommendation to NOT chroot Postfix, another option is to run Postfix on demand, since you appear to only be running it in a client-only mode. I'm not sure how you'd do that on Debian, but the general idea is to run 'master -e 60' whenever a file appears in the maildrop queue directory.

Reply via email to