Hi Michael,
So cool to have a message from the actual Debian package maintainer via
here too!
As you requested:
root@SMTP:~# ls -l /var/spool/postfix/etc/resolv.conf
-rw-r--r-- 1 root root 114 Aug 27 19:22
/var/spool/postfix/etc/resolv.conf
root@SMTP:~# ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 162 Aug 27 19:23 /etc/resolv.conf
I think it's just as simple as the service is starting too early (before
dhcpd has concluded).. I looked more at whether network-online.target
was a viable option and it looks like in non-GUI Trixie there's nothing
that implements or depends on it. ChatGPT suggested some pre-script that
if it came to it just implements a crude delay before Postfix gets started.
>If it's not the case, I'd love to see more details about your setup.
* In the Debian installer everything is un-ticked apart from SSH
Server and Standard System Utilities.
* Attached is all the commands I used to build the machine.
* The VM gets its IP and DNS servers via DHCP (static lease on DHCP
server).
* I'll send you the TAR file direct.
Sometimes it boots up fine.. most of the time it does not and I have to
manually force a service postfix restart. I don't recall needing to do
this with Debian 12 but due to a UPS battery issue I've been restarting
my 13 more than I did my 12.
The packaging otherwise has served me well in Debian 12 and Debian 13
was relatively seamless too (so it's not a criticism and I haven't
otherwise noticed or cared about chroot before - any extra security is
usually fine by me).. it's the only one issue I've encountered and it's
only on startup and it's purely a simple race condition with dhcpd and a
chroot'd postfix.
I consider your and Wiese's time far more valuable than mine, given the
impact of your work - so I'm happy to give you as much or as little info
as you find important or interesting. Just found the DHCP supplied DNS
race condition on Debian 13 to be noteworthy to the postfix community.
If you need me to raise anything via bugs.debian.org or contribute in
any threads there happy to as well.
Kind Regards,
Matthew
On 27/08/2025 09:44, Michael Tokarev via Postfix-users wrote:
On 27.08.2025 02:04, Wietse Venema via Postfix-users wrote:
Matthew via Postfix-users:
*Aug 26 15:09:28 SMTP postfix[1037]: postfix/postlog: warning:
/var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
Aug 26 15:09:28 SMTP postfix/postfix-script[1037]: warning:
/var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ*
Please also check the timestamps of these files - is resolv.conf
in /var/spool/postfix more recent than the one in /etc?
If yes, what you're seeing is the remnants of previous postfix
packaging in debian, and my inability to imagine this particular
situation when trying to fix it, - this particular issue should
be fixed in the next version of postfix package in debian (already
fixed in unstable). Once again, this is about a particular issue
when chroot copy of the file is more recent than the one in /etc.
If it's not the case, I'd love to see more details about your setup.
That would explain why DNS results are different for Postfix amd
for OS utilities. Turn off chroot and the problem goes away.
Looks like it's exactly as you suspected "is the file
/var/spool/postfix/etc/resolv.conf up-to-date BEFORE Postfix is
started?" it would appear not.
For completeness, as you requested:
root@SMTP:~# postconf -F smtp/inet/chroot smtp/inet/chroot = y
root@SMTP:~# postconf -F submissions/inet/chroot
submissions/inet/chroot = y
Unfortunately this will most likely break (move) comments in master.cf.
Running Postfix chrooted on Linux is like fighting windmills. Don't
waste your time on that.
Can you file a request to Debian maintainers to make non-chroot
Postfix the default? Upstream Postfix turned off chroot a decade
ago (in 2015), and it's time that Debian catches up. Your struggles
are unnecessary, and they make Postfix adoption difficult.
https://bugs.debian.org/1084167 -- I asked for help with this issue,
and had no chance to resolve it before trixie (I'll probably have to
rewrite existing configuration mechanism entirely, also due to
https://bugs.debian.org/734401).
But this wont change this situation in any way, because it is an
upgrade from previous debian release and we have to keep existing
configuration.
Thanks,
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
# All future commands require root
sudo -i
# Update distro
apt-get update
apt-get -y dist-upgrade
# Install fail2ban, iptables-persistent, postfix, postfix-pcre,
postfix-policyd-spf-python and unattended-upgrades
apt-get -y install fail2ban iptables-persistent postfix postfix-pcre
postfix-policyd-spf-python unattended-upgrades
# Configure unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
# Backup config.
#tar --create --file=/home/smtp/SMTP.tar --absolute-names --verbose
/etc/iptables/
#tar --append --file=/home/smtp/SMTP.tar --absolute-names --verbose
/etc/postfix/body_checks /etc/postfix/main.cf /etc/postfix/master.cf
/etc/postfix/restricted_helo /etc/postfix/restricted_senders
/etc/postfix/virtual
#tar --append --file=/home/smtp/SMTP.tar --absolute-names --verbose
/etc/postfix-policyd-spf-python/
#tar --append --file=/home/smtp/SMTP.tar --absolute-names --verbose
/etc/ssl/private/Matthew1471.pem
# Restore config.
tar --extract --file=/home/smtp/SMTP.tar --absolute-names --verbose
# Restart postfix
systemctl restart postfix
# Clear logs
journalctl --rotate
journalctl --vacuum-time=1s
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
