Am 15.02.2013 13:31, schrieb Jouke Witteveen:
On Fri, Feb 15, 2013 at 1:26 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.02.2013 13:11, schrieb Jouke Witteveen:
On Fri, Feb 15, 2013 at 1:08 PM, Thomas Bächler <thomas@archlinux.org> 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 netctl@.service and netctl-auto@.service.
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.