problemas do servidor ntp. Está em pânico e então estou 3 horas à frente

Question

Não tenho certeza do que configurei incorretamente e não consigo instalar e executar um servidor ntp confiável. Note que este é apenas um servidor ntp da intranet.

O servidor é um sistema slackware e, portanto, o arquivo de configuração é baseado no modelo que encontrei:

interface ignore wildcard
interface listen 127.0.0.1
interface listen eth0
interface listen eth1
server 3.gr.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 0.europe.pool.ntp.org iburst
server  127.127.1.0 # local clock
fudge   127.127.1.0 stratum 10  
driftfile /etc/ntp/drift
multicastclient 224.0.1.1       # listen on default 224.0.1.1
broadcastdelay  0.008
restrict default kod nomodify notrap noquery nopeer
restrict 3.gr.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 0.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 192.168.18.0 mask 255.255.255.0 nomodify notrap
restrict 127.0.0.1
logfile /var/log/ntp.log

para um despejo do conf com comentários, veja: link

observe que a rede 192.168.18.0 é a intranet local que esse servidor ntp atende.

um trecho do log dos últimos meses. Não vejo nenhuma informação útil.

30 Nov 15:41:12 ntpd[28591]: 194.177.210.54 interface 192.168.201.210 -> (none)
30 Nov 15:41:12 ntpd[28591]: Deleting interface #1 eth0, 192.168.18.10#123, interface stats: received=136483, sent=136483, dropped=0, active_time=7277307 secs
30 Nov 15:41:12 ntpd[28591]: Deleting interface #0 lo, 127.0.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7277307 secs
30 Nov 15:41:12 ntpd[28591]: 127.127.1.0 interface 127.0.0.1 -> (none)
30 Nov 15:41:12 ntpd[28591]: peers refreshed
30 Nov 15:41:15 ntpd[28591]: ntpd exiting on signal 15
 1 Dec 13:56:56 ntpd[1650]: Listen normally on 6 multicast 224.0.1.1 UDP 123
 1 Dec 13:56:56 ntpd[1650]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
 5 Dec 22:51:42 ntpd[18694]: Listen normally on 6 multicast 224.0.1.1 UDP 123
 5 Dec 22:51:42 ntpd[18694]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
27 Feb 14:17:23 ntpd[18694]: Deleting interface #5 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 secs
27 Feb 14:17:23 ntpd[18694]: Deleting interface #4 eth0, fe80::21a:92ff:fe3a:ac17#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 sec
s
27 Feb 14:17:23 ntpd[18694]: Deleting interface #3 eth1, fe80::211:6bff:fe32:f77e#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 sec
s
27 Feb 14:17:23 ntpd[18694]: Deleting interface #2 eth0, 192.168.18.10#123, interface stats: received=120122, sent=120122, dropped=0, active_time=7226742 secs
27 Feb 14:17:23 ntpd[18694]: Deleting interface #1 eth1, 192.168.201.210#123, interface stats: received=6261, sent=7292, dropped=0, active_time=7226742 secs
27 Feb 14:17:23 ntpd[18694]: 155.207.113.227 interface 192.168.201.210 -> (none)
27 Feb 14:17:23 ntpd[18694]: Deleting interface #0 lo, 127.0.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 secs
27 Feb 14:17:23 ntpd[18694]: 127.127.1.0 interface 127.0.0.1 -> (none)
27 Feb 14:17:23 ntpd[18694]: peers refreshed
27 Feb 14:17:27 ntpd[18694]: ntpd exiting on signal 15
27 Feb 17:32:45 ntpd[1642]: Listen normally on 6 multicast 224.0.1.1 UDP 123
27 Feb 17:32:45 ntpd[1642]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
12 Mar 22:11:51 ntpd[9153]: Listen normally on 6 multicast 224.0.1.1 UDP 123
12 Mar 22:11:51 ntpd[9153]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
12 Mar 22:11:51 ntpd[9153]: ntpd: time slew +0.000000 s
12 Mar 19:40:09 ntpd[9564]: Listen normally on 6 multicast 224.0.1.1 UDP 123
12 Mar 19:40:09 ntpd[9564]: Joined 224.0.1.1 socket to multicast group 224.0.1.1

mas de vez em quando o servidor ntp irá parar de funcionar. Quando eu verifico novamente, ele se afastou 3 horas à frente. E eu não acho que essas 3 horas sejam um número aleatório. Isso pode estar relacionado ao fato de que estou no horário EET (ou EEST).

A hora da BIOS está definida para a hora local (como posso verificar isso no linux?)

Depois de executar ntpdate 3.gr.pool.ntp.org , recebo o seguinte:

root@halki:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+postmortem.csd. 122.231.59.246   2 u   18   64    1   15.646   21.219   0.471
*ntp.jine.se     192.36.144.22    2 u   16   64    1   78.292    3.687   0.251
+static-ip-85-25 192.168.100.15   2 u   15   64    1   50.748   -2.676   1.071
 LOCAL(0)        .LOCL.          10 l   25   64    1    0.000    0.000   0.000

Há algo errado com meu ntp.conf?

Talvez com as configurações de fuso horário do meu sistema?

Não sei como verificar isso. Eu sei que selecionei "Europa / Atenas" durante a instalação há alguns anos, mas a variável $ ZZ do fuso horário que está retornando retorna uma string vazia.

date parece correto no momento, mas não posso ter certeza de que vai continuar assim.

root@halki:~# date
Thu Mar 12 20:22:39 EET 2015

alguém pode dar algumas dicas sobre o que poderia estar errado / o que verificar?

EDITAR

no slackware linux, o arquivo de configuração para o relógio do hardware está em /etc/hardwareclock . Isso está definido para "localtime" no meu caso. Esse arquivo é verificado durante a inicialização por /etc/rc.d/rc.S para definir o relógio como UTC ou horário local.

Parece haver algo errado com o RTC.

root@halki:/etc# hwclock --show --debug
hwclock from util-linux 2.21.2
hwclock: Open of /dev/rtc failed: No such file or directory
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

Isso não parece normal. Talvez algo esteja faltando no meu kernel, mas alguém pode verificar?

    

Answer 1

yet every so often the ntp server will stop working. When I check it out again it has drifted 3 hours ahead. And I do not think these 3 hours are a random number. This may be related to the fact that I am on EET (or EEST) time.

Se isso significa que uma máquina é reiniciada e, em seguida, o tempo desarrumada, pode ser por causa do seu sistema operacional, erroneamente, acha que o relógio do hardware indica a hora como UTC. Em seguida, adiciona 3 horas ao tempo que responderam por hardware.

Então, se o problema acontecer depois de uma reinicialização, informe ao sistema operacional que o hardware armazena a hora como hora local (que por sua saída de data está no fuso horário EET):

# hwclock --localtime

Em seguida, ajuste a hora do sistema em date -d até chegar a hora correta. No final, salve esse tempo no relógio do hardware:

# hwclock --systohc

BIOS time is set to local time (how can I check that from within linux?)

hwclock diz qual data é armazenada aqui, mas não será informada. É correto vê-la como UTC ou hora local; Espero que você o informe sobre isso.

I am not sure how to check those. I know I have selected "Europe/Athens" during installation a few years ago, but echoing timezone variable $TZ returns an empty string.

Seu fuso horário é impresso por date . Verifique /etc/timezone , que pode conter o nome do fuso horário, por ex. Europa / Atenas ou /etc/localtime , que podem conter (ou vinculados a um arquivo contendo) dados zoneinfo; como arquivos residem em /usr/share/zoneinfo .

    

Answer 2

Deve haver um arquivo de configuração em /etc , que indica se o relógio do hardware está configurado para UTC ou hora local. Esse sinalizador deve ser usado na reinicialização para ajustar a hora do sistema, se apropriado. No Ubuntu o arquivo é /etc/default/rcS .

Também deve haver um local onde você possa adicionar sinalizadores ao comando ntpd quando ele for iniciado. Adicione -g aos sinalizadores e ntpd parará de entrar em pânico na reinicialização. Por padrão, ele se recusará a inicializar se o relógio estiver desligado por mais de 1000 segundos. Parece que você está fora por várias vezes isso, então ntpd pânico como projetado. A opção -g impedirá o pânico de inicialização.