On Sun, Apr 12, 2015 at 02:12:06PM -0700, [email protected] wrote: > Hi > > On Sun, Apr 12, 2015, at 02:08 PM, Cameron Norman wrote: > > It's probably just a race that you see with the bridge because the > > bridge is up at a later time than the ethernet device. > > I guess that's kindof the point here. > > Using network.target and network-online.target doesn't apparently cause a > unit's exec to wait for the race to resolve, and for the specific bridge(s) > to be up. > > If those targets don't, is there one that does? It was already pointed out by Lennart above in this thread, but let me try again:
network-online.target provides a point after which servcies can be ordered, but it is up to individual services which bring up the network (e.g. NetworkManager, systemd-networkd, ...) to order themselves before this target. The target by itself is meaningless, it needs support from the servcie managing the network. Like Reindl and others pointed out above, waiting for the network to be "up" is in general the wrong thing to do. IP_FREEBINDand/or listening on 0.0.0.0. are much better solutions. But if you really want the ordering, figure out what needs to be done for the network managing service that you are using to do this. For example, for NetworkManager you need to enable NetworkManager-wait-online.service, for systemd-network you need to enable systemd-networkd-wait-online.service, etc. Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
