[arch-projects] [netctl][PATCH] Support dynamically appearing interfaces

Thomas Bächler thomas at archlinux.org
Fri Feb 15 08:02:17 EST 2013

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20130215/7b4c145e/attachment.asc>

More information about the arch-projects mailing list