Bug 1357899 - [RHEL 7.2] "Job NetworkManager-wait-online.service/start failed with result 'dependency' " error after disabling NetworkManager-wait-online service while installation.
[RHEL 7.2] "Job NetworkManager-wait-online.service/start failed with result '...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
x86_64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Beniamino Galvani
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-07-19 10:18 EDT by Akshay Jadhav
Modified: 2017-07-28 01:34 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-28 12:55:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Akshay Jadhav 2016-07-19 10:18:29 EDT
Description of problem:

When NetworkManager and NetworkManager-wait-online services are disabled, missing dependencies on NetworkManager-wait-online service are reported during boot.

------------------------------
Jul 19 03:05:08 localhost systemd: Job NetworkManager-wait-online.service/start failed with result 'dependency'.
------------------------------

I have disabled the NetworkManager-wait-online and NetworkManager service during installation via kickstart.

Version-Release number of selected component (if applicable):

How reproducible:

Use the simple kickstart file and add the commands to stop and disable NetworkManager and NetworkManager-wait-online service in the post script section.

Steps to Reproduce:

1. Import the kickstart file while installation, kickstart file will stop NetworkManager and NetworkManager-wait-online services.

2. reboot.

3. Try to grep out the NetworkManager-wait-online from the log files. you will find dependency errors in logs.

Actual results:

"NetworkManager-wait-online.service/start failed with result 'dependency'" should not be happened, as both the services are stop and disabled.

Expected results:

"systemd" should not check that service and print dependency error in log file, as both the services are stop and disabled.

Additional info:

This scenario appears to be a bug like :  https://bugzilla.redhat.com/show_bug.cgi?id=921774
Comment 2 Jan Synacek 2016-07-20 03:58:35 EDT
# rpm -qf /usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
NetworkManager-1.4.0-0.3.git20160621.072358da.el7.x86_64

The NetworkManager-wait-online.service is enabled statically. If you disable NetworkManager.service, then you see the dependency-related info message in the log, because NetworkManager-wait-online.service has a Requisite=NetworkManager.
Comment 3 Beniamino Galvani 2016-07-20 12:13:02 EDT
(In reply to Jan Synacek from comment #2)
> # rpm -qf
> /usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-
> online.service
> NetworkManager-1.4.0-0.3.git20160621.072358da.el7.x86_64
>
> The NetworkManager-wait-online.service is enabled statically.

What do you mean? The service is disabled according to comment 0, and
when I try to reproduce I get:

 $ systemctl status NetworkManager-wait-online
 ● NetworkManager-wait-online.service - Network Manager Wait Online
    Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; disabled; vendor preset: disabled)
    Active: inactive (dead)
      Docs: man:nm-online(1)

 Jul 20 11:46:50 winterfell systemd[1]: Dependency failed for Network Manager Wait Online.
 Jul 20 11:46:50 winterfell systemd[1]: Job NetworkManager-wait-online.service/start failed with result 'dependency'.

Why is systemd trying to start NetworkManager-wait-online.service even
if it's disabled?

> If you disable NetworkManager.service, then you see the
> dependency-related info message in the log, because
> NetworkManager-wait-online.service has a Requisite=NetworkManager.

But NetworkManager-wait-online is disabled in this case too...
Do you think this is caused by wrong dependencies in NM-wait-online
unit file?
Comment 4 Jan Synacek 2016-07-21 08:18:13 EDT
(In reply to Beniamino Galvani from comment #3)
> (In reply to Jan Synacek from comment #2)
> > # rpm -qf
> > /usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-
> > online.service
> > NetworkManager-1.4.0-0.3.git20160621.072358da.el7.x86_64
> >
> > The NetworkManager-wait-online.service is enabled statically.
> 
> What do you mean? The service is disabled <...>

It is present in /usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service, which makes it "statically enabled" (for the lack of better description...), meaning that the network-online target has a Wants= type of dependency on NetworkManager-wait-online.service. That's why the NM-w-o service is started even though it shows as being disabled. The failed dependency is then caused by the Requisite= option.

> Why is systemd trying to start NetworkManager-wait-online.service even
> if it's disabled?

See above.

> Do you think this is caused by wrong dependencies in NM-wait-online
> unit file?

As suggested by Michal, one way to solve this would be to remove the Requisite= from the NetworkManager-wait-online.service and make the nm-online tool return 0 when NM is not running.
Comment 6 Beniamino Galvani 2016-08-10 15:33:51 EDT
(In reply to Jan Synacek from comment #4)
> > Do you think this is caused by wrong dependencies in NM-wait-online
> > unit file?
> 
> As suggested by Michal, one way to solve this would be to remove the
> Requisite= from the NetworkManager-wait-online.service and make the
> nm-online tool return 0 when NM is not running.

Instead, how about removing the static "Want" dependency of
network-online.target to NM-w-o.service? I'm not sure of the reason
why it was added in the first place (it was suggested here [1]), but
that dependency makes impossible to disable NM-w-o (if we exclude
masking) when a service pulls network-online.target in.
systemd-networkd-wait-online doesn't use the static dependency either
(in Fedora/RHEL).

Removing the static dependency will prevent the warning as
network-online.target will not start NM-w-o if this is disabled. When
the service is re-enabled, it will add the "Want" dependency from
network-online.target again and everything should work as before.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37
Comment 7 Jan Synacek 2016-08-15 04:13:38 EDT
You would have to make sure that NM-w-o is enabled after installation, so you don't cause any regressions. But, even then, if you enabled NM-w-o and disabled NM, you would still get the warnings in the logs. I think that part of the fix should also be documenting that if people disable NM, they should also make sure that NM-w-o is disabled.
Comment 8 Beniamino Galvani 2016-09-01 16:54:11 EDT
Ok, so it seems that this topic (removing the static dependency) has
been discussed multiple times [1] [2] with the outcome that the
current solution is good enough.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=787314
[2] https://bugzilla.gnome.org/show_bug.cgi?id=746039

Regarding the initial request, the error is caused by the fact that there
is a service that depends on network connectivity, and when NM is
installed this creates a dependency on NM-wait-online.

This command:

 systemctl list-dependencies --reverse NetworkManager-wait-online

shows which services are requesting network connectivity.

These solutions come to mind:

 1) simply ignore the error, since it is expected if there are
 services requesting network connectivity but NM is disabled

 2) mask the NetworkManager-wait-online service to prevent it from
 being started ("systemctl mask NetworkManager-wait-online")

Are these acceptable solutions?
Comment 14 Beniamino Galvani 2016-09-28 12:55:39 EDT
I'm closing this as the error is harmless and can be avoided masking the service. Please reopen if needed.

Note You need to log in before you can comment on or make changes to this bug.