s/upstream/downstream/ :)

I don't see a compelling use-case for having an interface automatically started at boot time, but not automatically started after boot.  Likewise, I'm not sure why you'd have an interface to be automatically started after boot, but not at boot.

In any case, if you enable wait-online, NM blocks until at least one interface has connectivity.  Are you suggesting that a user may have two interfaces, one for a private network, and one for an upstrea network, and that wait-online should only wait for the upstream network or something?  If that's the case, there are better ways to make that happen (and it's already handled if the user sets the private network as never-default=true).

The only case where splitting onboot from autoconnect would speed up booting would be if *no* interfaces had connectivity at boot time, but you still wanted them to autoconnect after boot.  Otherwise, this is already handled by NM AFAICT.

(In reply to comment #2)
> I don't see a compelling use-case for having an interface automatically started
> at boot time, but not automatically started after boot.

This case is not the prominent one, but there still may be use cases at the administrator's discretion. Usually, when a setup is expected to succeed at boot, you don't care about it later.

The typical onboot=yes connection would stick with the default (auto same as onboot).

> Likewise, I'm not sure
> why you'd have an interface to be automatically started after boot, but not at
> boot.

That's another story.

* An ethernet DHCP configuration that isn't necessary for basic system services (e.g. when the administrator knows that all services either bind to wildcard address, or can cope with dynamic changes).

* A USB ethernet device that isn't (or may not) be connected at boot time.

* A wireless connection that needs scanning and shouldn't delay your boot time.

* Other removable network interfaces.

Basically any connection that you want autoconnected but that shouldn't block the boot process.

> In any case, if you enable wait-online, NM blocks until at least one interface
> has connectivity.  Are you suggesting that a user may have two interfaces, one
> for a private network, and one for an upstrea network, and that wait-online
> should only wait for the upstream network or something?

This is one of the many use cases. The whole idea is about properly supporting the ifcfg's ONBOOT=yes and equivalents. Currently we don't support blocking the /etc/init.d/network or network.service until *all* ONBOOT=yes connections are up and running, failed or timed out. Therefore we effectively violate backwards compatibility with ifcfg.

> If that's the case,
> there are better ways to make that happen (and it's already handled if the user
> sets the private network as never-default=true).

This is about network dependencies, not about default interface selection, that's another topic that could see improvements but...

> The only case where splitting onboot from autoconnect would speed up booting
> would be if *no* interfaces had connectivity at boot time, but you still wanted
> them to autoconnect after boot.

Not limited to that at all.

> Otherwise, this is already handled by NM
> AFAICT.

My view on this is very simple. The former ifcfg scripts guarantee that all ONBOOT=yes connections are connected or failed trying. NetworkManager doesn't fulfil that guarantee and should be modified to be able to do that.

The current nm-wait-online waits for the *first* AUTO connection. The original behavior was to wait for *all* ONBOOT connections. This difference is fatal. As ifcfg's ONBOOT=yes specifies a set of connections that are guaranteed to be tried (and often expected to succeed) and this set can have zero, one or multiple member connections, nm-wait-online simply fails to provide this behavior.

There may be some specifics I don't know about even in the old ifcfg scripts and I can stand corrected. But the basic idea comes from Michal Schmidt and I very much agree with it:

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

Yes, agreed that NM-wait-online doesn't exactly duplicate the old ONBOOT/sysv initscript behavior.  We can change that, but we should also try to figure out what people actually use the boot-time behavior for, and if they really do a lot of complicated stuff with it.

I'm also of the opinion that things that require network connectivity should actually specify *what* they require,  instead of saying "hey I want a network".  If you bind to * then yes you want something, but you're not saying *what* you want and that doesn't help make the system smarter.  eg, if apache wants some IP address, then there should be a mechanism for the startup scripts to say "I need 192.168.1.1" instead of "I need a network", since then you can guarantee that apache will fail if it doesn't get what it wants.  But I digress, back to the actual topic...

I'm thinking more about complexity versus gain here.  If we can do this in a way that gives most of the behavior that people actually use when they want network interfaces up on boot, but we don't have to add new properties or new "startup modes", that's a win, both in code and in terms of complexity of configuring NM for users.  Which is why I'm interested in how people actually use ONBOOT.

One option is to simply modify nm-wait-online to be more like what people want, possibly with some configuration of its own that it looks at to be smarter about what blocks and what doesn't, like allowing the administrator to specify that nm-wait-online should block only for eth0 but not for wlan0.

In the end, NM doesn't know or care much about startup, because it might be executed in many different contexts, and not just at startup time.  The auxiliary services like nm-wait-online and other initscripts are much more suited to make these sorts of policy decisions than NetworkManager is.  NM can help facilitate that, possibly by exposing passthrough type properties so that configuration is still done the same way, but I'm not sure it should actually apply policy based on system boot states or anything like that.

(In reply to comment #4)
> We can change that,

Change that or replace the whole thing.

> but we should also try to figure out
> what people actually use the boot-time behavior for, and if they really do a
> lot of complicated stuff with it.

Actually, my proposal follows directly from the specified needs. People want to use their old & stupid daemons. Those daemons only work with network already set up. Administrators are sane enough to know which configurations are required for their services.

They don't actually do *any* complicated stuff, they just want to have all of their *required* connections either successfully set up or failed with a good reason before the old daemons are started.

> I'm also of the opinion that things that require network connectivity should
> actually specify *what* they require,

We all are of that opinion, but let's face the reality. We're talking specifically about services which say: “Hey, I want network, as it is specified by the administrator.”

> instead of saying "hey I want a
> network".  If you bind to * then yes you want something, but you're not saying
> *what* you want and that doesn't help make the system smarter.

This bug report is not about solving the smart case but about solving the dumb case. The smart case is already more or less handled by the D-Bus signalling.

> eg, if apache
> wants some IP address, then there should be a mechanism for the startup scripts
> to say "I need 192.168.1.1" instead of "I need a network", since then you can
> guarantee that apache will fail if it doesn't get what it wants.  But I
> digress, back to the actual topic...

Agreed. That would be nice. You can do that with Apache e.g. by parsing its configuration file (or Apache itself could be modified). But this is more about software that either can't be modified, or whose modification is highly impractical for us. And I'm afraid such software will be still here during the next decade.

> I'm thinking more about complexity versus gain here.

Good.

> If we can do this in a
> way that gives most of the behavior that people actually use when they want
> network interfaces up on boot, but we don't have to add new properties or new
> "startup modes", that's a win, both in code and in terms of complexity of
> configuring NM for users.  Which is why I'm interested in how people actually
> use ONBOOT.

Feel free to ask them. But actually, on servers, this is pretty clear. They use it to mark connections that are required at startup. Whether a network service waits for the network itself or whether the launcher waits before starting a dumb service, that can be specified in the unit file.

I didn't test whether ONBOOT is consistent across all network types. But I'm pretty much sure 'auto' is not a good match for 'ONBOOT' in the server context.

> One option is to simply modify nm-wait-online to be more like what people want,
> possibly with some configuration of its own that it looks at to be smarter
> about what blocks and what doesn't, like allowing the administrator to specify
> that nm-wait-online should block only for eth0 but not for wlan0.

Possibly yes. But it will still be a workaround. AFAIK what administrators want is that the network service guarantees selected connections to be *considered* when booting (that doesn't mean they have to succeed) and, if possible, connected before network.target (or network-online.target) takes place to control the ordering.

> In the end, NM doesn't know or care much about startup, because it might be
> executed in many different contexts, and not just at startup time.

The same applied to the network scripts. Both are handled by the launcher (systemd in most cases) and thus the launcher can handle the external dependencies both at startup and at runtime.

> The
> auxiliary services like nm-wait-online and other initscripts are much more
> suited to make these sorts of policy decisions than NetworkManager is.

Possibly. But then, for compatibility, they should be able to know whether the connection is marked as onboot or not (in /etc/sysconfig/network when on Fedora). Conceptually, *onboot* usually implies *auto* but not the other way round. If the services wait for an auxiliary wifi connection when the main connection is already running, then there's something wrong.

> NM can
> help facilitate that, possibly by exposing passthrough type properties so that
> configuration is still done the same way,

This is more of an implementation detail. In my opinion, it will be a bit more difficult with an external tool, as it also needs to keep track of failed connections since NetworkManager start, but I'm currently more interested in having at least a basic notion of a solution, not the implementation itself.

> but I'm not sure it should actually
> apply policy based on system boot states or anything like that.

I described possible NetworkManager starting process. The dependency was the exact opposite. The system (the launcher) waits for NetworkManager, while NetworkManager doesn't care about the system. Why should it, after all?

Also, after seeing danw's wait-online branch, it might be OK to start all auto/onboot connections at once but only make nm-online (or similar) tool wait for onboot ones. Currently, danw is improving nm-online to [roughly] wait for all auto connections without the possibility to distinguish those not required for to finish during booting time.

"nm-online -s" does the right thing now. I don't think there's any compelling use case for splitting apart autoconnect and ONBOOT.

WONTFIX?

Yeah...

(In reply to comment #7)
> "nm-online -s" does the right thing now.

The manual page explicitly says that -s isn't there to wait for establishing a connection. That means it's entirely unrelated to this issue.

Created attachment 277294 [details] [review]
man: clarify the meaning of "nm-online --wait-for-startup"

Sounds good.

Or maybe one sentence, that once NM reaches "startup complete", it will not go back to this state again?

That's what I was aiming for with "this is generally only useful at boot time" but maybe it could be more explicit. How about:

  Wait for NetworkManager startup to complete. Startup is considered
  complete once NetworkManager has activated (or attempted to activate)
  every auto-activate connection which is available given the current
  network state. (This is generally only useful at boot time; after
  startup has completed, "nm-online -s" will just return immediately,
  regardless of the current network state.)

(In reply to comment #12)

Sounds good!!

Comment on attachment 277294 [details] [review]
man: clarify the meaning of "nm-online --wait-for-startup"

pushed as 84fd73b

This bug report is about supporting onboot connections. With the current versions of systemd, that means blocking network-online.target until all onboot connections are attempted and either successfully connected or failed.

I consider the distinction between 'onboot' and 'auto' part of a proposal from May 2013 on how to solve this, not really as a goal of this feature request.

(In reply to comment #12)
>   Wait for NetworkManager startup to complete. Startup is considered
>   complete once NetworkManager has activated (or attempted to activate)
>   every auto-activate connection which is available given the current
>   network state.

From these docs, I see that this bug can now be resolved by using 'nm-online -s' in NetworkManager-wait-online and I *now* even see that this solution has been used in the upstream git. Therefore I believe this feature request should be closed as RESOLVED/FIXED instead, as it now seems to have been fully implemented.

In my opinion, the support for auto connections that are not onboot (distinction between auto and onboot) wasn't part of the feature request but rather of a proposal on *how* to implement the feature (the part after "It could work in the following steps").

> (This is generally only useful at boot time; after
>   startup has completed, "nm-online -s" will just return immediately,
>   regardless of the current network state.)

Could you please verify this (reopening)? I'm testing it with a fairly recent git build and it won't work as described:

mole ~ # nm-online -s
Connecting..                26s

At the time of running the command, NetworkManager is running and connected to one wireless connection and one VPN (OpenVPN). I will provide more information as requested. Reopening.

nm-online -s works as expected, it's just that there's some bug on pavel's machine causing startup to never complete (which is a separate bug)

Steps to reproduce:

1) Start your system, wait for NM to connect

2) Run: ip link add testbridge type bridge

3) Run: nm-online -s

Reopening so it doesn't get lost, please close if a separate bugreport gets started.

adding a bridge after startup completes won't do anything; the problem is that startup isn't completing in the first place for you

Indeed. More testing proved that it wasn't the new bridge that caused it. Will file a new bug report when I get more information but that would be about a corner case. Under normal circumstances, 'nm-online -s' seems to work correctly. And NetworkManager-wait-online.target seems to work as well. In my opinion this is a great improvement to NetworkManager. Thanks for cooperation.

I'm looking at the following bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1183321

In my opinion it suggest that my original proposal might have been a better solution to the issue. In the original design, onboot and auto were two distinct properties.

Typical use cases:

 * onboot=yes auto=yes -> Connection is attempted at NetworkManager startup and the attempt blocks network-online.target. When, for some reason, it is not active, it can be automatically connected later. A typical connection required at boot time.

 * onboot=no auto=yes -> Connection can be automatically connected at any time but never blocks network-online.target. A typical connection not required at boot time but still automatically connected.

 * onboot=no auto=no -> Connection can be manually started. A typical connection for occasional use or special purpose.

Not so typical:

 * onboot=yes auto=no -> Almost like the first case except that it is only ever connected at NetworkManager startup or manually.

As seen above, all cases may be useful. Of course specific applications may wait for specific connection like Android apps do for example. But this proposal was designed to allow the system administrator to choose a single set of connections that are required at startup and that block services waiting on network-online.target.

Reopening:

there is also downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1183321



to quote myself:

networkd's wait-online supports (multiple) --interface options to specify which interfaces to wait for [1]. That might be a useful and nice feature...

OTOH, waiting for NM-wait-online is not encouraged, so it might not be worth investing in such a feature.

[1] http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html

This distinction between autoconnect and onboot (comment 21) is not only relevant for wait-online.

Actually, implementing onboot as suggested is only one way to do it. For example networkd is more flexible in that you can explicitly state:
  systemd-networkd-wait-online -i em1

In fact, I would prefer this flexibility instead of configuring per connection whether you want nm-online to wait for it.
But the onboot condition above is a good default if the user omits the nm-online -i arguments. 


An onboot distinction is anyway useful. Since NetworkManager 0.9.10, NM tries to assume a connection. At startup, the user might forcefully want to autoactivate a connection. For example, see https://mail.gnome.org/archives/networkmanager-list/2015-March/msg00000.html

(In reply to Thomas Haller from comment #23)
> This distinction between autoconnect and onboot (comment 21) is not only
> relevant for wait-online.
> 
> Actually, implementing onboot as suggested is only one way to do it. For
> example networkd is more flexible in that you can explicitly state:
>   systemd-networkd-wait-online -i em1
> 
> In fact, I would prefer this flexibility instead of configuring per
> connection whether you want nm-online to wait for it.
> But the onboot condition above is a good default if the user omits the
> nm-online -i arguments.

I think that "nm-online -i" would be pretty easy except that "-i" stands for interfaces and NM usually operates rather on connections. You could also have "-c" for connections or just a subset of the possibilities.

> An onboot distinction is anyway useful. Since NetworkManager 0.9.10, NM
> tries to assume a connection. At startup, the user might forcefully want to
> autoactivate a connection. For example, see
> https://mail.gnome.org/archives/networkmanager-list/2015-March/msg00000.html

I might just share my view on the possibility of "onboot" connections in the context of our IRC discussion to keep it here in bugzilla.

The basic purpose of an "onboot" connection as known from /etc/network/interfaces and similar tools is (in my opinion) generally to acquire connectivity at (system) startup and keep over the whole (system) uptime.

In NetworkManager I would expect that:

1) At (NetworkManager) startup, the desired connection should be attempted whether or not the device is configured. When the device was already configured as expected, NetworkManager should be able to take over gracefully. When the device is configured otherwise, NetworkManager should fix it.

2) At (NetworkManager) exit, an "onboot" connection should be kept if applicable. Applicable means that it communication can continue without NetworkManager or any related daemons running.

Notice the shift between system startup/shutdown and NetworkManager startup/exit. Those most often happen in relation to each other, where restarting NetworkManager is a notable exception.

Also notice that the definition is "practical" (or from sysadmin's point of view). Enforcing a connection over an already configured interface and bootup connections are technically two distinct behaviors but they happen to be useful in the same use cases.

One last note is that I don't generally expect to see "onboot" connections on a user's laptop (with connectivity provided via various wireless or wired networks connected at any time) as much as I don't generally expect to see "non-onboot" "auto" connections on a server with permanent physical connection. Those are (proposed) tools for entirely different use cases.

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).