Re: Clock jumps forward.
On Sunday 19 February 2006 18:26, Mirko Parthey wrote:
> On Sat, Feb 18, 2006 at 10:53:09PM +0200, David Baron wrote:
>>> Ntpdate is what I am using. Maybe the setup needs be changed.
>>
>> Which timeservers are you getting the time from? (see /etc/default/ntpdate)
>> Do they provide the correct time?
>>
>> Try "/etc/init.d/ntpdate start", and look in /var/log/syslog for new
>> entries from ntpdate.
>I once had the default file to a server which was placed in my firewall's
>"dmz". Guess what. /etc/default/ntpdate is 0-length.
>
Apparently not. I am not running /etc/init.d/ntpdate at all. Did it explicitly
in cron.daily.
>> If you are using pool.ntp.org, a server is randomly chosen from the pool.
>> You might want to configure ntpdate to always use the same server(s) -
>> this makes it easier to analyze the problem.
>>
>> For debugging, you can also use the command "ntdpate -b -u SERVER", so
>> the output is sent to your terminal rather than syslog.
>I have no entries in my logchecks for ntp. Running the above command to the
>pool yields NO server which is accessable--in other words, the one I was
>using is no longer available there. Allowing ntp outside the dmz from "pool"
>seems to most often be hitting the same one so I will put that in the dmz.
>Might be best in the long run to use the pool, though a tiny bit less secure
>needing to allow many of them through the firewall.
>In other words, the thing has not been working for a while. Funny no error
>messages in the logchecks. Reinstall and dpkg-reconfigure did not give me a
>new default ntpdate file so a made a new one with
>NTPSERVERS="213.222.11.213". Simply using the pool will try a bunch until
>hitting this one. Having the file should take it from there.
The one in my cron command 216.200.93.8 is in the dmz list and certainly does
work (apparently is not in the pool).
So ... no, the problem is not solved in ntpdate.
Reply to: