the ntpd service reports "failed" on boot if you're using networkmanager.
i thought this was meant to be fixed in ntp 4.2.4 according to bug 216351? or
does 4.2.4 just have some new options which need to be configured to make it
handle this scenario?
anyhow, i imagine it could confuse new users because it looks like something's
gone wrong. and it looks untidy because rhgb 'unhides'.
are we supposed to manually create a NetworkDispatcher rule to restart ntpd when
a network comes up and then stop ntpd from starting on boot?
ntpd shouldn't need a NetworkDispatcher rule.
Is it failing for "ntpd: Synchronizing with time server:" ? If yes, please
remove all servers listed in /etc/ntp/step-tickers, it's not supposed to work
ah, nice. thanks. presumably those got in there because NM isn't activated by
default so the first time ntpd ran it was doing so without NM?
so maybe enabling NM should clean out that file? or comment it out or move it?
presumably it would be recreated anyway if you then disabled NM again?
maybe we should revisit this when we get to the next version of NM.
system-config-date has "Synchronize system clock before starting service" in
advanced options. It's disabled by default. Maybe you enabled it in first boot?
hmm. well, i didn't enable it myself - just ticked "Enable Network Time
Protocol" - but it's enabled now. Presumably it gets ticked by default if you
enable NTP in first boot?
Yes, that's the problem.
s-c-d should ignore lines beginning with # in step-tickers. ntp now packages
step-tickers which has a comment in (was empty in F7).
I've started to build system-config-date-1.9.15-1.fc8 right now which should:
- check if not only comments and/or empty lines are in the step-tickers files
instead of just checking its size
- write the comment "# List of servers used for initial synchronization." at the
top of the file, regardless if "Synchronize system clock before starting
service" is chosen or not
it's finished building, waiting for rel-eng...
And this is tagged
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.
If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)
Thanks for your help and we apologize for the interruption.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.