12.12.2024 20:03, Vincent Lefevre wrote:
On 2024-12-12 15:57:59 +0300, Michael Tokarev wrote:
On Tue, 30 Apr 2024 16:33:14 +0200 Vincent Lefevre <vinc...@vinc17.net> wrote:
I had to do "cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf".
Does it fix itself when you restart postfix?
No, it doesn't, because it seems that it is only
/etc/network/if-up.d/postfix that does the copy, while this script
is not involved when one restarts postfix.
When you restart postfix (either systemctl or /etc/init.d/), the
startup procedure execute /usr/lib/postfix/configure-instance.sh,
which updates whole chroot thing, not just resolv.conf.
So I wonder why this script is not being executed in your case.
Do you run it though systemd? If yes and you take a look at
`systemctl status postfix@-.service', it should show the ExecStartPre=
line referencing configure-instance.sh.
If you run it through /etc/init.d/postfix (under sysvinit, unlikely),
it's this script which run the same configure-instance.sh.
When I asked you about `when you restart postfix', I wasn't clear
enough. I mean what happens when you `systemctl restart postfix',
not `postfix stop; postfix start'.
Not even that either: If I move to a different wiki network, the
wireless interface remains up; it is just the associated IP address
that changes. So /etc/network/if-up.d/postfix is not re-executed.
Well, it is supposed to trigger not only on interface up/down, but
also when dhcp info changes. But I see.
There's a note in /usr/share/doc/postfix/README.Debian[.gz] which
suggests to enable systemd path units for resolv.conf (though I
do *not* recommend doing this now).
If I understand correctly, when everything is enabled: When
postfix-resolvconf.path detects that /etc/resolv.conf has changed,
it activates the postfix-resolvconf.service unit, which runs
/etc/resolvconf/update-libc.d/postfix, which copies /etc/resolv.conf
to the chroot directory and reloads postfix.
Please don't do this. I want to understand what's going on, what's
your environment where it doesn't work.
So this could solve the issue, but might yield a race condition
with other scripts like /etc/network/if-up.d/postfix when run
(e.g. postfix might be reloaded while the resolv.conf target is
temporarily empty due to the cp from the other script).
No, there should be no race conditions here. But if we enable
this service, we wont be able to fix the root problem. This
service is a last resort really.
And there are hooks for NetworkManager which should - in theory -
update resolv.conf in postfix when things changes. I wonder why
they don't run.
I do not see any hook under /etc/NetworkManager. But AFAIK, it
is up to the postfix package to provide hooks (like it does for
/etc/network/if-*.d and ppp).
Nothing uses ppp hooks besides ppp itself, ok.
For /etc/network/if-*.d, - NetworkManager does run the hooks from
there, it seems like -- see #1054064 asking to switch to nm-specific
hooks and with the info about current state.
But I *guess* it doesn't execute hooks on dhcp changes when the iface
stays up, exactly as you noted above.
I think I'll have to install N-M somewhere to see how it works.
BTW, even with no chroot in postfix involved, postfix has to be
reloaded to re-read /etc/resolv.conf. So this is a more general
issue than chroot. Though without chroot it isn't that obvious,
since all postfix daemons will eventually exit and be re-started,
to re-read new resolv.conf.
Thank you for working with me on this. Hopefully we will be able
to find and fix the root cause.
/mjt
