Am 15.02.2013 13:31, schrieb Jouke Witteveen: > 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].
Indeed, it's unnecessary. >> 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. Ordering on targets is implied by DefaultDependencies, yes. IMO, we should not override this. Loading a profile on an interface that doesn't exist is incorrect behaviour, we should not encourage it.
signature.asc
Description: OpenPGP digital signature
