Am 08.05.2017 um 16:18 schrieb Michael Biebl: Hi,
> I'm missing context here. Can you go into more detail please? What exactly is > the question here? Sorry. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854475 is about several issues with postfix being started before the network is up, failing to bind specific IPs or copying an empty resolvconf managed /etc/resolv.conf into its chroot on startup. This is happening since postfix ships native systemd units. Postfix ships postfix.service https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.service/ (oneshot, ExecStart=/bin/true, After=network.target postfix@.service https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix%40.service/) (forking, PartOf=postfix.service, NO After=network.target) Additionally a snipped in postinst drops an override in /etc in the standard case of having systemd-resolved installed (not necessarily used) and the configuration being a somehow managed standard configuration. It adds additional After= dependencies for postfix.service on network-online.target and systemd-resolved.service https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.postinst/#L650 https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.postinst/#L185 It also ships a generator that directly links postfix@ instances into the WANTDIR postfix-instance-generator https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix-instance-generator/ Scott's question was why the After=network.target (and the additional ordering statements added by the override) of postfix.service isn't enough to ensure proper ordering on startup. If I understand this correctly the generator will independently start the postfix@.service instances. The PartOf=postfix.service does not affect ordering at all. So for a proper fix the additional After= tweaks need to be added to postfix@.service, not just postfix.service Bernhard