On Fri, Apr 10, 2015, at 05:54 PM, Mantas Mikulėnas wrote:
> By itself, if I remember correctly, network-online.target doesn't wait
> for *anything;
> *it needs the provider-specific services to also be enabled, like
> NetworkManager-wait-online.service (similarly for systemd-networkd and
> ifupdown).
Not completely sure of the details, but it seems to provide the right
dependency for services like sshd, and firewall(s), unlike network.target
doesn't always.
"network-online.target
Units that strictly require a configured network connection should pull in
network-online.target (via a Wants= type dependency) and order themselves after
it. This target unit is intended to pull in a service that delays further
execution until the network is sufficiently set up. What precisely this
requires is left to the implementation of the network managing service.
Note the distinction between this unit and network.target. This unit is an
active unit (i.e. pulled in by the consumer rather than the provider of this
functionality) and pulls in a service which possibly adds substantial delays to
further execution. In contrast, network.target is a passive unit (i.e. pulled
in by the provider of the functionality, rather than the consumer) that usually
does not delay execution much. Usually, network.target is part of the boot of
most systems, while network-online.target is not, except when at least one unit
requires it. Also see Running Services After the Network is up for more
information.
All mount units for remote network file systems automatically pull in this
unit, and order themselves after it. Note that networking daemons that simply
provide functionality to other hosts generally do not need to pull this in.
"
There's a lot of chatter for example of the need for early init of Shorewall,
on their list.
So though not clear on the real-intfc-only case, it's clearly not enough of a
dependency check when the bridge interface comes into play.
Wondering if simply adding an "After=after-local.target" -- i.e. the latest
unit trigger I'm aware of -- to the sshd deps is the right way to go here.
Seems a blunt instrument, but it does work.
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
