After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 682375 - ifupdown-plugin: /etc/network/interface seems to be read in only at start/restart of NM
ifupdown-plugin: /etc/network/interface seems to be read in only at start/res...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: Distro-specific
unspecified
Other All
: Normal enhancement
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-08-21 17:06 UTC by Christoph Anton Mitterer
Modified: 2020-11-12 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christoph Anton Mitterer 2012-08-21 17:06:36 UTC
Hi.

The ifupdown plugin of NM seems to read in /etc/network/interfaces only at start/restart.

Thus any new connections are not shown (and perhaps for the old ones, old settings are used, if they got changed).


Cheers,
Chris.
Comment 1 Pavel Simerda 2012-08-24 15:16:08 UTC
You should always include 'expected behavior' in bug reports. Afaik in this respect NetworkManager behaves exactly the same way as ifupdown.

See also bug 671752.
Comment 2 Christoph Anton Mitterer 2012-08-24 18:06:16 UTC
(In reply to comment #1)
> You should always include 'expected behavior' in bug reports.
Ok, sorry, though it was clear what I expect ;)

I think the file should be monitored with e.g. inotify, and on changes re-read.


> Afaik in this
> respect NetworkManager behaves exactly the same way as ifupdown.
Don't think so...
What's _not_ updated by ifupdown (and I guess this is what you mean) are already enabled (up) connections; which is obviously good.

But when you next time say ifup <new-interface> it will know it; after all, ifupdown is no deamon.

With NM that's different: You add a new interface, but you won't see it.
And (though I haven't verified this), I guess it also doesn't use changed parameters (again I do not mean it should modify currently enabled connections).

Consider I have a wlan0.
1) It was enabled by NM (via ifupdown-plugin).
2) I change the parameters for wlan0. Now NM should leave the enabled connection as is.
3) I stop the connection in NM.
4) I restart the connection in NM. Now it should use the changed parameters.


Cheers,
Chris.
Comment 3 Pavel Simerda 2012-08-28 10:10:37 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > You should always include 'expected behavior' in bug reports.
> Ok, sorry, though it was clear what I expect ;)
> 
> I think the file should be monitored with e.g. inotify, and on changes re-read.
> 
> 
> > Afaik in this
> > respect NetworkManager behaves exactly the same way as ifupdown.
> Don't think so...

OK, thanks for the information.

> What's _not_ updated by ifupdown (and I guess this is what you mean) are
> already enabled (up) connections; which is obviously good.
> 
> But when you next time say ifup <new-interface> it will know it; after all,
> ifupdown is no deamon.
> 
> With NM that's different: You add a new interface, but you won't see it.
> And (though I haven't verified this), I guess it also doesn't use changed
> parameters (again I do not mean it should modify currently enabled
> connections).
> 
> Consider I have a wlan0.
> 1) It was enabled by NM (via ifupdown-plugin).
> 2) I change the parameters for wlan0. Now NM should leave the enabled
> connection as is.
> 3) I stop the connection in NM.
> 4) I restart the connection in NM. Now it should use the changed parameters.

Any patches to match NM's behavior to original ifupdown?
Comment 4 Dan Winship 2013-05-02 15:55:08 UTC
NM bugzilla reorganization... sorry for the bug spam.
Comment 5 André Klapper 2020-11-12 14:28:04 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).