Well, no promises, but I am shooting for one of the next two releases
of OpenSolaris. A backport to Solaris 10 is a possibility, but not
highly probable. As for the version of NTP, I am constantly working
with the latest development release. At some I'll have to freeze that
of course. For polit
Danny Mayer wrote:
> David J Taylor wrote:
>> Unruh wrote:
>> []
>>> Of course if the unix system time were TAI then the leapsecond issue
>>> would not arise as far as the kernel were concerned. It would be
>>> cleaner to have the kernel on TAI and the translation to user space
>>> time via zoneinf
David J Taylor wrote:
> Unruh wrote:
> []
>> Of course if the unix system time were TAI then the leapsecond issue
>> would not arise as far as the kernel were concerned. It would be
>> cleaner to have the kernel on TAI and the translation to user space
>> time via zoneinfo using a leapseconds file.
Brian Utterback wrote:
> David J Taylor wrote:
>
>> If Solaris or HP-UX is still supplying NTP 3, I would be rather
>> worried.
>
> Be worried then. The latest bundled version of NTP on Solaris is xntpd
> 3-5.93e.
>
> Not too worried though. I hope to have V4 available in OpenSolaris
> soon.
> Bria
David J Taylor wrote:
> If Solaris or HP-UX is still supplying NTP 3, I would be rather worried.
>
Be worried then. The latest bundled version of NTP on Solaris is xntpd
3-5.93e.
Not too worried though. I hope to have V4 available in OpenSolaris soon.
Brian Utterback
Unruh wrote:
[]
> Of course if the unix system time were TAI then the leapsecond issue
> would not arise as far as the kernel were concerned. It would be
> cleaner to have the kernel on TAI and the translation to user space
> time via zoneinfo using a leapseconds file.
I don't like that idea, init
ma...@ntp.isc.org (Danny Mayer) writes:
>Folkert van Heusden wrote:
>>> I don't recall ever seeing a report of NTP causing problems with normal
>>> operations.
>>
>> Sorry for being anal on this but:
>> Well almost: certain versions of the linux kernel under certain specific
>> conditions would
hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
>>Seemed I made myself not totally clear: The system has NO network connection
>>to the outside world, but will be the time source of a little network. (NOT
>>internet-connected, for security reasons.) NTPDATE (which is deprecated
>>
>Seemed I made myself not totally clear: The system has NO network connection
>to the outside world, but will be the time source of a little network. (NOT
>internet-connected, for security reasons.) NTPDATE (which is deprecated
>anyway) does not work with reference clocks, it can query servers
>on
Juergen Perlinger wrote:
> Hi everybody,
>
> One of the things that can be annoying is that NTPD cannot do an initial
> synchronization from (most) reference clocks over a difference of more
> than 4 hours.
>
> The reason is that 'refclock_process()' calls 'clocktime()' which in turn
> will only
j...@specsol.spam.sux.com wrote:
[]
> Solaris 10 Update 6 IS the latest release of Solaris and the provided
> NTP is nowhere near the latest downloadable version of NTP.
>
> I would have to check, but I am pretty sure the same is true for
> HP-UX.
>
> Not everyone runs Linux nor do they usually cho
Folkert van Heusden wrote:
>> I don't recall ever seeing a report of NTP causing problems with normal
>> operations.
>
> Sorry for being anal on this but:
> Well almost: certain versions of the linux kernel under certain specific
> conditions would panic when ntp introduces a leap second.
> http:
Terje Mathisen wrote:
> Andy Helten wrote:
>
>> Unruh wrote:
>>
>>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>>> used. If ntpd -g fails it is a bug.
>>>
>>>
>> Then it is a bug because, as previously mentioned, no command line
>> argument or tinke
David J Taylor
wrote:
> j...@specsol.spam.sux.com wrote:
> []
>> The point is LOTS of places have extensive procedures in place that
>> must be followed before any software on production systems can be
>> changed, including applying vendor supplied and recommended patches.
>>
>> While I have free
j...@specsol.spam.sux.com wrote:
[]
> The point is LOTS of places have extensive procedures in place that
> must be followed before any software on production systems can be
> changed, including applying vendor supplied and recommended patches.
>
> While I have free reign to do anything I want with
Folkert van Heusden wrote:
>> I don't recall ever seeing a report of NTP causing problems with
>> normal operations.
>
> Sorry for being anal on this but:
> Well almost: certain versions of the linux kernel under certain
> specific conditions would panic when ntp introduces a leap second.
> http://
David J Taylor
wrote:
> j...@specsol.spam.sux.com wrote:
> []
>> What planet do you people live on?
>>
>> I have one client that will not even allow Windows critical security
>> updates to be installed until a extensive formal test is done to
>> "prove" the updates won't effect operations.
>>
>>
> I don't recall ever seeing a report of NTP causing problems with normal
> operations.
Sorry for being anal on this but:
Well almost: certain versions of the linux kernel under certain specific
conditions would panic when ntp introduces a leap second.
http://markmail.org/message/dhm5byrbfcarpiet
j...@specsol.spam.sux.com wrote:
[]
> What planet do you people live on?
>
> I have one client that will not even allow Windows critical security
> updates to be installed until a extensive formal test is done to
> "prove" the updates won't effect operations.
>
> This is hardly a unique operation.
David J Taylor
wrote:
> j...@specsol.spam.sux.com wrote:
> []
>> You do understand there are lots of environments where it takes an
>> act of God to be allowed to replace vendor utilities with self
>> compiled versions, don't you?
>
> Not a problem with Windows, fortunately.
>
> David
What p
In article <9bca36-5p@mail.specsol.com> j...@specsol.spam.sux.com writes:
>Unruh wrote:
>> j...@specsol.spam.sux.com writes:
>>
>
>>>Have you never heard of calling ntpdate before starting the NTP daemon?
>>
>>
>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>>
j...@specsol.spam.sux.com wrote:
[]
> You do understand there are lots of environments where it takes an
> act of God to be allowed to replace vendor utilities with self
> compiled versions, don't you?
Not a problem with Windows, fortunately.
David
_
j...@specsol.spam.sux.com writes:
>Unruh wrote:
>> j...@specsol.spam.sux.com writes:
>>
>>>Have you never heard of calling ntpdate before starting the NTP daemon?
>>
>>
>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>> used. If ntpd -g fails it is a bug.
>>
>Uh
Richard B. Gilbert wrote:
> j...@specsol.spam.sux.com wrote:
>> Unruh wrote:
>>> j...@specsol.spam.sux.com writes:
>>>
Have you never heard of calling ntpdate before starting the NTP daemon?
>>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>>> used. If ntpd -g fai
j...@specsol.spam.sux.com wrote:
> Richard B. Gilbert wrote:
>> j...@specsol.spam.sux.com wrote:
>>> Unruh wrote:
j...@specsol.spam.sux.com writes:
> Have you never heard of calling ntpdate before starting the NTP daemon?
uh, ntpdate is severely depricated, and ntpd -g is what
Richard B. Gilbert wrote:
> j...@specsol.spam.sux.com wrote:
>> Unruh wrote:
>>> j...@specsol.spam.sux.com writes:
>>>
>>
Have you never heard of calling ntpdate before starting the NTP daemon?
>>>
>>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>>> used. If nt
j...@specsol.spam.sux.com wrote:
> Unruh wrote:
>> j...@specsol.spam.sux.com writes:
>>
>
>>> Have you never heard of calling ntpdate before starting the NTP daemon?
>>
>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>> used. If ntpd -g fails it is a bug.
>>
>
> Uhh,
Andy Helten wrote:
> jimp wrote:
>
>> Andy Helten wrote:
>>
>>> Heiko Gerstung wrote:
>>>
Juergen Perlinger schrieb:
> Hi everybody,
>
> One of the things that can be annoying is that NTPD cannot do an initial
> synchronization from (most) referenc
wrote in message
news:9bca36-5p@mail.specsol.com...
> Unruh wrote:
>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed
>> to be used. If ntpd -g fails it is a bug.
>
> Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still
> have ntpdate, e.g. Solaris 10.
Y
Unruh wrote:
> j...@specsol.spam.sux.com writes:
>
>>Have you never heard of calling ntpdate before starting the NTP daemon?
>
>
> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
> used. If ntpd -g fails it is a bug.
>
Uhh, lots of mainline 'nix's don't have a -g op
On 2009-01-05, Andy Helten wrote:
> No one has answered the OP question and apparently no one understands
> the behavior as well as myself and the OP.
It may well be that very few people have observed the behavior described
by the OP. And none of those individuals frequent this news-group.
--
Andy Helten wrote:
> Unruh wrote:
>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>> used. If ntpd -g fails it is a bug.
>>
>
> Then it is a bug because, as previously mentioned, no command line
> argument or tinker can disable this behavior. I suppose the solutio
Unruh wrote:
> j...@specsol.spam.sux.com writes:
>
>
>> Andy Helten wrote:
>>
>>> Heiko Gerstung wrote:
>>>
Juergen Perlinger schrieb:
> Hi everybody,
>
> One of the things that can be annoying is that NTPD cannot do an initial
> synchron
j...@specsol.spam.sux.com writes:
>Andy Helten wrote:
>> Heiko Gerstung wrote:
>>> Juergen Perlinger schrieb:
>>>
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more th
jimp wrote:
> Andy Helten wrote:
>
>> Heiko Gerstung wrote:
>>
>>> Juergen Perlinger schrieb:
>>>
>>>
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of mor
Andy Helten wrote:
> Heiko Gerstung wrote:
>> Juergen Perlinger schrieb:
>>
>>> Hi everybody,
>>>
>>> One of the things that can be annoying is that NTPD cannot do an initial
>>> synchronization from (most) reference clocks over a difference of more than
>>> 4 hours.
>>>
>>> The reason is that
Heiko Gerstung wrote:
> Juergen Perlinger schrieb:
>
>> Hi everybody,
>>
>> One of the things that can be annoying is that NTPD cannot do an initial
>> synchronization from (most) reference clocks over a difference of more than
>> 4 hours.
>>
>> The reason is that 'refclock_process()' calls 'cl
Juergen Perlinger schrieb:
> Hi everybody,
>
> One of the things that can be annoying is that NTPD cannot do an initial
> synchronization from (most) reference clocks over a difference of more than
> 4 hours.
>
> The reason is that 'refclock_process()' calls 'clocktime()' which in turn
> will onl
Hi everybody,
One of the things that can be annoying is that NTPD cannot do an initial
synchronization from (most) reference clocks over a difference of more than
4 hours.
The reason is that 'refclock_process()' calls 'clocktime()' which in turn
will only accept time stamps that are in a hard-cod
39 matches
Mail list logo
