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 with NetworkManager.
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 rawhide. (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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.