NTP view

[Marcelo Fco. Pereira Jr]

Hi,

i have two systems in my project but i need to syncronize the server B with 20 - 25 sec later of server A. The two servers is configured to a NTP Server and the time is equal in both. I read the man of command ntpdate and don have any arguments to create thist configuration, exisits any command to read the time of NTP Server and don apply in the Client??? I ask this because if exists I will make a script for read the time of NTP Server sum 20 seconds and apply this time to Server B.

Thanks.

[A. Clay Stephenson]

There is nothing in NTP to do this and, indeed, this is contrary to the very nature and design of NTP. If you want to do this then you need to stop the xntpd daemon on one of your boxes and issue a date command to change the date in a step fashion or issue a date -a 20 (or -20) to gradually adjust the time by 20 seconds. I can't imagine why this would ever be a good idea. If you attempt to restart the xntpd daemon after this change, it will immediately start doing its job and try to correct the time.

It might help if you explain what you are trying to do rather than how you are trying to accomplish it.

[Marcelo Fco. Pereira Jr]

EhehHEH sorry but i don't have ideai why the application need this. The responsable for the system ask me if this is possible, he needs the server B always have the exactly 20 - 25 sec more of server A. My fear is to make a script with the server B make a ntpdate and after a date -a 20 but i will extremally dependent of crond.

[Court Campbell]

yeah this is weird. i guess you could write a script to get then time from the other box and add 20 seconds to it. Then set the time from that. And to make it even better you could run the cronjob every 5 seconds. Hehe. Now that would be funny.

[Steven E. Protter]

Shalom,

Cron can not do this, and as noted won't.

Best solution is to get a very accurate clock device for the second system and set it behind the 20 seconds you need .

B will have to get its time from the clock you add to your setup.

SEP

[A. Clay Stephenson]

Whenever I have had to do something like this, I put the onus on the application itself. It would be rather trivial to create a macro that wraps the time() system call with a getenv("TIMEOFFSET") and adds that value to time() --- and this is the way that this insanity should be handled.

However, here is a Plan B that should be run on your application host. It assumes that the other host is running NTP. I'll assume that you are better at shell scripting than Perl scripting so I will minimize the use of Perl.

----------------------------------------
#!/usr/bin/sh

typeset REMHOST=remotebox
typeset DELTA=22 # seconds difference

typeset -i STAT=0
typeset -i REMSECONDS=0
typeset -i LOCSECONDS=0
REMSECONDS=$(remsh ${REMHOST} perl -e \'print time\')
LOCSECONDS=$(perl -e 'print time')
typeset -i DIFF=$((${LOCSECONDS} - ${REMSECONDS}))
typeset -i OFFSET=$((${DIFF} + ${DELTA}))
if [[ ${OFF} -lt -1 || ${OFF} -gt 1 ]]
then
date -a ${OFF}
STAT=${?}
fi
exit ${STAT}
-----------------------------------------

The idea is that when the time if off by more than 22 +- 1 seconds, we adjust the time to bring it back to 22 seconds. You will need to disable xntpd on the application host. This is untested but it should be very close and I would say that you need run it via cron no more often than every 2 hours. There will be some latency with the remsh but the +- 1 second should compensate.

However, your first task should be to find out exactly why this is needed because lying about system time is state-of-the-art-stupid and you should also consider the impact on the other application on this box. How will they fare running under incorrect time. If you are running NFS, your date stamps are suspect.

[Bill Hassell · Accepted solution]

Hooray for HP-UX -- there is a way to do this (as stupid a request as it is). All computers should run their clocks in UTC (also known as Zulu or GMT time) and offset the references to time based on local requirements. HP-UX is particularly easy to do this. In fact, you can have a thousand users from a thousand different timezones all logged in at once and they will see their local time accurately. The secret is the TZ variable and a helper file called tztab.

A review of the man page for environ (man environ) tells you all about the TZ variable. You can set the offset to *ANY* value in hours, minutes *and* seconds. So I have now invented two new timezones called DUMB and DUMBER and these timezone are offset exactly 10 seconds before and after GMT:

$ TZ=DUMB00:00:10 date;TZ=GMT0 date;TZ=DUMBER-00:00:10 date
Tue Mar 27 18:47:09 DUMB 2007
Tue Mar 27 18:47:19 GMT 2007
Tue Mar 27 18:47:29 DUMBER 2007

These three date commands are run with different TZ values. The DUMB timezone has an offset of 00:00:10 from UTC time (the internal HP-UX time), while the GMT0 timezone is the same as UTC. Likewise, DUMBER-00:00:10 is offset 10 seconds the other way from GMT0. So, you can invent any timezone you want and it applies to any process(es) that have that value for TZ -- on the same computer. To make the DUMBER timezone effective for every user on serverB, edit the file /etc/TIMEZONE with the lines:

TZ=DUMBER-00:00:10
export TZ

So, yes, it is possible to offset any number of seconds, minutes or hours from GMT on HP-UX. And as you may have surmised from my examples, it is both a DUMB and a DUMBER request. My guess is that certain processes on serverA must complete some task prior to related processes on serverB and the developers have guessed that 25 seconds is enough delay to keep things in sync. If this is the case, find new developers -- these systems *will* get out of sync someday or worse, serverA will be heavily loaded and serverB's 25 secs delay must be changed to 2 hours and maybe later to 18 hours -- what a mess. This is an example of trying to tinker with the OS to fix a bad design.

[A. Clay Stephenson]

I admit Bill's approach is better than mine - I think. I wasn't sufficiently warped in my thinking to come up with that approach. However, Bill's approach will not work if the application is using gmtime() or epoch seconds in it's calculations.

If this were me, I would have the application developers sitting right in front of me with my baseball bat clearly visible. If they could not provide me with a sufficiently good reason for this time adjustment, I would use the baseball bat for about 20-25 seconds of programmer cranial adjustment.

[Marcelo Fco. Pereira Jr]

Tks everyone for the tips... the solution with configurantion of TZ works well... Now i will have some fight with the developers...

Tks!!! :-)