Estou executando o Arch Linux. Recentemente, quando ligo meu PC, a hora do sistema está definida para 1h00 de 1º de janeiro de 1970 - provavelmente 1h00 é a mudança de fuso horário.
Alguém tem alguma idéia de por que systemdnão está configurando a hora do sistema corretamente?
Alguma saída útil (eu acho) ...
[root@alex-desktop network.d]# timedatectl status
Local time: Sun 2013-06-09 16:33:04 BST
Universal time: Sun 2013-06-09 15:33:04 UTC
RTC time: Sun 2013-06-09 15:18:50
Timezone: Europe/London (BST, +0100)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2013-03-31 00:59:59 GMT
Sun 2013-03-31 02:00:00 BST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2013-10-27 01:59:59 BST
Sun 2013-10-27 01:00:00 GMT
Responder1
Eu tive um problema semelhante com um Raspberry Pi (queaparentementenão temRTC), então ou você está usando um dispositivo semelhante que também não possui um (improvável), ou seu computador é um pouco mais antigo e a bateria do RTC, também conhecida comoBateria CMOSficou vazio.
De acordo com você timedatectl statusvocê já tem o NTP habilitado, que deve consultar um servidor de horário e definir o horário para você. No entanto, isso parece não funcionar se você não estiver conectado à Internet no horário definido ao inicializar o computador, o que pode acontecer se você estiver usando WLAN e demorar muito para se conectar.
No final, minha solução foi adicionar um cron job para root ( su -c "crontab -e") ser executado ntpd -suma vez por minuto para forçar a verificação da hora, assim:
# sync network time every minute (this is sad)
* * * * * ntpd -s
Problema resolvido.
O NTPDPágina de manual do ntpd.confmenciona uma minpollopção que supostamente pode ser usada para fazer a verificação do ntpd com uma frequência de até 8 segundos. Obviamente, isso é mais de 9.000 vezes melhor e atualizarei minha resposta se funcionar conforme o esperado.