diff options
author | Lubomir Rintel <lkundrak@v3.sk> | 2017-01-25 13:27:16 +0100 |
---|---|---|
committer | Lubomir Rintel <lkundrak@v3.sk> | 2017-01-25 13:36:30 +0100 |
commit | b605fb27120cf6c8ac44d4a57e3f19e5ce0f69ed (patch) | |
tree | 7078d2cae73a8d91aa5db16f0331e0bac989bef4 /src | |
parent | 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9 (diff) | |
download | NetworkManager-b605fb27120cf6c8ac44d4a57e3f19e5ce0f69ed.tar.gz |
manager: don't let a master device go unmanaged on a slave activation
If a slave device activates, we should keep the master up even though it
was taken over before.
This fixes an issue, where a single slave to a master would be
reactivated after a daemon restart. The daemon restart would cause the
master to be treated externally created (would go unmanaged when all the
slaves are gone) while the reactivation would leave the master without
slaves for a while.
Diffstat (limited to 'src')
-rw-r--r-- | src/nm-manager.c | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/src/nm-manager.c b/src/nm-manager.c index 867e0db6d8..0c1d36e1f6 100644 --- a/src/nm-manager.c +++ b/src/nm-manager.c @@ -3122,6 +3122,13 @@ _internal_activate_device (NMManager *self, NMActiveConnection *active, GError * } } + /* Now that we're activating a slave for that master, make sure the master just + * decides to go unmanaged while we're activating (perhaps because other slaves + * go away leaving him with no kids). + */ + nm_device_set_unmanaged_by_flags (master_device, NM_UNMANAGED_EXTERNAL_DOWN, + NM_UNMAN_FLAG_OP_FORGET, NM_DEVICE_STATE_REASON_USER_REQUESTED); + nm_active_connection_set_master (active, master_ac); _LOGD (LOGD_CORE, "Activation of '%s' depends on active connection %p %s", nm_settings_connection_get_id (connection), |