Time displayed one hour off after recent upgrade
 

3rd edit: OK never mind i forgot about ntpdate and fixed the problem myself.
Someone who does such things can delete this if they want to.

Using timeconfig as root to set the time to US/eastern, results in the time being an hour earlier than actual EST. I have tried setting the hardware clock to both UTC and local and rebooted twice, no joy.

Help appreciated, thanks.

Oh and i should mention that im on 64 current and this happend only after the recent upgrade to 3.7.1

EDIT: starting ntpd from /etc/rc.d/rc.ntpd with a public timeserver listed in /etc/ntp.conf gets me no joy
2nd edit: the date command lists EST as the time.

Bumped off 0-reply list: if you could post a clear explanation of what you did to fix the problem, then anyone else who has the same problem can benefit from your solution. Glad you got it solved, in any case.

Regards,

Seems to have been what did the trick. I also listed the above server in /etc/ntp.conf .
0.pool.ntp.org is a public time server.

Also i guess i should mention that i put the above in a cron job to run daily.

Oh, sorry, and please mark the thread as SOLVED using the link at the top of the page.

Thanks,

/etc/rc.d/rc.ntpd start starts NTP with /usr/sbin/ntpd -g.

Isn't this supposed to be the same as ntpdate? AFAIK ntpd -g gradually adjusts time to what ntpdate brutally does.

Not quite -- if your local clock is too far off (something like more than 5 minutes or so), the daemon will not synchronize it; i.e., the clock needs to be set to near the correct time so that the daemon can "walk" it into sync and keep it there. This is particularly important when the system is a laptop or where the power is off for extended periods.

Say your clock is all screwed up, like, oh, 2.5 hours off. You use ntpdate to set it (the daemon definitely will not) then start the daemon to keep it on time. The daemon will analyze drift (all computer clocks drift), set a factor in /etc/ntp/drift that it uses to gradually adjust the clock. The details about this are found at http://www.eecis.udel.edu/~mills/ntp...iscipline.html along with other documentation pages.

What it gets down to is that if you clock is off more than 5 minutes, stop the daemon (if it's running) then set it with ntpdate. Start the daemon, wait a few minutes, then see if you've synchronized with ntpq -pn (and, if not, wait a few more minutes, it can take some time). When things are synchronized, you should see something like this:
The server sections in /etc/ntp.conf for the above is
It is, by the way, important to have the local clock defined as shown; what it does is allow the daemon to continue synchronizing with the local clock if the Internet (or external time reference) goes away periodically; when the Internet comes back, the daemon just synchronizes with an external server and keeps on going.

Hope this helps some.

Well, that is a really comprehensive answer, but...

so I'm thinking that each time the system starts ntpd -g can be invoked and time will gradually be adjusted.

In fact I have observed this behaviour in some systems will in others it has no effect.

Also, using ntpdate to manually adjust the time backwards is a recipe for disaster (e.g. try to do it while an Oracle database is running).
How do you handle these cases?

It seems like many problems with clocks come up when the system is dual-booted with Windows (any Windows); if you've got the system running Linux when stupid time happens (and NTP is running) the switch to or from daylight savings time happens just as it should. Then, you boot Windows and, viola! one hour off. The fix is to simply shut off the automatic adjustment in Windows and be done with it. Of course, this all assumes that the time zone on the Linux side of the world is set to the correct location; ls -l /etc/local* is a quick and dirty way:
All my systems have the system clock (the hardware clock) set to UTC and the "software" clock set to US-Eastern (which does switch to and from daylight; UTC never switches) and all my systems run NTP. The one that has occasionally, well, once, been a problem is a laptop that is normally sitting on a shelf and turned off. As it happens, the hardware clock in the thing seems to stay pretty much on time over weeks or even months without the system running but I have had machines in the past that were old enough for the on-board battery to go dead and then all bets are off about what the hardware clock is or has been doing.

The easiest way I've found for dealing with the clock problem is that on first boot after a long period of storage is to check and possibly set the hardware clock in the BIOS (just have to remember to do that and I don't always). If the hardware clock is close to actual time (within 5 minutes), booting it will let NTP start and synchronize without a problem.

The other way, when I notice that the clock is way out of whack, is to put the system in single-user mode (which shuts down pretty much everything of any consequence) and set the clock with the date utility or ntpdate then reboot. You don't have to do that (it's kind of the nuclear option): if the clock is slower than actual time, you can shut down the NTP daemon (/etc/rc.d/rc.ntpd stop, set the clock with either the date or ntpdate utility, then restart NTP (/etc/rc.d/rc.ntpd start), wait a few minutes and execute /usr/sbin/ntpq -pn and see what you've got. On the other hand, if the clock is faster than actual time, depending upon how faster (this is a judgement call, by the way), you can either do the above (stop the daemon, set the clock with date/ntpdate) or shut it down to single user (init 1 comes in handy here), set the clock and reboot (init 6, for example). If you don't want you data bases screwed up, the best option is to get into single user to fiddle with it, I believe.

Slackware starts the NTP daemon with (in /etc/rc.d/rc.ntpd)
where the -g allows the first adjustment to be big. Too, the NTP daemon gets started before things like MySQL and PostgreSQL do (don't know about Oracle, but I'd bet that it get started well after NTP does).

It's pretty typical the NTP is reliable as all get out; the thing works, it works well, you don't have to fiddle with it and your systems stay synchronized (within a millisecond or so, at least well within one second). The only thing you really have to mess with is the initial server section (you really do want three pool server specified and you really do the locahost/fudge lines in there) in /etc/ntp.conf. I've found that setting the hardware clock to UTC and the system clock to the local time zone is a real good idea and that another real good idea is to disable the automatic daylight time adjustment in Windows if you're dual booting.

Just as an aside, I have a Win7 guest installed in VirtualBox; VirtualBox does not allow Windows to mess with the hardware clock at all but I still disable the automatic adjustment "just in case" (you never know what damage those Windows boys will impose on you with you knowing about it until it's too late, eh?).

Hope this helps some.

I didnt want to start the daemon and open a port so i didnt really investigate that option as much as i might have otherwise.

I dont worry about them myself :) if ntpdate runs at boot and with the rest of the daily cron jobs i dont see the time changing that much in 24 hours and i only reboot for power failures and kernel upgrades.

Well I suppose each one to his needs, but I need to run my machines on months without rebooting.
Such issues do worry me.
And to be honest, I still haven't found a satisfactory answer for setting the clock back in time while the system is operational.
I'm open to suggestions.

@tronayne: no, I don't dual boot or run Windows even on virtual instances. Sure, NTP is pretty reliable, but everything breaks down eventually. What do we handle it?

My system run 24/7 for months (except the laptop that's usually turned off). I've been running NTP for roughly 20-25 years on various systems (Unix, Solaris, Linux) with zero problems keeping the system clocks synchronized with both internal (reference clocks) and external (the Internet) time references.

Over time there have been changes (in the U.S. anyway) to when daylight time begins and ends, leap seconds added every so often, power interruptions, who knows what all. Other than the last leap second (which required manually resetting the date and restarting the daemon because of some glitch or other that I think has been fixed) there just haven't been any problems keeping everybody sync'd and happily mumbling to each other. I'd say that's pretty darned reliable.

My Internet connection is satellite -- no DSL, no cable, no broadband, no wi-fi, no nuthin' where I live except satellite and, shudder, 56K dial-up (which I continue to pay for just in case of solar flares or winds or whatever that knocks out the satellite). And NTP syncs 'em all.

There are optional time references -- you can buy a reference clock that connects to your server or LAN and you use NTP to keep you clocks sync'd. They're radio (like WWV) or GPS. Work fine, no external time reference(s) needed. There's a whole section of the NTP documentation describing these at http://www.ntp.org/ntpfaq/NTP-s-refclk.htm. Downside? You need to buy one (hey, the Internet is, you know, free). Hook one on a box, make it your LAN time server, sync all the other boxes to that one and you're done. If you get a Ethernet one, plug it in to a router or switch and sync all your boxes to that.

For my money, the NTP daemon is started at boot, continues running until the system(s) is/are rebooted for some reason or other and is started again at the reboot. I used to be paranoid about checking NTP logs, don't do that any more, the thing just works. I don't set the time with ntpdate at boot or any other time, just don't need to, the daemon does what it's supposed to.

They're your systems, you can do as you wish with them.

Hope this helps some.

Logging NTP, two ways, first way

In /etc/rc.d/rc.ntpd make the start section look like this:
Second way

In /etc/ntp.conf add (right after the drift file entry or so)
If you want to keep statistics, add this and uncomment as appropriate. This really is only useful if you have a time reference and you're serving time to your network.