Bug 197393 - Default installation should have provision for correct time
Default installation should have provision for correct time
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-06-30 15:53 EDT by David Anderson
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-26 10:48:23 EDT
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 David Anderson 2006-06-30 15:53:33 EDT
IMO, it should not be considered acceptable nowadays that after installing 
Fedora Core, manual action is needed in order to get correct time. Windows XP 
has had automatic SNTP since 2001.

I suggest a cron.hourly or cron.daily cron job that syncs time. This is better 
than running the NTP daemon permanently, because we do not want to add extra 
services to run by default on startup.

The only problem with this would be if the user sets up NTP manually, he may 
not realise he needs to turn off the manual job. But this would be easy to 
deal with - the cron script can check if NTP daemon is running or not.

Suggested cron.hourly (or daily) script:

/sbin/service ntpd status >/dev/null || /usr/sbin/ntpdate -s clock.redhat.com 
>/dev/null 2>/dev/null

Alternatively, the script could check if NTP is _meant_ to be running (by 
looking for the PID file), to deal with the case that NTP has crashed (the 
admin may not wish ntpdate to be running in this case).

Maybe you'd want a variable and a file in /etc/sysconfig/ in order to turn 
this off, but I cannot think of any reason why anyone would want to turn it 
off. The only reason to turn it off would be because the user is running ntpd.
Comment 1 Miroslav Lichvar 2006-07-26 10:48:23 EDT
I agree it would be convenient to many users to have something like this
enabled by default, but it's unlikely to happen.

Running ntpdate from cron is generally a bad idea. It will not keep very good
time at first place, after every ntpdate call the clock will drift again.

However, the reason why ntpdate will never be in crontab by default is that it
would cause a major network problem, imagine that all the systems connected to
internet in a timezone query a server in the same time.

Running ntpd is a better idea, but I still think it is better to have it
disabled by default.
Comment 2 David Anderson 2006-07-27 05:07:43 EDT
Drifting: That's not a huge problem. We're talking here about users who don't 
have the expertise or don't care enough about the precision enough to run 
ntpd. We're talking about users who just want their clocks not to run into 
minutes of drift.

I run ntpdate hourly via cron. Windows XP seems to sync via SNTP weekly. 
It's "good enough". Anyone running a server should run ntpd, I agree. My 
machines, with ntpdate hourly, drift by about 0.4 seconds an hour. If I cared 
about that I'd run ntpd, I'm not running a server, so it's fine.

Major network problem: Fedora already faces this issue with automated yum 
updates (and ClamAV database updates in Extras). In both cases, it introduces 
a randomised delay in order to avoid the problem. We could do the same here.

Please consider re-opening!
Comment 3 Miroslav Lichvar 2006-07-27 06:31:35 EDT
The SNTP implemented in Windows XP is a service running all the time. Please
drop the idea about putting ntpdate into the crontab.

Enabling the ntpd service is easy. Even user who doesn't know anything about NTP
will notice the "Network Time Protocol" tab in the system-config-date dialog.
You can file a bug for system-config-date if you think it's not easy or obvious

BTW, there is a SNTP utility in ntp-4.2.2 packages, unfortunately it's not ready
to be a service yet.

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