Bug 458737 - NTP doesn't notice network configuration changes when NM is used
NTP doesn't notice network configuration changes when NM is used
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F10Target
  Show dependency treegraph
Reported: 2008-08-11 20:59 EDT by Tom Horsley
Modified: 2013-01-09 23:46 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 01:17:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2008-08-11 20:59:38 EDT
Description of problem:

I turn on ntp during the 1st boot setup, goto advanced options
and check the synchronize time at startup option. When I boot the
system, NetworkManager hasn't yet brought up the network when the
ntp startup attempts to get the time synced.

I'm sure you'll call this NOTABUG, but I'd just point out that
all I did was use the installer to pick available options, and
the combination winds up with a system that isn't working correctly.
There is a bug somewhere :-).

I have no idea why NetworkManager can't be absolutely identical
in functionality to the old network system when I have a static IP.

Version-Release number of selected component (if applicable):

Whatever version is on the Fedora-10-Alpha-x86_64-DVD

How reproducible:

every boot (in fact, I see the NetworkManager startup messages in
/var/log/messages immediately following the NTP startup messages).

Steps to Reproduce:
1. turn on synchronize at boot option in NTP
2. boot system with static IP and NetworkManager
Actual results:

ntp startup can't sync the time because there is no network

Expected results:

ntp bootup timesync works

Additional info:
Comment 1 Dan Williams 2008-09-24 07:04:16 EDT
The Fedora NTP package should include a dispatcher script that resyncs NTP whenever NM brings an interface up.
Comment 2 Miroslav Lichvar 2008-09-26 08:28:10 EDT
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.
Comment 3 Tom Horsley 2008-09-26 16:52:04 EDT
>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 :-).
Comment 4 Jesse Keating 2008-10-27 14:57:56 EDT
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.
Comment 5 Tom Horsley 2008-10-27 15:12:20 EDT
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).
Comment 6 Jesse Keating 2008-10-27 15:21:28 EDT
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 (:
Comment 7 Bill Nottingham 2008-10-27 15:39:13 EDT
(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.)
Comment 8 Miroslav Lichvar 2008-10-29 10:02:04 EDT
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.
Comment 9 Bug Zapper 2008-11-25 21:44:41 EST
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:
Comment 10 Bug Zapper 2009-11-18 03:15:41 EST
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: 
Comment 11 Bug Zapper 2009-12-18 01:17:57 EST
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.

Note You need to log in before you can comment on or make changes to this bug.