NTPDate é executado três vezes na inicialização, resultando em data incorreta

2

Estou executando o Voyage Linux (uma distribuição baseada no Debian) e estou tendo problemas para obter a data correta. Quando olho em /var/log/daemon.log , vejo o seguinte:

Nov 18 11:04:07 voyage ntpdate[1676]: step time server 203.97.109.165 offset 2141299826.398106 sec
Aug 20 17:06:20 voyage ntpdate[1710]: step time server 119.47.118.129 offset 2141299826.401065 sec
Jun 28 06:36:47 voyage ntpdate[1744]: step time server 203.97.109.165 offset 2141299826.460901 sec

A data correta é Nov 18 11:04:07 , mas está sendo alterada para meados de junho. Como posso consertar isso?

    
por DanielGibbs 17.11.2011 / 23:07

2 respostas

3

Encontrei a solução em este site . O NTPdate tentava atualizar a data toda vez que uma interface subia, o que no meu caso era três vezes durante o processo de inicialização. Por isso, modifiquei /etc/network/if-up.d/ntpdate para executar somente ntpdate se eth0 aumentar adicionando o seguinte ao topo do script:

# Only update the date if eth0 goes up.
if [ "$IFACE" != eth0 ]; then
    exit 0
fi
    
por 18.11.2011 / 00:15
4

[uma resposta muito tardia, mas acrescentada para outros que podem seguir]

limitar as interfaces nas quais você roda o ntpdate pode ser útil, mas parece que o seu maior problema é a falta de hardware de relógio em tempo real, portanto o enorme deslocamento inicial.

Eu sugiro que você veja o pacote fake_hwclock. A partir da descrição do pacote :

Package: fake-hwclock (0.5)

Save/restore system clock on machines without working RTC hardware

Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform filesystem checks at every boot.

On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.

    
por 18.12.2014 / 13:09

Tags