[ntp:questions] move_fd() causing bad behavior on AIX5.3
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
> to ignore it.
This seems like a good idea since it's so broken right now. You
want to default IPv6 support off for AIX5 as well.
> It is mature but the ideosyncrasies of the AIX implementation of the
> 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
> 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
>> 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
it in some of our test runs to see how things behave.
More information about the questions