[Sa] ntp проблем отново
Vladimir Germanov
v.germanov at gmail.com
Thu Mar 1 16:25:47 EET 2012
On 1 March 2012 14:35, Vladimir Germanov <v.germanov at gmail.com> wrote:
> On 1 March 2012 13:09, Vladimir Germanov <v.germanov at gmail.com> wrote:
>> On 1 March 2012 12:48, "Боби Б." <606u at dir.bg> wrote:
>>> On 01.03.2012, at 12:37, Vasil Kolev <vasil at ludost.net> wrote:
>>>> В 09:56 +0200 на 01.03.2012 (чт), Vladimir Germanov написа:
>>>>
>>>>> Благодаря за информацията. Ами аз рестартирах също няколко пъти. В
>>>>> момента nagios-а пак пуска ALERT:
>>>>> Това ми изписва от chek_ntp
>>>>>
>>>>> u7 at phyllis:~$ /usr/lib/nagios/plugins/check_ntp -H u7.ludost.net -v
>>>>> sending request to peer 0
>>>>> response from peer 0: offset -0.7734282017
>>>>> sending request to peer 0
>>>>> response from peer 0: offset -0.7734596729
>>>>> sending request to peer 0
>>>>> response from peer 0: offset -0.7734520435
>>>>> sending request to peer 0
>>>>> response from peer 0: offset -0.7734479904
>>>>> discarding peer 0: flags=3
>>>>> overall average offset: 0
>>>>> NTP OK: Offset unknown|
>>>>> _______________________________________________
>>>>
>>>> Пак същия случай като с leap 11:
>>>>
>>>> 78.128.6.187: Server dropped: Leap not in sync
>>>> server 78.128.6.187, port 123
>>>> stratum 3, precision -22, leap 11, trust 000
>>>> refid [78.128.6.187], delay 0.02846, dispersion 0.00563
>>>> transmitted 4, in filter 4
>>>> reference time: d2f9cf84.32cd47b0 Thu, Mar 1 2012 12:35:48.198
>>>> originate timestamp: d2f9cf88.62bde7b9 Thu, Mar 1 2012 12:35:52.385
>>>> transmit timestamp: d2f9cf89.c08bf330 Thu, Mar 1 2012 12:35:53.752
>>>> filter delay: 0.03592 0.03104 0.03030 0.02846
>>>> 0.00000 0.00000 0.00000 0.00000
>>>> filter offset: -1.35260 -1.35901 -1.36493 -1.36793
>>>> 0.000000 0.000000 0.000000 0.000000
>>>> delay 0.02846, dispersion 0.00563
>>>> offset -1.367931
>>>>
>>>> Виж в предишните thread-ове, Георги имаше същия проблем, мисля, че беше
>>>> проблем на самата виртуалка, не на софтуера вътре.
>>>
>>> discarding peer 0: stratum=0
>>> или
>>> discarding peer 0: flags=3
>>> Според сорса, check_ntp не харесва отговорите. check_ntp приема и -vv.
>>
>> Аз просто не мога да си го обясня при положение, че снощи е работило
>> без проблем и само след рестарт без да са редактирани никакви
>> настройки по ntp... да се получава това просто нямам идея...
>
> Ето в момента работи ОК. Сега го рестартирах
В момента съм го пуснал с debug опции, специално прекомпилирах пакета
за да видя какво се случва. За да инсталирам новите пакети съм apt-get
purge ntp ntpdate и съм изчистил всичко/всички конфигурационни файлове
свързани с ntp и ntpdate. ntp.conf e по-подразбиране. За момента е ОК.
Преди да стартирам ntpd съм направил:
ntpdate bg.pool.ntp.org europe.pool.ntp.org
Това е за момента:
root at u7:~# ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*212.70.148.15 94.26.7.48 2 u 12 64 17 9.241 -32.120 27.980
+kgb.comnet.bg 132.239.1.6 2 u 10 64 17 6.923 -34.257 27.433
+ns2.novatelbg.n 193.204.114.233 2 u 14 64 17 0.472 -1.301 21.869
root at u7:~# ntpdc -c sysinfo
system peer: 212.70.148.15
system peer mode: client
leap indicator: 00
stratum: 3
precision: -22
root distance: 0.02040 s
root dispersion: 0.07140 s
reference ID: [212.70.148.15]
reference time: d2fa02fb.7bbf1b49 Thu, Mar 1 2012 16:15:23.483
system flags: auth monitor ntp kernel stats
jitter: 0.032715 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
Предполагам, че след ~20 мин. ще даде отново Offset unknow... и тогава
ще прикача дебъг файла. Дебъга съм го пуснал с:
/usr/sbin/ntpd -ddddddd -c /etc/ntp.conf -f /var/lib/ntp/ntp.drift -g
-p /var/run/ntpd.pid -s /var/log/ntpstats -u 105:107
Съжалявам, че спам-я листата с това, но аз вече се изчерпах и не знам
какво друго мога да направя....
More information about the Sa
mailing list