Bug 1311469

do you have a slave-device that is autoconnect=yes?

Activating a slave obviously brings up the master too. Same for auto-activating a slave.

and do not see how it's obvious - they are slaves, right?
If I remember correctly I had to change master

connection.autoconnect-slaves:          1 (yes)

from default(-1) because device would not initialize.
And if remember correctly then that master ordered the slaves on this occasion, must have changed their autoconnect - if I remember correctly, but probably very easy for devs to reproduce - if true then it's confusing & inconsistent.

(In reply to lejeczek from comment #3)
> and do not see how it's obvious - they are slaves, right?

A slave cannot be activated without a master.



> If I remember correctly I had to change master
> 
> connection.autoconnect-slaves:          1 (yes)
> 
> from default(-1) because device would not initialize.

connection.autoconnect-slaves is a property of the master connection, and indicates that when the master activates, it will also activate the slaves.

The question is, whether you have any slave connections with "connection.autoconnect yes".

> And if remember correctly then that master ordered the slaves on this
> occasion, must have changed their autoconnect - if I remember correctly, but
> probably very easy for devs to reproduce - if true then it's confusing &
> inconsistent.

What do you mean is confusing and inconsistent? Modifying connection.autoconnect-slaves does not "change [the slaves] autoconnect", as you can see via `nmcli connection show $SLAVE_CONNECTION`.

All I'm trying to say, to suggest is that slaves should (only in this context naturally) behave as ones, which is do what master says.

(In reply to lejeczek from comment #5)
> All I'm trying to say, to suggest is that slaves should (only in this
> context naturally) behave as ones, which is do what master says.

Sorry, I don't understand what you mean.


The point is, that the issue that you describe (team device autostarts even with connection.autoconnect: no) could be explained by the configuration of your slave.

Please ensure that the "connection.autoconnect" setting of all your slave connections is "no". Can you verify that?

Otherwise, please also attach `journalctl -b 0 -u NetworkManager` of your last boot.


Thank you.

if master says "autoconnect no" then slave should obey, should not matter what they have to say.
Like you said "connection.autoconnect-slaves is a property of the master connection, and indicates that when the master activates, it will also activate the slaves." and this logic (given that connection.autoconnect-slaves:          -1 (default) , I don't need to consider other, user set values for now) should extend and it all should be govern my master's autoconnect - if master does autoconnect Not so should Not the slaves.
But it's ok, no point debating it over, lets close this report.

(In reply to lejeczek from comment #7)
> if master says "autoconnect no" then slave should obey, should not matter
> what they have to say.
> Like you said "connection.autoconnect-slaves is a property of the master
> connection, and indicates that when the master activates, it will also
> activate the slaves." and this logic (given that
> connection.autoconnect-slaves:          -1 (default) , I don't need to
> consider other, user set values for now) should extend and it all should be
> govern my master's autoconnect - if master does autoconnect Not so should
> Not the slaves.
> But it's ok, no point debating it over, lets close this report.


A slave cannot connect without also activating the master. Activating a slave always activates the master too -- regardless, whether the slave was activated by explicit user-decision or whether the slave auto-activated.

autoconnect=no on the master does not mean that slaves are forbidden to autoconnect.
That does not follow from "connection.autoconnect-slaves is a property ..."


According to your expectation, the connection.autoconnect property of the slave would be always overruled by the master's configuration.
With the current setup you could have:

   eth0
     connection.autoconnect=yes
   eth1
     connection.autoconnect=no
   master0
     connection.autoconnect=yes

and at startup only eth0 gets enslaved. You cannot achieve the same with your interpretation.


Also, connection.autoconnect-slaves is still useful:

   eth0
     connection.autoconnect=no
   eth1
     connection.autoconnect=no
   master0
     connection.autoconnect=no
     connection.autoconnect-slaves=yes

now, nothing gets activated at boot, but once you activate the master, it's slaves are activated too.

I understand what your are saying, I see how it behaves, it's fine. I thought wrong, I only think it looks, sounds silly - when master autoconnect=no yet gets up only because one missed a slave, yes should be overruled in my mind.
thanks.