ntpd(8) exits quietly after fork()

[Chuck Swiger]

On Mar 13, 2007, at 3:46 PM, Kevin Kinsey wrote:
> The ktrace is on "ntpd -C /etc/ntp.conf -l $HOME/ntp.log" --- I'd  
> seen nothing at all in /var/log/messages (was running tail on it  
> while restarting it several times), so I pointed it there.  The  
> full ktrace is rather long, any point to posting it?  It did  
> complain about some missing files, but seemed to accept others and  
> go on.  Here's most of the complaints in snippage form....
>
>  <snip>
>  12195 ktrace   NAMI  "/sbin/ntpd"
>  12195 ktrace   RET   execve -1 errno 2 No such file or directory
>  12195 ktrace   CALL  execve(0xbfbfe710,0xbfbfec5c,0xbfbfec74)
>  12195 ktrace   NAMI  "/bin/ntpd"
>  12195 ktrace   RET   execve -1 errno 2 No such file or directory
>  <snip>
>  12195 ntpd     CALL  open(0x280a2c48,0,0x1b6)
>  12195 ntpd     NAMI  "/etc/libmap.conf"
>  12195 ntpd     RET   open -1 errno 2 No such file or directory
>  <snip>
>  12195 ntpd     NAMI  "/etc/malloc.conf"
>  12195 ntpd     RET   readlink -1 errno 2 No such file or directory
>
>  These don't seem to be related, but IANAE ;-)

It seems to be having problems locating the ntpd binary to fork/exec  
it as a child?  Is it possible the path in the /etc/rc.d/ntpd script  
isn't sane?  ntpd should be in /usr/sbin/ntpd....

> Grepping "ntp" in /etc/syslog.conf returns nada, so that would  
> explain why there's nothing there.  I did get "status 2040" in  
> $HOME/ntp.log, so I'm guessing bad driftfile was the issue?
>
>> Showing your ntp.conf file would also help, but if you'd like to  
>> see an example of a working stratum-2 conf file which has been in  
>> use for quite some time:
>
> Nice, ty.  Mine's simple:
>
> $ cat /etc/ntp.conf
> server time.nist.gov
> server navobs1.wustl.edu
> driftfile /var/ntpd.drift
>
> I've got it running fine now in FG (-n) option, and the slaves are  
> happy ATM.  I guess I could give it a "&" ;-)
>
> It did complain that sanity limit was exceeded after I started it  
> with -n, which would explain this, maybe?

You might try checking "ntpq -p" and seeing whether your offset is  
too large.  In that case, killing ntpd, running "ntpdate -b  
time.nist.gov", and then restarting ntpd might help.

> However, it was exiting prior to any mention of this previously,  
> and I was *quite certain* that this box did the DST thing just  
> fine, aside from sendmail logging behind as discussed in a thread  
> on questions.

ntpd operates against GMT/UTC, and doesn't care about DST issues at  
all, fortunately.  :-)

> Either way, thanks for the reply!

You're welcome...

-- 
-Chuck