[ntp:questions] move_fd() causing bad behavior on AIX5.3

Phillips, Brandon brandon.phillips at lmco.com
Tue Nov 27 16:32:48 UTC 2007


Danny Mayer wrote: 
> One thing that we could do for you is to make the move_fd() code do
> nothing by creating an #ifdef NO_MOVE_FD option so that AIX can
specify
> to ignore it.

This seems like a good idea since it's so broken right now.  You
probably 
want to default IPv6 support off for AIX5 as well.

> It is mature but the ideosyncrasies of the AIX implementation of the
IP
> stacks is causing unnecessary problems.

> I think that basically these are the same thing. The real problem here
> is that the IPv6 wildcard socket is trying to grab the IPv4 wildcard
too
> and it's already bound which is what is causing it to fail. This is a
> bug in the O/S since it shouldn't be doing that.

If we can identify specific problems, we will try to open PMRs with IBM
to correct/track the issues.
 
>> 598: This is interesting since it also complains about the xntpd IBM
>> ships (which we currently use as well).  We have had some issues with
>> the clocks jumping back to 0:00...1970 after reboots; I believe we
>> finally convinced IBM there was a problem.  The other issues
discussed
>> in this bug I am not sure about; we'll have to investigate and see if
>> they are contributing to time related pecularities.

> This is probably an O/S issue where NTP is not able to retrieve or set
> the clock properly.

FYI, the reset-to-1970 issue we encountered (and got IBM to fix) would 
infrequently occurr after a sudden power loss; it would not update later
as is suggested by #598.

The only other "ntp is unreliable" issue we have had with the old xntpd
was tracked down to a priority issue (xntpd was getting starved for CPU,
messing up the algorithms). 

Now that I have a v4 ntpd hacked into functioning on AIX5, we plan to
deploy
it in some of our test runs to see how things behave.



More information about the questions mailing list