Description of problem:
During bootup, a message is shown, "A start job is running
for NetworkManager wait online" and boot does not complete until this is done
Version-Release number of selected component (if applicable):
pretty often but not every time
Steps to Reproduce:
GUI login (graphical.target) is not reached until network connects (what if it never connects??)
graphical.target is reached regardless of network. Network can keep starting up in the background
# systemctl --reverse list-dependencies network-online.target
One of the services you list is pulling in network-online.target. Systemd is executes the dependency as specified by those units. Check which one is enabled (most likely ntpdate.service) and reassign to it. They might be able to fix it, or if they really need the dependency, they will close the bug.
I understand that ntpdate wants network-online -- but my argument is that graphical.target should not wait for either ntpdate or for network-online
As a user, I want to see GUI as soon as possible -- and if some services are still starting up, it's not a big deal
Right, but please understand that systemd does not specify this dependency. ntpdate.service does. If you think it should do something different, take it up with ntpdate developers.
The ntpdate service waits for the network to be up. And it is configured to be started as part of bootup and finish before boot is completed. Either drop ntpdate from your system or convince the ntpdate maintainer that the service should have different deps (though I really don't think that would make much sense).
Anyway, reassigning, this is really between you and the ntpdate maintainer, it's not a systemd issue.
No, my argument is that ntpdate is not a prerequisite for graphical.target -- why is that so hard to understand??
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 21 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
As I understand it, this is not really an issue with the ntpdate service as it needs network in order to do something useful. I'm reassigning back to systemd. If this bug is no longer present in current Fedora, or you think it's not really a bug, please close.
My suggestion would be to disable the ntpdate service and enable an NTP daemon, like chronyd, ntpd, or systemd-timesyncd.
Right, ntpdate.service wants to run after the network is up, and it also wants to run before multi-user.target, which is before graphical.target, hence it adds an ordering between network-online.target and graphical.target. Systemd then duly obeys specified constraints.
If you want to change this, either disable ntpdate, or modify it not to be before multi-user.target.