Hi everyone, a couple of comments inline
Am 08.05.2017 um 16:47 schrieb Bernhard Schmidt: > 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 So postfix.service is a dummy service. You actually would want a target to group several services together. I notice though, that your postfix@.service has ReloadPropagatedFrom=postfix.service. This does indeed not work for .targets atm [1]. So such a dummy service is the best you can do. That said, what you usually want is that systemctl start postfix.service is only marked as started once all instanced postfix@.service units have started up. For that postfix@.service should have Before=postfix.service. > 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's rather odd to have that After= ordering generated via a drop-in and have that applied to the dummy service. You really would want to apply that to the unit starting the real service, especially given my comment above that you want postfix@.service have a Before=postfix.service. I probably also wouldn't bother generating the network dependency dynamically. After all, a user could modify the postfix config without using dpkg-reconfigure. So you probably just want to use that unconditionally. As for network.target vs network-online.target, please read https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ and man systemd.special network.target is a so called passive target which is activated once your network configuration has started. It doesn't actually mean that your interfaces have been configured. After=network.target is thus mostly interesting on shutdown, when you want to ensure your service is stopped before the network configuration is stopped. What you probably want is After=network-online.target Wants=network-online.target network-online.target is an active target, which needs to be pulled in explicitly by the consumer, thus the Wants=. For ifupdown network.target and network-online.target are mostly the same (it basically just runs ifup -a) and that only includes interfaces of type auto. allow-hotplug is currently not hooked up in network-online.target/network.target in any way. For other network configuration systems, the situation is different, take NetworkManager. network.target for NetworkManager simply means, that NetworkManager.service, ie. the NetworkManager daemon has started. It doesn't say anything about configured interfaces which are dynamically actived by NetworkManager network-online.target for NetworkManager means that NetworkManager-wait-online.service has run. This is a service which waits until nm-online reports an active connection (see man nm-online). I suppose one of the bug reporters was using ifupdown with interfaces of type auto. That's why After=network.target was sufficient for him. As for systemd-resolved, I can't really comment on that why that's necessary. At least that comment is wrong for Debian though: > # If using systemd without systemd-resolved, you're on your own. We do *not* enable systemd-resolved in Debian by default, so I don't think this actually fixes something in Debian, the situation might be different for Ubuntu. The comment in postinst says, that you need DNS resolution. That's what usually nss-lookup.target is for, which translates to $named in SysV. I notice that the old SysV init script has Required-Start: $named, which would translate into a After=nss-lookup.target ordering. With that all said, this would be my recommendation: - debian/postfix.postinst: drop the postfix.service.d/override.conf and make sure to remove that conffile on upgrades - postfix.service: Drop After=network.target - postfix@.service: Add the following PartOf=postfix.service Before=postfix.service ReloadPropagatedFrom=postfix.service After=network-online.target nss-lookup.target Wants=network-online.target - debian/postfix.postinst: drop the postfix.service.d/override.conf and make sure to remove that conffile on upgrades If you have further questions, please ask. Regards, Michael [1] https://github.com/systemd/systemd/issues/710 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
