Control: reopen -1 [Replying to an old bug report]
On Sat, 15 Apr 2017 21:14:03 +0200 Christian Schrötter <c...@fnx.li> wrote:
Are you sure network.target is enough? network-online.target sounds much better for me.
[The context is that postfix.service should not start before network.target (because three's no way to bind to non-existing network interfaces), or maybe network-online.target] Dependency on network-online.target is, unfortunately, wrong. Quite a few services depends on it, and all of them which I've seen, are doing it wrong in one way or another. There are really numerous ways how this can be screwed up. network-online.target is very vaguely defined, because there's no good definition for this. And more, this "network is online" state might depend on several external factors (presence of known WIFI network with airplane mode turned off on a laptop, for example). Do we need to delay users logons because some service which is a part of some system target is waiting for a network to be online? I've seen multiple cases like this, when you can't login to and use your laptop unless you give it a known wifi (because you can't login to connect it to unknown). This is nuts. If we're to depend on network-online, we have to ensure the user system does have proper definitions of all network interfaces (properly marked with RequiredForOnline= or in other ways), which almost no one actually does. Even dependency on network.target is wrong. It is only needed when postfix is configured to bind to specified ifaces and not needed if not. But even if we mark postfix as dependent on network.target, we still can't assume the interface(s) in question are configured when the postfix is started. Depending on the setup, it might be delayed. Look at the description of network.target in systemd.special: they explicitly note that network.target does not mean IP configuration is available, but also that physical interfaces might not be up yet (only synthetic interfaces are available, but not necessary with IP addresses). So we've very small chance here to have defined IP config in there. Imagine an interface which gets its configuration over DHCP, and which might change during runtime, it's kinda tempting to specify this one in network_interfaces too, in a hope postfix will follow the address. The proper solution here, I think, would be to explicitly mark postfix service as depending on particular interface(s) to be fully up when these ifaces are used in network_interfaces. This can be done by the user, or this can even be done automatically, by the startup procedure, which parses network_interfaces and adds appropriate transient overrides - with PROPER STATE of the network interfaces too. This is the only real solution I see for the issue. As for the original issue with empty resolv.conf - this is a different issue entirely. We don't have an actually working mechanism to propagate resolv.conf into the chroot still, after 25 years of using postfix in debian. And *this* is what needs to be addressed, instead of adding more band-aids on top of band-aids. I'm reopening this one, though it has 2 different issues in one. Thanks, /mjt
