Skip to content

manager: don't bring up master connections on devices that are not disconnected

Lubomir Rintel requested to merge lr/master-autoactivate into main

Otherwise we're likely interfering with an in-progress activation. Consider the following connections, first two being active:

id=bond0a type=bond interface-name=bond0, (Active) id=dummy0a type=dummy interface-name=dummy0 master=bond0a, (Active) id=bond0b type=bond interface-name=bond0 id=dummy0b type=dummy interface-name=dummy0 master=bond0b

Note there's two hierarchies with bond0 bond having a dummy0 port, first one (bond0a, dummy0a) being active.

Suppose the users wants to bring the other one up (bond0b, dummy0b) and does a "nmcli c up bond0b". This is what happens:

1.) bond0b starts activation due to user request 2.) bond0a starts deactivation due to new activation 3.) dummy0 loses its master, begins deactivation 4.) dummy0 finishes deactivation 5.) both dummy0 being deactivated and bond0b check for slaves enqueues auto-activation check for dummy0 6.) auto-activation picks dummy0a for dummy0 7.) dummy0a begins activation 8.) dummy0a looks for master connection, picks bond0a 9.) bond0a starts activating on bond0, kicks bond0b away 10.) bond0a and dummy0a end up finishing activation 11.) Everybody unhappy :(

NM's auto-activation logic is only takes autoconnect priority into account when figuring out a connection to activate and can't be expected to bring up most sensible combination of connection when there's multiple ones for the same devices with complex dependencies.

Nevertheless, it shouldn't ever undo the activations if the user is bringing up the connections manually.

This patch prevents bringing up of master devices that are not DISCONNECTED and therefore shouldn't be up for grabs. This was previously done for hardware devices only whereas I believe it should be the case for all realized devices.

Edited by Lubomir Rintel

Merge request reports