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.
