On Fri, Feb 15, 2013 at 1:26 PM, Thomas Bächler <[email protected]> wrote: > Am 15.02.2013 13:11, schrieb Jouke Witteveen: >> On Fri, Feb 15, 2013 at 1:08 PM, Thomas Bächler <[email protected]> wrote: >>> Am 15.02.2013 12:43, schrieb Jouke Witteveen: >>>> Another option is to add everything to network.target.wants. >>> >>> Nope. network.target is not started by default and is quite mysterious >>> anyway. >> >> It is perhaps more understandable if network.target just wants all >> activated network configurations and multi-user.target wants >> network.target. > > This isn't the case. network.target is ONLY activated when any service > has Wants=/After=network.target to synchronize itself after the network > start. All network services ususally have Before=network.target, without > Wants= or Requires=. In short, network.target is only used as a > synchronization point for services that require the network to be up.
This implies we should drop Wants=network.target from [email protected] and [email protected]. >>>> Although >>>> that might be a better place, it doesn't really solve the initial >>>> problem. On the other hand: what is precisely the problem: the unit >>>> just times out and is not supposed to block anything. >>> >>> How is that related to the topic? >>> >> >> Part of the problem of Ivan Shapovalov I do not understand. If a >> profile is enabled and the interface does not appear, this should not >> delay anything. > > If a network interface doesn't appear and a network profile using it is > activated, the service will wait for it until a timeout. This blocks the > completion of multi-user.target. This likely won't be visible, but is > undesirable. > Is this a consequence of DefaultDependencies=true (by default)? Otherwise, the netctl units do not enforce an ordering with regard to multi-user.target.
