jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
Signup
Haus Chores
  • Haus Chores
  • HAUS-112

ntp to sync clocks

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Task Task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Buildmeister
  • Labels:
    None
  • Number of attachments :
    0

Description

Since folks are doing cronjobs on the buildmeister, it'd probably be wise to have all the machines agreeing on roughly what time it is.

We seem to have about 2 hours of skew between the boxen at this point.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
bob mcwhirter added a comment - 19/Jul/03 11:53 PM

45 0 * * * /usr/sbin/ntptimeset -s 2>&1 > /dev/null

45 after midnight (whatever it's concept of midnight might happen to be), syncs time against tick/tock and another server.

cron'd on both falstaff and ale. had to install the rpms for libcap and ntp on ale. falstaff was already happy.

Show
bob mcwhirter added a comment - 19/Jul/03 11:53 PM 45 0 * * * /usr/sbin/ntptimeset -s 2>&1 > /dev/null 45 after midnight (whatever it's concept of midnight might happen to be), syncs time against tick/tock and another server. cron'd on both falstaff and ale. had to install the rpms for libcap and ntp on ale. falstaff was already happy.
Hide
Permalink
bob mcwhirter added a comment - 19/Jul/03 11:54 PM

shoulda closed this.

Show
bob mcwhirter added a comment - 19/Jul/03 11:54 PM shoulda closed this.
Hide
Permalink
peter royal added a comment - 20/Jul/03 8:08 AM

why not just run NTP continuously rather than daily? that way they are never out of sync!

Show
peter royal added a comment - 20/Jul/03 8:08 AM why not just run NTP continuously rather than daily? that way they are never out of sync!
Hide
Permalink
bob mcwhirter added a comment - 20/Jul/03 9:05 AM

'cuz I tried running ntpd, and it'd just deer-in-headlights for me and not actually do anything. ntptimeset was the only thing I could get working.

be my guest...

Show
bob mcwhirter added a comment - 20/Jul/03 9:05 AM 'cuz I tried running ntpd, and it'd just deer-in-headlights for me and not actually do anything. ntptimeset was the only thing I could get working. be my guest...
Hide
Permalink
bob mcwhirter added a comment - 21/Jul/03 11:43 PM

matt-the-sysadmin recently jumped through his ass to get ntpd working for his day job, and has generously offered to get our boxen set up corectly, instead of my cronjob hack.

Werken's buying him Thai on Wednesday to compensate.

Show
bob mcwhirter added a comment - 21/Jul/03 11:43 PM matt-the-sysadmin recently jumped through his ass to get ntpd working for his day job, and has generously offered to get our boxen set up corectly, instead of my cronjob hack. Werken's buying him Thai on Wednesday to compensate.
Hide
Permalink
bob mcwhirter added a comment - 22/Jul/03 11:37 PM

Heya,

I think I've completed the NTP stuff, at least mostly. However, there's
a test that should be performed before I do the last thing or two: please
reboot stout and make sure he comes back to life properly.

Here's the run-down...

falstaff is your local time master. He synchronizes off three of the
best public NTP servers out there. ale and stout synchronize off of
falstaff.

All three beers use actual NTP (ntpd) to do their synch; no more
ntptimeset or whatever.

All three also dump their system time into the hardware clock once a
day so that recovery from a power failure will put them at least close
to right. That's in root's crontab.

On boot, each system should use ntpdate to grab the current time and
slam it into the clock. No skew; slam. Boom: the time is now Right.
I've built something that should do this. It's on stout, which is why
he should be rebooted. If it works, I'll enable it on the others.

The ntpd is running out of rc.local on all systems. Screw all that
init.d crap, and screw RedHat, and screw their idea of how ntpd should
run (which, by the way, was wrong).

I have falstaff broadcasting ntp version 4 time packets onto the wire.
This might synchronize the Mac and/or the Tivo; it depends on whether
they listen and, if so, to what version. I didn't sniff that out, but
can if you want. If the periodic blinkenlight bothers you, commend out
the "broadcast" line in falstaff:/etc/ntp.conf, kill that ntpd, and run
it again with '/usr/sbin/ntpd -U ntp'.

How do you know if it's working? Well, you can get the date on all
systems and see how close they are. You also can use ntpq, which
works basically like this (as seen from stout):

root@stout# ntpq -p falstaff
remote refid st t when poll reach delay offset jitter
==============================================================================
10.42.42.255 0.0.0.0 16 - - 64 0 0.000 0.000 4000.00
*ntp2.usno.navy. .USNO. 1 u 63 64 177 67.106 22.187 29.521
+ns2.usg.edu .GPS. 1 u 56 64 377 56.014 19.927 5.886
+cuckoo.nevada.e time.nist.gov 2 u 4 64 377 96.637 24.512 3.470

root@stout# ntpq -p ale
remote refid st t when poll reach delay offset jitter
==============================================================================
*falstaff ntp2.usno.navy. 2 u 56 64 177 0.189 -0.416 8.265

root@stout# ntpq -p stout
remote refid st t when poll reach delay offset jitter
==============================================================================
falstaff ntp2.usno.navy. 2 u 34 64 7 0.177 -11.116 5.666

The * items are in use (time is in synch). The + items are potential: if
a * goes away, it'll fall back to the +. ale is in synch with falstaff.
stout isn't. It takes about 5-8 minutes (I think--haven't measured) for
these things to decide to synch up. (stout synched up.)

The ntpdate program is another good one for testing; use "-d" to keep it
from actually changing your clock. 'ntpdate -d falstaff' will report on
how things are on falstaff.

I've made a dinky little script on falstaff called "checktime" that'll
give you a quick report:

[root@falstaff bin]# ./checktime
on 10.42.42.42 offset is 0.000002 seconds at 22 Jul 23:45:17
on 10.42.42.51 offset is -0.008236 seconds at 22 Jul 23:45:18
on 10.42.42.52 offset is 0.020758 seconds at 22 Jul 23:45:18

Not surprisingly, falstaff is pretty much in synch with himself (line 1).

So... I think that's it. If you add nodes, either copy stuff over or
yell and I will. For "good enough for now" type service on those new
nodes, I'd cron this:

*/10 * * * * /usr/bin/ntpdate 10.42.42.42 > /dev/null 2>&1

-Matt

Show
bob mcwhirter added a comment - 22/Jul/03 11:37 PM Heya, I think I've completed the NTP stuff, at least mostly. However, there's a test that should be performed before I do the last thing or two: please reboot stout and make sure he comes back to life properly. Here's the run-down... falstaff is your local time master. He synchronizes off three of the best public NTP servers out there. ale and stout synchronize off of falstaff. All three beers use actual NTP (ntpd) to do their synch; no more ntptimeset or whatever. All three also dump their system time into the hardware clock once a day so that recovery from a power failure will put them at least close to right. That's in root's crontab. On boot, each system should use ntpdate to grab the current time and slam it into the clock. No skew; slam. Boom: the time is now Right. I've built something that should do this. It's on stout, which is why he should be rebooted. If it works, I'll enable it on the others. The ntpd is running out of rc.local on all systems. Screw all that init.d crap, and screw RedHat, and screw their idea of how ntpd should run (which, by the way, was wrong). I have falstaff broadcasting ntp version 4 time packets onto the wire. This might synchronize the Mac and/or the Tivo; it depends on whether they listen and, if so, to what version. I didn't sniff that out, but can if you want. If the periodic blinkenlight bothers you, commend out the "broadcast" line in falstaff:/etc/ntp.conf, kill that ntpd, and run it again with '/usr/sbin/ntpd -U ntp'. How do you know if it's working? Well, you can get the date on all systems and see how close they are. You also can use ntpq, which works basically like this (as seen from stout): root@stout# ntpq -p falstaff remote refid st t when poll reach delay offset jitter ============================================================================== 10.42.42.255 0.0.0.0 16 - - 64 0 0.000 0.000 4000.00 *ntp2.usno.navy. .USNO. 1 u 63 64 177 67.106 22.187 29.521 +ns2.usg.edu .GPS. 1 u 56 64 377 56.014 19.927 5.886 +cuckoo.nevada.e time.nist.gov 2 u 4 64 377 96.637 24.512 3.470 root@stout# ntpq -p ale remote refid st t when poll reach delay offset jitter ============================================================================== *falstaff ntp2.usno.navy. 2 u 56 64 177 0.189 -0.416 8.265 root@stout# ntpq -p stout remote refid st t when poll reach delay offset jitter ============================================================================== falstaff ntp2.usno.navy. 2 u 34 64 7 0.177 -11.116 5.666 The * items are in use (time is in synch). The + items are potential: if a * goes away, it'll fall back to the +. ale is in synch with falstaff. stout isn't. It takes about 5-8 minutes (I think--haven't measured) for these things to decide to synch up. (stout synched up.) The ntpdate program is another good one for testing; use "-d" to keep it from actually changing your clock. 'ntpdate -d falstaff' will report on how things are on falstaff. I've made a dinky little script on falstaff called "checktime" that'll give you a quick report: [root@falstaff bin] # ./checktime on 10.42.42.42 offset is 0.000002 seconds at 22 Jul 23:45:17 on 10.42.42.51 offset is -0.008236 seconds at 22 Jul 23:45:18 on 10.42.42.52 offset is 0.020758 seconds at 22 Jul 23:45:18 Not surprisingly, falstaff is pretty much in synch with himself (line 1). So... I think that's it. If you add nodes, either copy stuff over or yell and I will. For "good enough for now" type service on those new nodes, I'd cron this: */10 * * * * /usr/bin/ntpdate 10.42.42.42 > /dev/null 2>&1 -Matt
Hide
Permalink
bob mcwhirter added a comment - 26/Jul/03 11:00 AM

everything's syncing.

Show
bob mcwhirter added a comment - 26/Jul/03 11:00 AM everything's syncing.

People

  • Assignee:
    Unassigned
    Reporter:
    bob mcwhirter
Vote (0)
Watch (0)

Dates

  • Created:
    19/Jul/03 1:50 PM
    Updated:
    26/Jul/03 11:00 AM
    Resolved:
    26/Jul/03 11:00 AM
  • Atlassian JIRA (v5.2.7#850-sha1:b2af0c8)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.