GNOME Bugzilla – Bug 731277
core: when creating and removing interfaces externaly, active connection objects are not removed
Last modified: 2014-06-06 14:28:06 UTC
I have found that when you create a software device and NM activates a connection on it, and then you delete the device NM doesn't remove the active connection object. And it will still refer to a non-existing device. First I saw that for virbr0, then Thomas also reproduced this by running platform tests. Invalid active connections keep piling. The simplest reproducer would be: # ip link add name BBB type bridge and # ip link del BBB and check active connections with $ nmcli con sh -a See jk/dev-remove-fix branch for a fix - the first commit is the fix - the is also a commit adding ifindex to log messages, because it helps to distinguish what device we are dealing with. - and also a fix for libnm-glib
Created attachment 277961 [details] Some debugging information
*** This bug has been marked as a duplicate of bug 729833 ***
Bug already duped, but anyway: >> libnm-glib: fix double unref() when object creation fails I think this is obviously correct(?) (I wouldn't mind if you merge it earlier, as it fixes a bug). >> core: log ifindex in addition to interface name (trivial) I don't think that this is a trival patch :) "trival" in my understand means: "does not change the program run in any possible way, yes, really, it doesn't!!" In general I very much agree with this patch (in what it does). But I would not do it this way. Instead I proposed already earlier, see th/logging (http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f553c61db00adfd2b6939be4a67312c9fa46df3b) -- I thought I also opened a bug for that, but cannot find it ATM. I would drop this patch, and do it properly later in th/logging. >> core: transition removed devices into unmanaged is this correct? For assumed connection, NM should not touch the interface. Ok, the interface is probably already gone, but how about other unwanted changes? btw. I think, this has high priority
For the logging patch in this branch, it might kill me to have to rebase dcbw/dispatcher-blocking on top of that; could we hold off on doing anything there until that gets merged?
(In reply to comment #4) > For the logging patch in this branch, it might kill me to have to rebase > dcbw/dispatcher-blocking on top of that; could we hold off on doing anything > there until that gets merged? Sure. I just did it as it helped in debugging. But we can leave the logging for later, sync with Thomas stuff.