Bug 741984

Created attachment 525375 [details]
bootchart showing multiple nmcli processes being spawned

That's the way how it works. When you click on a network in nm-applet, the profile is created with ONBOOT=yes, so it can be activated automatically next time. I think the same applies for the GnomeShell indicator.
However, the profile is not automatically created without user interaction (except for a bug in GnomeShell - see bug 717665)
So when you don't want profiles to be created don't click on networks or remove undesired connections with editor. You are always free to edit connection profiles via nm-connection-editor to your needs as well.

I understand, but then perhaps ONBOOT is not the right indicator and a new one should be invented.  The user shouldn't waste boot time waiting for NetworkManager to try the SSIDs for every airport or cafeteria that they have ever visited---especially considering that in all likelihood the wireless card hasn't even finished scanning at the time /etc/init.d/network runs.

Created attachment 525543 [details]
patch posted upstream

Didn't mention that the 3 seconds are with wireless *disabled* (offline mode).  For wireless enable, that goes up by a factor of ~100 thanks to bug 742292.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

(In reply to comment #3)
> I understand, but then perhaps ONBOOT is not the right indicator and a new
> one should be invented.  The user shouldn't waste boot time waiting

You have a point. ONBOOT and AUTO (or something like that) should be IMO separated (missing AUTO defaulting to ONBOOT value for compatibility). This, together with nm-wait-online or similar tool waiting for the NM boot process to finish instead of waiting for a single good connection, would greatly improve systemd integration.

> for
> NetworkManager to try the SSIDs for every airport or cafeteria that they
> have ever visited

But nobody currently waits for NetworkManager to boot and NetworkManager doesn't even try every SSID before scanning is done.

Closing because current behavior doesn't cause any delays and it will be taken into account if it's going to change.

> But nobody currently waits for NetworkManager to boot and NetworkManager 
> doesn't even try every SSID before scanning is done.

NetworkManager doesn't, but network.service does.  Using ONBOOT means that *network.service* will try all SSIDs and make boot slow.  Still, the bug is in NetworkManager who is abusing ONBOOT.

That said, it's been a while since I actually tried this, as I have now disabled network.service for quite some time.

(In reply to comment #7)
> (In reply to comment #3)
> > I understand, but then perhaps ONBOOT is not the right indicator and a new
> > one should be invented.  The user shouldn't waste boot time waiting
> 
> You have a point. ONBOOT and AUTO (or something like that) should be IMO
> separated (missing AUTO defaulting to ONBOOT value for compatibility). This,

Disagree.  ONBOOT is the same thing as "autoconnect me".  There's no valid use-case for "automatically connect to this network at boot time, but *don't* automatically connect to it at any other time" which is what separating ONBOOT and AUTO would do.

The network service is not a daemon and had no concept of connecting to networks when they are available, thus it can only try every single configured network you've got.  This is a deficiency of the network service, because that's just the way the network service is.  And NetworkManager isn't going to separate ONBOOT just to placate the less capable network service.

Second, the network service can't handle WPA or Dynamic WEP networks anyway, so most of the connections people actually use these days simply won't work with it.  Arguably the network service should ignore any ifcfg file that is for WPA or has 802.1x keys, which would probably help your bootup speed.

(In reply to comment #9)
> (In reply to comment #7)
> > (In reply to comment #3)
> > > I understand, but then perhaps ONBOOT is not the right indicator and a new
> > > one should be invented.  The user shouldn't waste boot time waiting
> > 
> > You have a point. ONBOOT and AUTO (or something like that) should be IMO
> > separated (missing AUTO defaulting to ONBOOT value for compatibility). This,
> 
> Disagree.  ONBOOT is the same thing as "autoconnect me".  There's no valid
> use-case for "automatically connect to this network at boot time, but
> *don't* automatically connect to it at any other time" which is what
> separating ONBOOT and AUTO would do.

Let's move the discussion to:

https://bugzilla.redhat.com/show_bug.cgi?id=816655#c12

There's more information for this suggestion.

I think the two bugs are different.  This is an interoperability bug with network.service.

> This is a deficiency of the network service, because that's just the way the 
> network service is.  And NetworkManager isn't going to separate ONBOOT just to > placate the less capable network service.

Sure.  But ifcfg is the network service's file format, and NetworkManager is using it.  If network manager means auto rather than on-boot, it must use a separate key and perhaps set ONBOOT when it makes sense (e.g. for eth0).

> Second, the network service can't handle WPA or Dynamic WEP networks anyway, 
> so most of the connections people actually use these days simply won't work 
> with it.

Captive portals (airports, hotels, coffee shops, etc.) still use open networks a lot.

(In reply to comment #11)
> I think the two bugs are different.

The reference to other bug was meant as a short answer to Dan Williams's remark.

> This is an interoperability bug with network.service.

The problem, as you described it, doesn't IMO happen with NetworkManager at all as there is no separate booting time and nobody is waiting for NetworkManager to finish all ONBOOT=yes connections.

> > This is a deficiency of the network service, because that's just the way the 
> > network service is.  And NetworkManager isn't going to separate ONBOOT just to > placate the less capable network service.
> 
> Sure.  But ifcfg is the network service's file format, and NetworkManager is
> using it.  If network manager means auto rather than on-boot, it must use a
> separate key and perhaps set ONBOOT when it makes sense (e.g. for eth0).

There is currently no such distinction in ifcfg, nor in NetworkManager. And only /etc/init.d/networks indicate that it finished the booting stage (by simply exitting), NetworkManager doesn't do that. Therefore no service and no application can specifically wait for all ONBOOT connections to be tried.

If you think there should by such a possibility, you can file a bug report upstream for that or wait whether someone else does it.

> > Second, the network service can't handle WPA or Dynamic WEP networks anyway, 
> > so most of the connections people actually use these days simply won't work 
> > with it.
> 
> Captive portals (airports, hotels, coffee shops, etc.) still use open
> networks a lot.

Still NetworkManager handles them better, as it can use scanning results to choose the connection :).