The following issue occurs on a 3.16.7-24 x86_64 Desktop system which uses wicked for the network configuration:
/var/log/boot.log content:
INFO ] Network Manager is not active.
[DEPEND] Dependency failed for Network Manager Wait Online.
The following information is also addressing this issue:Red Hat Bugzilla – Bug 921774
[INDENT=2]NetworkManager-wait-online reports dependency errors when using network.service
When NetworkManager and NetworkManager-wait-online are disabled (using the plain network service instead), missing dependencies on NetworkManager-wait-online are reported during boot.[/INDENT]
[INDENT=3]This isn’t a NetworkManager bug. Please file bugs against ypbind and xinetd; they do not need to depend on NetworkManager-wait-online, they should only depend on network.target.
[/INDENT]
[INDENT=2]Status: CLOSED NOTABUG[/INDENT]
Red Hat Bugzilla – Bug 1002294
[INDENT=2]xinetd should not depend on NetworkManager-wait-online
xinetd currently depends on NetworkManager-wait-online. This causes a dependency failed warning from systemd during boot when using the plain network service instead of NetworkManager.[/INDENT]
[INDENT=3]Fedora Update System 2013-12-13 22:34:04 EST
xinetd-2.3.15-10.fc20 has been pushed to the Fedora 20 stable repository.
[/INDENT]
[INDENT=2]Status: CLOSED ERRATA
[/INDENT]
Despite the Bugzilla status, it seems that this issue has been addressed by xinetd-2.3.15-10.
But, on reading the change log for the xinetd Version: 2.3.15 Release: 10.1 with the build date Thursday September 3rd 2015 in the OpenSuSE Factory there is no mention of this issue’s resolution being included in that build.
Is this a simple omission from the change log text or, has the repair been overlooked?
Those RedHat bugs do not apply to current openSUSE releases. Neither xinetd.service nor ypbind.service require NetworkManager-wait-online.service.
And you can’t compare RedHat and openSUSE package versions anyway. What RedHat/Fedora fixed in their 2.3.15-10.fc20 package might not have been a problem at all in openSUSE, or might have been fixed in a completely different “version” (or even not at all).
It definitely isn’t a problem in 13.2’s 2.3.15-7.2.2 package as mentioned…
To your “problem”:
Do you maybe have NetworkManager-wait-online.service enabled?
systemctl status NetworkManager-wait-online.service
No – default 13.2 installation on an Ethernet-only Desktop machine – everything related to Network Manager is disabled – “wicked” handles network configuration.
Well, then some other unit seems to want it.
But AFAICS it’s neither xinetd.service nor ypbind.service, as already mentioned.
I just switched to Wicked myself on my 13.2 system (I’m using NetworkManager normally), and I see the same message.
I’m not sure at the moment how to find out which other unit causes it to start though, a grep through all unit files doesn’t show anything…
You might want to file a bug report about that at http://bugzilla.opensuse.org (same username/password as here).
OTOH, you can also just ignore that I suppose, I don’t think it causes any problem…
OK ] Reached target Basic System.
Starting Avahi mDNS/DNS-SD Stack...
Starting Machine Check Exception Logging Daemon...
OK ] Started Machine Check Exception Logging Daemon.
Starting irqbalance daemon...
OK ] Started irqbalance daemon.
Starting WPA Supplicant daemon...
Starting Name Service Cache Daemon...
Starting /etc/init.d/boot.local Compatibility...
Starting D-Bus System Message Bus...
OK ] Started D-Bus System Message Bus.
OK ] Started Avahi mDNS/DNS-SD Stack.
OK ] Started WPA Supplicant daemon.
Starting SuSEfirewall2 phase 1...
OK ] Started Name Service Cache Daemon.
OK ] Started /etc/init.d/boot.local Compatibility.
OK ] Started Restore Sound Card State.
OK ] Reached target User and Group Name Lookups.
OK ] Reached target Host and Network Name Lookups.
OK ] Started SuSEfirewall2 phase 1.
Starting wicked AutoIPv4 supplicant service...
Starting wicked DHCPv4 supplicant service...
Starting wicked DHCPv6 supplicant service...
OK ] Started wicked AutoIPv4 supplicant service.
OK ] Started wicked DHCPv6 supplicant service.
OK ] Started wicked DHCPv4 supplicant service.
Starting wicked network management service daemon...
OK ] Started wicked network management service daemon.
Starting wicked network nanny service...
OK ] Started wicked network nanny service.
Starting wicked managed network interfaces...
And, now the cause is clear: in /usr/lib/systemd/system/NetworkManager-wait-online.service there’s a requisite which seems to be causing this issue:
*By the way:
*In /usr/lib/systemd/system/xinetd.service and ypbind.service both use:
**After=network.target
**-- and (almost) everything else as well – the only exceptions are the YaST2 Firstboot and Second-Stage services which seem to need a “Before=” definition of both network.service and NetworkManager.service.
It should have been enough to only mask NetworkManager-wait-only.service, the others were not being started anyway (otherwise you wouldn’t have had that error message in the boot.log in the first place).
And, now the cause is clear: in /usr/lib/systemd/system/NetworkManager-wait-online.service there’s a requisite which seems to be causing this issue:
Of course, NetworkManager-wait-online.service makes no sense without NetworkManager.service.
The Requisite=NetworkManager.service only makes sure that it won’t be started without NetworkManager.service, but this is what causes the “error” message.
The interesting question rather is why it is being started at all.
*By the way:
*In /usr/lib/systemd/system/xinetd.service and ypbind.service both use:
**After=network.target
**-- and (almost) everything else as well – the only exceptions are the YaST2 Firstboot and Second-Stage services which seem to need a “Before=” definition of both network.service and NetworkManager.service.
Before or After do not start units, they only order them. As long as there is no “Requires=NetworkManager-wait-online.service” or “Wants=NetworkManager-wait-online.service” it shouldn’t get started.
I suspect that “systemctl disable” does not prevent the boot-time execution of the checks implied by “Requisite=”:If the unit(s) listed by “Requisite=” have not been started then they will not be started and the transaction will fail immediately.
“systemctl mask” prevents every possible activation of the unit – “disable” on the other hand allows at least the manual activation of the unit.
I’ll do some code inspection to confirm if this assumption is correct.
Sounds plausible. Although I still think that something should at least want to start it for the “error” to appear.
Yes, systemctl disable only prevents automatic, unconditional start of the unit. It will still be started if some other unit depends on it.
Whereas mask completely disables it, like if you deleted the file (it actually symlinks it to /dev/null).
But again, it’s just a message in the boot.log, there’s no problem anywhere really.