LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Time displayed one hour off after recent upgrade (http://www.linuxquestions.org/questions/slackware-14/time-displayed-one-hour-off-after-recent-upgrade-4175442673/)

fogpipe 12-23-2012 08:40 AM

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.

Snark1994 12-23-2012 05:40 PM

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,

fogpipe 12-24-2012 07:22 AM

Code:

[root@odin:m0rl0ck]# ntpdate 0.pool.ntp.org

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.

Snark1994 12-25-2012 03:24 PM

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

Thanks,

rouvas 01-07-2013 04:54 PM

/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.

tronayne 01-08-2013 09:11 AM

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:
Code:

/usr/sbin/ntpq -pn
    remote          refid      st t when poll reach  delay  offset  jitter
==============================================================================
 127.127.1.0    .LOCL.          10 l  53h  64    0    0.000    0.000  0.000
+108.61.73.243  209.51.161.238  2 u  368 1024  377  1416.25  54.687  5.982
+174.123.154.242 216.218.254.202  2 u  594 1024  377  1281.02  -21.571  50.867
*204.2.134.162  204.123.2.72    2 u 1015 1024  377  1150.97    6.000  49.543

The server sections in /etc/ntp.conf for the above is
Code:

server        127.127.1.0        # local clock
fudge        127.127.1.0 stratum 10       
#server  pool.ntp.org
server  0.us.pool.ntp.org
server  1.us.pool.ntp.org
server  2.us.pool.ntp.org

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.

rouvas 01-09-2013 02:16 AM

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

Code:

man ntpd
...
-g, --panicgate
  Allow the first adjustment to be Big.  This option may appear an unlimited number of times.

  Normally,  ntpd exits with a message to the system log if the offset exceeds the panic threshold, which
  is 1000 s by default. This option allows the time to be set to any value without restriction;  however,
  this  can  happen  only once. If the threshold is exceeded after that, ntpd will exit with a message to
  the system log. This option can be used with the -q and -x options.  See the tinker configuration  file
  directive for other options.
...

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?

tronayne 01-09-2013 09:03 AM

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:
Code:

ls -l /etc/local*
-rw-r--r-- 1 root root 3519 Oct 18 12:29 localtime
lrwxrwxrwx 1 root root  30 Oct 18 12:29 localtime-copied-from -> /usr/share/zoneinfo/US/Eastern

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)
Code:

# Start ntpd:
ntpd_start() {
  CMDLINE="/usr/sbin/ntpd -g"
  echo -n "Starting NTP daemon:  $CMDLINE"
  $CMDLINE -p /var/run/ntpd.pid
  echo
}

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.

fogpipe 01-11-2013 10:10 AM

Quote:

Originally Posted by rouvas (Post 4864947)
/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.

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.

fogpipe 01-11-2013 10:13 AM

Quote:

Originally Posted by rouvas (Post 4865938)
Well, that is a really comprehensive answer, but...

Code:

man ntpd
...
-g, --panicgate
  Allow the first adjustment to be Big.  This option may appear an unlimited number of times.

  Normally,  ntpd exits with a message to the system log if the offset exceeds the panic threshold, which
  is 1000 s by default. This option allows the time to be set to any value without restriction;  however,
  this  can  happen  only once. If the threshold is exceeded after that, ntpd will exit with a message to
  the system log. This option can be used with the -q and -x options.  See the tinker configuration  file
  directive for other options.
...

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?


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.

rouvas 01-12-2013 07:11 PM

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?

tronayne 01-13-2013 09:13 AM

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:
Code:

# Start ntpd:
ntpd_start() {
  # Clear the log file (or not, up to you)
  >/var/log/ntp.log

  CMDLINE="/usr/sbin/ntpd -g"
  echo -n "Starting NTP daemon:  $CMDLINE"
  # Start the daemon with logging
  $CMDLINE -p /var/run/ntpd.pid -l /var/log/ntp.log
  # Don't start the daemon with logging
  #$CMDLINE -p /var/run/ntpd.pid

  echo
}

Second way

In /etc/ntp.conf add (right after the drift file entry or so)
Code:

#
# Log file
#
logconfig=allclock +allpeer +allsys +allsync
logfile /var/log/ntp.log
#

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.
Code:

#
# Statistics stuff
#
# statsdir /var/log/ntpstats/  # directory for statistics files
# filegen      peerstats file peerstats type day enable
# filegen      loopstats file loopstats type day enable
# filegen      clockstats file clockstats type day enable



All times are GMT -5. The time now is 03:50 AM.