Por que meu ntpd não funciona?

Question

Editar

Eu tentei todas as suas sugestões, mas parece que o ntpd apenas se recusou a sincronizar com o servidor.

[vivs@peter-centos ~]$ /usr/sbin/ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================
 192.168.0.30    .LOCL.           1 u   11   64    3    0.984  232732. 20083.2

Este jitter "20083.2" indica que a hora foi alterada manualmente?

Eu desativei a sincronização de horário do vmware.

Pergunta original

Aqui está o status do ntp

[root@peter-centos gw]# /usr/sbin/ntpq -pn
 remote           refid      st t when poll reach   delay   offset  jitter
=============================================
 192.168.0.30    .LOCL.           1 u  153 1024  377    0.950  1905553 274023.
*127.127.1.0     .LOCL.          10 l    9   64  377    0.000    0.000   0.001

Você pode ver que apenas sincroniza com '127.127.1.0', que é o relógio local.

É porque o offset é muito grande?

Mas depois de configurar manualmente a data pelo comando date , ela ainda se recusa a sincronizar com 192.168.0.30

Isso pode ser ntp.conf

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org
#server 1.centos.pool.ntp.org
#server 2.centos.pool.ntp.org
server 192.168.0.30 #blf
#broadcast 192.168.1.255 key 42         # broadcast server
#broadcastclient                        # broadcast client
#broadcast 224.0.1.1 key 42             # multicast server
#multicastclient 224.0.1.1              # multicast client
#manycastserver 239.255.254.254         # manycast server
#manycastclient 239.255.254.254 key 42  # manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
#server 127.127.1.0     # local clock
#fudge  127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
lkey 8
h the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
lkey 8
olkey 8
lkey 8

    

Answer 1

Ah - agora fica claro:

My machine is installed in vmware workstation. So, form all the answers, I guess maybe the jitter becomes so large is because that vmware adjust the time. I will see if I am right.

Não execute o ntp em uma VM. O computador host não garante fatias da CPU, portanto, o relógio da VM não é exato. Como você pode ver, o ntp está tentando acompanhar o que parece ser um relógio externo de variação descontrolada e, eventualmente, desiste.

A resposta geral para esse problema é não executar o ntp, instalar as ferramentas do VMware e bloquear o relógio da VM no relógio do host.

A resposta específica depende da versão do Linux que você está executando. Eu tenho algumas notas sobre o CentOS (provavelmente geralmente aplicável a outras distribuições da família RedHat) aqui .

    

Answer 2

Primeiro, pare o ntpd e tente definir a data usando ntpdate {server}:

/etc/init.d/ntp stop
/usr/sbin/ntpdate 192.168.0.30

Isso ajusta seu tempo corretamente? Ou isso acaba?

Se expirar, tente outro servidor NTP:

/usr/sbin/ntpdate pool.ntp.org

A partir do jitter alto, eu esperaria que o ntpdate funcionasse - uma vez que tenha, reinicialize se possível (apenas reinicie o ntpd se você não puder reinicializar - embora muitos serviços fiquem confusos com um salto de tempo), e verifique ntpq -p novamente.

    

Answer 3

Esse é um valor muito grande de jitter (274023). Isso indica que você pode ter tentado alterar a hora manualmente enquanto o ntpd estava sendo executado. O que você deve fazer é parar o ntpd, definir a hora para a hora correta e depois reiniciar o ntpd.

    

Answer 4

O VMware tem as melhores práticas para cronometragem do Linux:

link

    

Answer 5

Como alguém mencionado acima, acho que a resposta principal está incorreta.

Para VMWare, eles recomendam explicitamente o uso de ferramentas NTP sobre VMWare em suas melhores práticas de marcação de tempo para convidados Linux. Além disso, para todas as VMs, você deve adicionar a diretiva tinker panic 0 à parte superior do arquivo /etc/ntp.conf para garantir que o horário seja corrigido, independentemente do desvio atual, o que é comum para as VMs conforme indicado.

Trecho: Práticas recomendadas de marcação de tempo para convidados do Linux

NTP Recommendations

VMware recommends using NTP instead of VMware Tools periodic time synchronization. NTP is an industry standard and ensures accurate timekeeping in your guest. It may be necessary to open the firewall (UDP 123) to allow NTP traffic.

Link para completo Doc: link

    

Answer 6

Isso faz isso por mim:

sudo service ntpd stop
sudo /usr/sbin/ntpdate 0.europe.pool.ntp.org
sudo service ntpd start

Lista de servidores NTP:

link

Para a Eslovênia:

link