Bug#854475: postfix: systemd needs postfix at .service to have "After=network.target"

[Michael Biebl]

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 at .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 at .service units have started up. For that
postfix at .service should have
Before=postfix.service.


> postfix at .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 at .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 at .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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170514/05fea96d/attachment-0002.sig>