The Fedora NTP package should include a dispatcher script that resyncs NTP whenever NM brings an interface up.

This is a duplicate of bug #445229.

ntpd handles new interfaces by itself, no need for dispatcher scripts. The problem is that ntpdate needs to be executed before ntpd is started and we don't want to delay starting ntpd as it is useful even when link to internet isn't ready yet.

Maybe drop the option from s-c-d? The ntpdate service is useful only in very specific cases and just makes confusion.

>The
>problem is that ntpdate needs to be executed before ntpd is started and we
>don't want to delay starting ntpd as it is useful even when link to internet
>isn't ready yet.

Or maybe bring the damn interface up at boot time before all the
network dependent services when you've defined a static IP: A technique
that has worked with no problems for many decades now :-).

So what happens here is that by default, NetworkManager service does not wait for an address to be obtained before it moves on in the startup sequence.  This allows for other services to continue their startup while NM gets / sets an address in the background.

Obviously this doesn't work when ntp wants to use the network before it starts by calling ntpdate (provided you're not using a local time device).  You can configure NM to wait for an address to be configured before continuing at boot up by setting NETWORKWAIT=true in /etc/sysconfig/network

Arguably system-config-date (as used by firstboot) should assess whether we want to set time before launching daemon, and if we're using a local device or not.  If we want it set, and are not using a local device, it needs to set NETWORKWAIT=true in /etc/sysconfig/network.  I'm re-assigning the bug there, but also dropping this off the blocker list.  I just don't think this meets release criteria for being a blocker.

I'm not sure having NetworkManager wait would even help. The last time
I looked at the sequence, NetworkManager was started a lot later
in the sequence than the old network service was, so things before
it still wouldn't have a network even if NetworkManager did wait
(maybe the ordering is different now than the last time I noticed though).

The ordering is different, and I verified that waiting does indeed allow ntpdate to run successfully before ntpd starts up.  I do test these things (:

(In reply to comment #2)
> ntpd handles new interfaces by itself, no need for dispatcher scripts. The
> problem is that ntpdate needs to be executed before ntpd is started and we
> don't want to delay starting ntpd as it is useful even when link to internet
> isn't ready yet.

This statement confuses me.  If ntpd 'is useful even when link to internet isn't ready yet', then this bug shouldn't exist - if it's to be useful without a network connection, it should work regardless of whether NM fails, succeeds, starts earlier, or starts later. (IOW, I don't see why it needs to depend on ntpdate.)

Well, it's generally not a good idea to run two programs adjusting the clock at the same time.

It's technically possible to start ntpdate when ntpd is running (ntpdate has option -u to not use port 123 for outgoing packets), but doing so may disturb ntpd. If ntpd was just in the mode which measures frequency error when ntpdate set the clock, it could take many hours for ntpd to settle down.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 WONTFIX if it remains open with a Fedora 
'version' of '10'.

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 prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.