xntpd "broke" and not able to start

[atul2701]

How is the time differance betrween your cliemt server and ntp server.. normaly if its up to 10-15 mins it will sync otherwise xntpd service will exit.. in that case first you need to set the clock mannualy or need to run the ntpdate -u .

[Dennis Handly]

>I'm not sure how to check /sbin/init.d/xntpd to find out the last command

Look for all the exit commands.

[Bill Hassell]

> The clock was set back due to an applciation problem... That this server has to run slower than another authentication server for users logging in to be successful

NTP is designed to maintain UTC (Zulu) time to within a fraction of a second. Forcing the time will cause NTP to try to fix the mistake unless there is more than about a 10 minute difference. If true, NTP (xntpd) will terminate as the difference is too much to correct.

HOWEVER, if you can't fix your badly designed application, you can certainly run the application in a different timezone. There are 86,400 timezones in HP-UX so you should have no problem creating a TZ value that makes your local time offset to whatever you want.

Here's how it works: The man page for environ describes the details for TZ, specifically how to set TZ without using the tztab file. Suppose you want the current time to be 3 hours, 25 minutes and 16 seconds west (behind) UTC (Zulu or GMT) time. Then set TZ=MYTIME3:25:16 and test your time like this:


# echo $TZ
EST5EDT
# date
Mon May 16 16:34:40 EDT 2011
# TZ=MYTIME3:25:16 date
Mon May 16 17:09:32 MYTIME 2011


To make this permanent for all applications and users, change the file /etc/TIMEZONE. Better yet, if only your application is broken, export the new TZ value into your application's startup procedure. Now the local time will be correct (and NTP can run) but your application will think it is 3:25:16 behind Zulu time.

NOTE: MYTIME is any 3 character (or longer) string you want to use to identify this strange time offset. It will be reported as the current timezone when you run the date command.

[laul]

Hi all, thanks for the response. The clock on this server is slower than the time server by around 45 secs.
Checking the permissions of /sbin/init.d/xntpd, it has x for all owner, group and others. But, will check on the permissions of other files it might be calling. Gotta trace how xntpd starts then...

[atul2701]

try to start the xntpd in debug mode (-d option) and share the output..

[rick jones]

Terminology nit - I suspect the badly broken software you mention needs the clock to be "behind" not "slower" - although were it slower it would fall farther and farther behind...

As may have already been pointed-out, if you set the clock back "too far" xntpd will decide that things are too screwed-up for it to do anything and will exit. I would expect a message in syslog to that effect.

If xntpd is running and doesn't bail, then eventually it *will* sync the time to whatever its time source(s) say the time happens to be. So, even if you start your system 45 seconds behind another, unless your time source(s) are reporting time 45 seconds behind what the other server's time source(s) are telling it, this system will end-up at the "correct" time and you will be back to square.

So, I suggest you stop trying to treat the symptom and treat the root cause - the seemingly fubar authentication software.

All that said, if what xntpd is doing remains inscrutable you might try running it "by hand" as root, under "tusc" (have tusc follow forks and be verbose) and then you will be able to see all the system calls it is making and perhaps divine what it is doing.

[Wilfred Chau_1]

could you post the output of the following to us?

grep NTP /etc/rc.config.d/netdaemons

and

grep -v ^# /etc/ntp.conf |grep -v ^$

[Bill Hassell · Accepted solution]

> i did a search on syslog but no entries on ntp. problem is the exit code 126 doesn't return a good result from google too. And i don't know if ntp has any logs in the OS.

When you start xntpd by hand, use this command:

xntpd -l /var/adm/xntpd.log

To make the log location permanent, change the /etc/rc.config.d/netdaemons file to start NTP with this option:

export XNTPD_ARGS="-l /var/adm/xntpd.log"

Now all the NTP messages will be logged outside of HP-UX syslog.

[rick jones]

FWIW, /sbin/init.d/xntpd is not a binary, it is a startup script. So, when you copied it from one system to another, you were not copying the xntpd binary, but rather the script that starts/stops the binary, which is under /usr/sbin .

I cannot claim with certainty that 126 means the same thing here, but some web searching on exit codes finds hits like:

http://tldp.org/LDP/abs/html/exitcodes.html

which suggests an exit code of 126 means the command could not be executed - perhaps for permissions problems like say trying to start xntpd as a user other than root.

[laul]

Hi guys,
thanks all for your contribution. Esp Bill for the tips on logging. Always appreciate tips on how we can troubleshoot. Including Rick's tusc, albeit i don't have it installed currently.

Now the cause.
i did a "ll /usr/sbin/xntpd" and the size of the binary was 0. How and when it ever got to that, is hard to trace. Possibly when the clock was set back, the binary broke.. Well, it works now after replacing the binary..
Once again thanks all.