Bug 445229

This would also have been the case on any LiveCD install from Fedora 7 or Fedora
8; this is not new.

You can work around this by setting NETWORKWAIT in /etc/sysconfig/network.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Any suggestions how to fix this?

Actually, I'm not able to reproduce this when NetworkManager is disabled.
ntpdate service seems to be started after network service (which has even waited
for dhclient to get an address).

Can you please provide more information?

when booting up Fedora 9/Rawhide:

rc3:

lrwxrwxrwx  1 root root   17 2008-04-17 04:13 S57ntpdate 
lrwxrwxrwx  1 root root   24 2008-04-17 04:13 S99NetworkManager

I am using NetworkManager the problem is when we boot up ntpdate is started too
early way before network services are even started, so no network is setup to
contact a ntp server to sync date/time.

This is the only service I notice (on laptop) that shows this problem at the moment.

NetworkManager should be at 27, can you try the following line from YumUpgradeFaq?

cd /etc/rc.d/init.d; for f in *; do /sbin/chkconfig $f resetpriorities; done

Even when NetworkManager is at 27, it probably won't be able to start the
networking before ntpdate is run (unless the NETWORKWAIT option is used).

lrwxrwxrwx 1 root root 24 2008-10-14 15:16 S99NetworkManager -> ../init.d/NetworkManager

Mine is set to start at 99 as well.

Should NETWORKWAIT be put in /etc/sysconfig/network by default if NTP is installed?  Or perhaps the NTP startup scripts should know about NetworkManger and wait for it to finish before spewing an error?

Incidentally, putting NetworkManager at S27 and setting NETWORKWAIT in /etc/sysconfig/network do not solve the problem.  I see "Waiting for network..." after NetworkManager starts up, and then [FAILED].  This is on Fedora 9 with NetworkManager-0.7.0-0.11.svn4022.4.fc9.i386 and ntp-4.2.4p5-2.fc9.i386.

with
NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64
ntp-4.2.4p5-2.fc10.x86_64

and
NETWORKWAIT=1
in /etc/sysconfig/network

and having verified as per previous comments that NetworkManager starts with S27

my clock does get synced on boot.

Yes, if NTPd is running it will, but ntpdate is trying first which fails for me.

(In reply to comment #10)
> Yes, if NTPd is running it will, but ntpdate is trying first which fails for
> me.

odd, my ntpdate gets run just before ntpd (as it should) and with the steps described in Comment #9, ntpdate sets the clock correctly. (without NETWORKWAIT=1 it would consistently fail)

the logs now say (server IP manually edited when pasting here)

[...]
Nov 19 03:38:55 morn ntpdate[2915]: step time server 192.168.x.y offset -7199.938771 sec
Nov 19 03:38:55 morn ntpd[2930]: ntpd 4.2.4p5 Wed Oct  8 11:22:32 UTC 2008 (1)
Nov 19 03:38:55 morn ntpd[2931]: precision = 0.117 usec
Nov 19 03:38:55 morn ntpd[2931]: Listening on interface [...]


The offset is exactly what I expect it to be and why I need ntp to fix my clock on boot, I had been playing a game under that OtherOS(tm) that does not deal properly with UTC in the RTC.

So, long story short, there must be a difference between your setup and mine we're both missing here.

Miroslav; anything you need from Shawn or myself to find out why it works for me but not for him?

*** Bug 473828 has been marked as a duplicate of this bug. ***

Adding "NETWORKWAIT=yes" to /etc/sysconfig/network on a current "rawhide" install allows ntpdate to synchronize correctly with a given NTP server.
Because of the additional delay of several seconds introduced by this modification which is unnecessary in case ntpdate is disabled, it would be nice to make the ntpdate service itself wait for network connectivity.

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

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 9'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 9 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

I agree with Joachim, this is a "Fit & Finish" kind of fix that it would be really nice to have ntpdate handle correctly.

If the ntpdate script forked and waited for network, adjusting clock could mess up already running ntpd.

Please note that ntpdate is useful only in very specific cases where services started after ntpdate need correct time immediately. So forking and waiting for network doesn't make much sense as it might break the services.

I think this will be much easier to fix when we switch to upstart scripts and events.

My suggestion:

/etc/NetworkManager/dispatcher.d/01-ntpdate:
#!/bin/bash

if [ -x /usr/bin/logger ]; then
  LOGGER="/usr/bin/logger -s -p user.notice -t NetworkManagerDispatcher"
else
  LOGGER=echo
fi

if [ -n "$1" ] && [ $2 == "up" ]; then
  if /sbin/chkconfig ntpdate
  then
    $LOGGER "running ntpdate"
    /sbin/service ${service} start
  fi
fi



/etc/NetworkManager/dispatcher.d/02-ntpd:
#!/bin/bash

if [ -x /usr/bin/logger ]; then
  LOGGER="/usr/bin/logger -s -p user.notice -t NetworkManagerDispatcher"
else
  LOGGER=echo
fi

service=ntpd

if [ -n "$1" ] && [ $2 == "up" ]; then
  if /sbin/chkconfig ${service}
  then
    if /sbin/service ${service} status >& /dev/null
    then
      $LOGGER "${service} is running, restart"
      /sbin/service ${service} restart
    else
      $LOGGER "${service} is not running, start"
      /sbin/service ${service} start
    fi
  fi
fi

# Only shut down if there are no networks up
if [ -n "$1" ] && [ $2 == "down" ] && [ -z "`/usr/bin/nm-tool | grep '^State: *connected'`" ]; then
  $LOGGER "stopping ${service}"
  /sbin/service ${service} stop
fi


Then NM will kick ntpdate/ntpd as needed when infertaces go up and down.

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

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

Still happening with f13 for me (on system upgraded from f12 at least).

Increasing priority since this bug causes GUI warning triangles in gdm and desktop now.

Starting sshd: 	[  OK  ]
ntpdate: Synchronizing with time server: 	[FAILED]
Starting ntpd: 	[  OK  ]
Starting sendmail: 	[  OK  ]

Happening on my Fedora 12 and Fedora 13 systems, regardless if it's a fresh install or upgrade from F12 to F13.

If you need a fast initial synchronization, please add iburst option to the servers specified in ntp.conf instead of enabling ntpdate service. This will cut down the time ntpd needs to sync to about 10 seconds (once the network is ready). If you don't want to keep ntpd running, add -q option to /etc/sysconfig/ntpd and it will exit just after the clock was set for the first time.

The ntpdate checkbox in system-config-date will be probably replaced with iburst setting.

Also, ntpdate from version 4.2.6p2 and on will need about 8 seconds to query a server, so it will be only 20% faster than the ntpd iburst mode.

The ntpdate service should be used only when some services started after ntpdate need correct time immediately, and NetworkManager has to be disabled in such cases.

Well we just need sane system default behaviour in fedora. :)

So how about disabling /etc/init.d/ntpdate by default?

The init script doesn't specify any default run levels, so something else had to enable it.

Did you check the "Synchronize system clock before starting service" option in system-config-date?

Ah I see - hmm I'll check more carefully then - thanks.

If that is an advanced option it should probably be moved
to a less prominent place in s-c-d? :)

(In reply to comment #27)
> If that is an advanced option it should probably be moved
> to a less prominent place in s-c-d? :)    

In the use case as follows, setting the time on boot is very much necessary but could be achieved with an iburst option enabling button too.

1) use Linux (no matter which distro) on one partition and using HW clock in UTC mode
2) Have an old OS that can not handle HW clock in UTC on another partition
3) sometimes boot into that old OS for legacy applications that do not work under Linux
4) at some point that OS sets time, non UTC time ends up in RTC
5) reboot into Linux

In this use case, I really would like my clock to be set back to something civilised during the bootup of Linux.

As such, please do not move the option and do not consider it an advanced option.

(In reply to comment #23)
> If you need a fast initial synchronization, please add iburst option to the
> servers specified in ntp.conf instead of enabling ntpdate service. This will
> cut down the time ntpd needs to sync to about 10 seconds (once the network is
> ready). If you don't want to keep ntpd running, add -q option to
> /etc/sysconfig/ntpd and it will exit just after the clock was set for the first
> time.

It has nothing to do with needing a fast initial synchronization, it's the fact that the option has been made available and it doesn't work as it is supposed to, hence this bug.
 
> The ntpdate checkbox in system-config-date will be probably replaced with
> iburst setting.

Until such time, this bug should be fixed.  After all it's over two years old.

> Also, ntpdate from version 4.2.6p2 and on will need about 8 seconds to query a
> server, so it will be only 20% faster than the ntpd iburst mode.

So you set a timeout and wait for a reply.  If it doesn't respond in 10-seconds then you move on.

> The ntpdate service should be used only when some services started after
> ntpdate need correct time immediately, and NetworkManager has to be disabled in
> such cases.    

Setting the time at system start-up is essential and is fully supported.  As a developer for a proprietary OS, it's absolutely do-able with "ntpd" or "ntpdate" but given the fact that "ntpdate" is being phased out, it would be wise to switch now.  The time and date needs to be adjusted so ensure CRON schedules function as needed, processes don't get FUBAR and it prevents the user from having to forcefully tell the system to update the time after each boot process.

The fact is that the option to "Synchronize system clock before starting service" was made available, to my knowledge, since Fedora 9.  Fedora 13 is now shipping and a bug as trivial as this could have been fixed already.  Instead, you're electing to tell users how to correct the problem themselves when it could be just as quick to fix the problem.

Users file bug reports because they feel they have found a bug.  If it turns out that the bug is valid, it should be fixed.  If the fix is to use a new process or service, then so be it.  Putting off a trivial bug for two years is not acceptable.

Now that this causes a warning triangle to show up in Fedora 13 it's going to get even uglier because more users will see this so called "who cares" bug and the complaints will start rolling in.  In the past I didn't care so much, but now my F13 systems all report boot errors as a result and I have to check each notice to ensure that it's just this warning.

Telling users to disable the "Synchronize system clock before starting service" option is unacceptable.

The option is disabled by default. You need to go in the "advanced options" in the s-c-d dialog and click on the checkbox to enable the ntpdate service. The tooltip should probably say it doesn't work with NetworkManager though.

As I stated before I don't know how to fix it, please feel free to send patches. The ones that were posted here already don't meet all requirements.

Would we be happy to move this all over to upstart?  Then it just needs to "start on networking" or something similar.

(In reply to comment #30)
> The option is disabled by default. You need to go in the "advanced options" in
> the s-c-d dialog and click on the checkbox to enable the ntpdate service. The
> tooltip should probably say it doesn't work with NetworkManager though.

It only mentions that it should not be used if the time server cannot be reached.  Since the time servers I use are the default Fedora servers, they're always available.  It make no mention of Network Manager at all.

> As I stated before I don't know how to fix it, please feel free to send
> patches. The ones that were posted here already don't meet all requirements.    

What are all of the requirements that need to be met?  I've seen a few fixes out there, but it would appear that each has their own approach and it resolves a different issue entirely.  What file shall I look in?  I'll provide a patch if I can resolve it and if you can point me in the appropriate direction.

(In reply to comment #31)
> Would we be happy to move this all over to upstart?  Then it just needs to
> "start on networking" or something similar.

Fine by me.  I just want this to work.

I think the requirements are:
- ntpdate has to set the clock (or exit with failure) before services following the ntpdate service are started (maybe only the services which have specified "should-start $time"), this includes ntpd and all other NTP clients
- it shouldn't block indefinitely and it would be nice to exit with failure quickly if we know NetworkManager is not trying to configure an interface

Fixing the /etc/init.d/ntpdate script directly or creating a new upstart script should be both ok.

Maybe adding a support for the workaround from comment #1 to s-c-d (setting NETWORKWAIT in /etc/sysconfig/network when the service is enabled) would be also acceptable.

As systemd is now default in f14, we can fix this by blocking in the ntpdate init script until the network is up. Services that need correct time before starting  can specify "After=ntpdate.service" in their unit files.

In ntp-4.2.6p2-2.fc14 the script retries ntpdate few times in exponentially increasing intervals before giving up, starting from 10 seconds and the default number of retries is 2 (can be configured in /etc/sysconfid/ntpdate).

ntp-4.2.6p2-2.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/ntp-4.2.6p2-2.fc14

ntp-4.2.6p2-3.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/ntp-4.2.6p2-3.fc14

For some reason the options in /etc/sysconfig/ntpdate have changed from:

OPTIONS="-U ntp -s -b"

to

OPTIONS="-q 2"

Looks like "-U ntp -s -b" has been moved to /etc/init.d/ntpdate, but what is expected from "-q 2"?  -q says don't actually set the clock (which is wrong) and "2" is taken as an ip address.

Ah, that should be -p 2, to speed it up a bit (see bug #615802) and to use less network resources.

Fixed in ntp-4.2.6p2-4.fc14.

ntp-4.2.6p2-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ntp-4.2.6p2-4.fc14

ntp-4.2.6p2-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.