Created attachment 299106 [details] [review]
systemd: install NetworkManager-wait-online.service into network-online.target

This fixes [Install].

Created attachment 299109 [details] [review]
systemd: Stop blocking network.target in systemd-networkd-wait-online.service

This drops the network.target dependencies. Most probably this is just a copy&paste leftover from NetworkManager-wait-online-systemd-pre200.service.in?

Please compare that with systemd-networkd-wait-online.service, that looks right.

Thanks for considering!

Yeah, that would seem to be the explanationgiven in http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ too.  Any idea when the "Whenever systemd encounters a $network dependency in LSB headers of init scripts it will translate this to a Wants= and After= dependency on network-online.target hence staying relatively close to traditional LSB behaviour." stuff hit?  We'll need to see what has to happen in distros when making this change, since a lot of packaged services probably already depend on network.

For example, here's what I have in Fedora 21 for stuff that requests "After" network.target.  Some of these look pretty suspicious.  NFS, docker, dnsmasq, sshd, rdisc, OVS, etc.

/lib/systemd/system/rdisc.service:After=syslog.target network.target
/lib/systemd/system/nfs-server.service:After=network.target named.service nfs-lock.service
/lib/systemd/system/nfs-lock.service:Requires=rpcbind.service network.target
/lib/systemd/system/nfs-lock.service:After=network.target named.service rpcbind.service
/lib/systemd/system/dnsmasq.service:After=network.target
/lib/systemd/system/nfs.target:After=network.target named.service 
/lib/systemd/system/sshd.service:After=syslog.target network.target auditd.service
/lib/systemd/system/docker.service:After=network.target
/lib/systemd/system/openvswitch.service:After=syslog.target network.target openvswitch-nonetwork.service
/lib/systemd/system/rc-local.service:After=network.target

The After=network.target orderings are only really useful on shutdown (as stated by the systemd.special man page)

The current NM-w-o.service file contents come from https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37. (And I agree that it seems wrong.)

(In reply to Michael Biebl from comment #4)
> The After=network.target orderings are only really useful on shutdown (as
> stated by the systemd.special man page)

Yeah, but it really looks like people are Doing This Wrong, and expecting that network.target means networking is actually up and running in at least some cases.  The stuff I pasted is from a minimal VM, and the list on my actual system is much more.

http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ says that After=network.target is only useful for making sure that the service cleanly terminates its connections.

I don't disagree with the changes you suggest but I think we'll see some fallout from this, where we have to (yet again) educate people on what exactly network and network-online are.

(In reply to Dan Winship from comment #5)
> The current NM-w-o.service file contents come from
> https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37. (And I agree that it
> seems wrong.)

Those changes came straight from Lennart himself, but that was early 2013 and things have likely changed since then.  Probably whatever networkd-wait-online does, NM-wait-online should also do...

(In reply to Dan Williams from comment #7)
> (In reply to Dan Winship from comment #5)
> > The current NM-w-o.service file contents come from
> > https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37. (And I agree that it
> > seems wrong.)
> 
> Those changes came straight from Lennart himself, but that was early 2013
> and things have likely changed since then.  Probably whatever
> networkd-wait-online does, NM-wait-online should also do...

I agree. networkd probably has a correct unit file...

http://cgit.freedesktop.org/systemd/systemd/tree/units/systemd-networkd-wait-online.service.in

(In reply to Dan Williams from comment #3)
> Any
> idea when the "Whenever systemd encounters a $network dependency in LSB
> headers of init scripts it will translate this to a Wants= and After=
> dependency on network-online.target hence staying relatively close to
> traditional LSB behaviour." stuff hit?

That was http://cgit.freedesktop.org/systemd/systemd/commit/?id=0404c609f399b, i. e. systemd 212.

> We'll need to see what has to happen in distros when making this change, since a lot of packaged services probably already depend on network.

> For example, here's what I have in Fedora 21 for stuff that requests "After"
> network.target.  Some of these look pretty suspicious.

> /lib/systemd/system/nfs-server.service:After=network.target named.service
> nfs-lock.service
> /lib/systemd/system/nfs-lock.service:Requires=rpcbind.service network.target
> /lib/systemd/system/nfs-lock.service:After=network.target named.service
> rpcbind.service

That's fine. A server merely opens ports, and you can also talk to it via localhost, so you don't need to be online to start an NFS *server*

> /lib/systemd/system/dnsmasq.service:After=network.target
> /lib/systemd/system/nfs.target:After=network.target named.service 
> /lib/systemd/system/sshd.service:After=syslog.target network.target
> auditd.service
> /lib/systemd/system/docker.service:After=network.target

Likewise with those. ssh and other servers should start without being online, and shouldn't stop if you temporarily drop off the network.

You need network-online.target for e. g. the NFS clients (and remote-fs *.mount units indeed have that), or for a bittorrent client or similar.

Adding a
RemainAfterExit=yes
under [Service], while at it, would be a good idea as well

1) The dependencies and ordering of data/NetworkManager.service.in are:

Wants=network.target
Before=network.target 

The Wants is IMO not needed for any purpose. But the Before is necessary for reverse ordering at shutdown (as already stated by mbiebl) per systemd's defintion of network.target which is very different from what the bug report claims, see systemd.special(7).

There's no mention of network-online.target in that file.

2) The dependencies and ordering of data/NetworkManager-wait-online.service.in are:

Requisite=NetworkManager.service
After=NetworkManager.service
Wants=network.target
Before=network.target network-online.target

The NetworkManager.service dependencies are IMO good. The network.target dependencies are a left over from the time before redefinition of network.target and network-online.target and should indeed no longer be needed.

3) The enable/disable logic of data/NetworkManager-wait-online.service.in is:

WantedBy=multi-user.target

This is a left over from the same time and should no longer be needed. There's a link installed for network-online.target in /var/lib, so there's no need to add any enable/disable logic.

Also, I was in contact with systemd developers when changes to the LSB initscript convertor was being done, and the basic idea was that the dependency on $network should basically give Wants+After=network-online.target as you never know what exactly the initscript expects, with a slightly different semantics for providing $network.

(In reply to Pavel Simerda from comment #11)
> 1) The dependencies and ordering of data/NetworkManager.service.in are:
> 
> Wants=network.target
> Before=network.target 
> 
> The Wants is IMO not needed for any purpose. But the Before is necessary for
> reverse ordering at shutdown (as already stated by mbiebl) per systemd's
> defintion of network.target which is very different from what the bug report
> claims, see systemd.special(7).

Wants/Before=network.target in NetworkManager.service seems correct. It makes sure the target is pulled in by NetworkManager.service and only active after NM has started.

> There's no mention of network-online.target in that file.
> 
> 2) The dependencies and ordering of
> data/NetworkManager-wait-online.service.in are:
> 
> Requisite=NetworkManager.service
> After=NetworkManager.service
> Wants=network.target
> Before=network.target network-online.target
> 
> The NetworkManager.service dependencies are IMO good. The network.target
> dependencies are a left over from the time before redefinition of
> network.target and network-online.target and should indeed no longer be
> needed.
> 
> 3) The enable/disable logic of data/NetworkManager-wait-online.service.in is:
> 
> WantedBy=multi-user.target
> 
> This is a left over from the same time and should no longer be needed.
> There's a link installed for network-online.target in /var/lib, so there's
> no need to add any enable/disable logic.

I guess you mean /usr/lib here.
That said, I would very much prefer, if NM-wait-online.service uses 
[Install]
WantedBy=network-online.target 
like systemd-networkd-wait-online.service, so it can easily be enabled/disabled.

(In reply to Michael Biebl from comment #13)
> (In reply to Pavel Simerda from comment #11)
> > 1) The dependencies and ordering of data/NetworkManager.service.in are:
> > 
> > Wants=network.target
> > Before=network.target 
> > 
> > The Wants is IMO not needed for any purpose. But the Before is necessary for
> > reverse ordering at shutdown (as already stated by mbiebl) per systemd's
> > defintion of network.target which is very different from what the bug report
> > claims, see systemd.special(7).
> 
> Wants/Before=network.target in NetworkManager.service seems correct. It
> makes sure the target is pulled in by NetworkManager.service and only active
> after NM has started.

Again, look at systemd-networkd.service this case, which has
Wants/Before=network.target

> > There's no mention of network-online.target in that file.
> > 
> > 2) The dependencies and ordering of
> > data/NetworkManager-wait-online.service.in are:
> > 
> > Requisite=NetworkManager.service
> > After=NetworkManager.service
> > Wants=network.target
> > Before=network.target network-online.target
> > 
> > The NetworkManager.service dependencies are IMO good.

Yep, Requisite/After=NetworkManager.service is fine

Review of attachment 299109 [details] [review]:

Looks correct to me.

Review of attachment 299106 [details] [review]:

This change looks sensible to me.
You will also need to change data/Makefile.am though and drop

install-exec-local:
       install -d $(DESTDIR)$(systemdsystemunitdir)/network-online.target.wants
       ln -sf $(systemdsystemunitdir)/NetworkManager-wait-online.service $(DESTDIR)$(systemdsystemunitdir)/network-online.target.wants

Michael: Isn't that Makefile.am snippet pretty much doing what the updated [Install] section does? This would just enable NM-w-o as part of "make install", right? Why does this need to be dropped?

Created attachment 299155 [details] [review]
systemd: Stop blocking network.target in NetworkManager-wait-online.service.in

Err, how embarrassing .. this updated patch fixes the service name in the commit changelog.

(In reply to Martin Pitt from comment #17)
> Michael: Isn't that Makefile.am snippet pretty much doing what the updated
> [Install] section does? This would just enable NM-w-o as part of "make
> install", right? Why does this need to be dropped?

No, the symlink is installed in $(systemdsystemunitdir), which means, the service is statically enabled. So the [Install] section would be rather pointless.

(In reply to Michael Biebl from comment #13)
> Wants/Before=network.target in NetworkManager.service seems correct. It
> makes sure the target is pulled in by NetworkManager.service

I have yet to learn the reason to pull it in from NetworkManager. There's no debate about the Before, it's needed for proper shutdown.

> I would very much prefer, if NM-wait-online.service uses 
> [Install]
> WantedBy=network-online.target

That was my original[1] proposal.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=728965

But then I learned more and changed my mind. In my opinion it is a bad idea to have the Install section at all. The only reason to keep it possible to support old-style services that relied on network.target instead of network-online.target.

I don't see a good reason for the administrator to enable/disable the service and therefore I don't see a reason for the Install section. 

> like systemd-networkd-wait-online.service, so it can easily be
> enabled/disabled.

I will talk to Tom Gundersen about it.

Created attachment 300642 [details] [review]
Various fixes to NM-wait-online

I've attached the patch I have in mind

(In reply to Michael Biebl from comment #21)
> Created attachment 300642 [details] [review] [review]
> Various fixes to NM-wait-online
> 
> I've attached the patch I have in mind

The patch looks good except that alone it doesn't ensure that nm-w-o.service is enabled (for network-online.target) and thus the removal of the link will break the boot sequence.

There are two solutions:

1) Keep the symlink. I still favor this solution originally suggested by Lennart. It makes sure that NetworkManager-wait-online gets used whenever the following two conditions are met.

a) At least one service pulls in network-online.target.

b) NetworkManager is running.

The "Requisite" directive is a perfect fit here.

2) Add proper enable logic (Also=nm-w-o.service in NetworkManager.service). I still think that this solution is slightly inferior comparing to the symlink as it relies on actions outside the systemd process.

to 1) The symlink would be created by running systemctl enable NetworkManager-wait-online.service in postinst. Afaics, RPM ships scriptlets to do that, deb-based distros have similar helpers.

to 2) I think NM-wait-online.service should be enabled independently of NetworkManager.service, i.e. enabling NetworkManager.service should *not* imply enabling NM-wait-online.service.

(In reply to Michael Biebl from comment #23)
> to 1) The symlink would be created by running systemctl enable
> NetworkManager-wait-online.service in postinst. Afaics, RPM ships scriptlets
> to do that, deb-based distros have similar helpers.

At least in Fedora this is handled using systemctl preset. But the issue here is that you expect the service to be enabled/disabled at all.

> to 2) I think NM-wait-online.service should be enabled independently of
> NetworkManager.service, i.e. enabling NetworkManager.service should *not*
> imply enabling NM-wait-online.service.

The advantage of the current way is that the combination of network-online.target and NetworkManager *always* works, while nm-online is still only run when appropriate. I do not see how changing that could be an improvement.

(In reply to Pavel Simerda from comment #24)
> The advantage of the current way is that the combination of
> network-online.target and NetworkManager *always* works, while nm-online is
> still only run when appropriate. I do not see how changing that could be an
> improvement.

That's quite simple: Say I have NetworkManager installed to manage my wlan interface but use systemd-networkd to manage my other interfaces.

In this case, I don't want boot to be blocked by NM-wait-online waiting for the wireless interface.

(In reply to Michael Biebl from comment #25)
> (In reply to Pavel Simerda from comment #24)
> > The advantage of the current way is that the combination of
> > network-online.target and NetworkManager *always* works, while nm-online is
> > still only run when appropriate. I do not see how changing that could be an
> > improvement.
> 
> That's quite simple: Say I have NetworkManager installed to manage my wlan
> interface but use systemd-networkd to manage my other interfaces.
> 
> In this case, I don't want boot to be blocked by NM-wait-online waiting for
> the wireless interface.

Now we have an actual use case to discuss.

The very same issue applies to people who are using just NetworkManager (it was reported in Fedora but I don't have a link at hand). In my opinion, it would be better to solve the actual issue (by allowing autoconnect connections that are not waited for at boot time) which has been already discussed (ask thaller).

When that is fixed, then you should have no connections marked for waiting, and the correct behavior of nm-online would AFAIK be to return immediately. If you later decide to mark some connection for being waited for, it would work without the need to change systemd configuration.

Another problem: say you have NetworkManager installed, but disabled, because you use another network management system.

Since NM-wait-online.service has Requires=NetworkManager.service, the service will be marked as failed once it's being activated via network-online.target.
network-online.target itself will not be considered fully up either.
So, every time another unit references network-online.target, this will lead to a failed attempt to start NM-wait-online.service.

In summary: The admin really needs a way to disable NM-wait-online.service, i.e. the service should not be hooked up statically in /lib/systemd/system/network-online.target.wants

(In reply to Michael Biebl from comment #27)
> Another problem: say you have NetworkManager installed, but disabled,
> because you use another network management system.
> 
> Since NM-wait-online.service has Requires=NetworkManager.service,

Requisite=NetworkManager.service

> the
> service will be marked as failed once it's being activated via
> network-online.target.
> network-online.target itself will not be considered fully up either.

After nm-w-o.service fails, network-online.target will be fully up because nm-w-o is *wanted*, not *required*, AFAIK.

> So, every time another unit references network-online.target, this will lead
> to a failed attempt to start NM-wait-online.service.

I can't confirm this.

(In reply to Pavel Simerda from comment #28)
> > So, every time another unit references network-online.target, this will lead
> > to a failed attempt to start NM-wait-online.service.
> 
> I can't confirm this.

And by the way even if it did, it would be a just a trivial check inside systemd that NetworkManager is still not running, so this is a non-issue anyway.

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