Há um mês, vários serviços no meu VPS pararam de funcionar. Depois de brincar por cerca de uma hora, descobri que o tempo havia congelado. Suponho que foi algum tipo de bug de virtualização e uma reinicialização logo corrigiu o problema.
No entanto, hoje eu estava tentando executar meu backup S3 e o SSL falhou devido ao horário errado. ao verificar a hora que recebo:
Current default timezone: 'Europe/London'
Local time is now: Sat Jul 11 22:03:02 BST 2009.
Universal Time is now: Sat Jul 11 21:03:02 UTC 2009.
tim@vps:~$ sudo ntpdate ntp.ubuntu.com
11 Jul 22:03:30 ntpdate[3901]: step time server 91.189.94.4 offset -14404.833448 sec
Agora estou no Reino Unido e claramente acabou de passar das 18h03.
Tentei definir a data manualmente:
sudo date +%T -s "18:03:30"
e quando eu li de volta, não mudou
O que eu errei?
EDITAR:
Eu corri:
tim@vps:/var/log$ sudo hwclock --utc
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
tim@vps:/var/log$ sudo hwclock --localtime
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
tim@vps:/var/log$ sudo hwclock --show
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
EDITAR NOVAMENTE:
Já reiniciei e continua o mesmo.
também:
tim@vps:~$ sudo hwclock --debug --show
hwclock from util-linux-ng 2.13.1
hwclock: Open of /dev/rtc failed, errno=2: No such file or directory.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.
Responder1
Atualizar:Não sei nada sobre Xen. Mas láhá muitas páginas por aíque discutem sua situação.
Aqui está algo que encontrei:
Por padrão, os XenVMs têm seus relógios sincronizados com o servidor XenEnterprise que os hospeda e ignorarão as solicitações para ajustar o horário feitas por um daemon NTP, se houver algum em execução. Se você deseja que um XenVM tenha um relógio independente, faça logon em seu console de texto e emita o comando
echo 1 > /proc/sys/xen/independent_wallclock
em seguida, execute um daemon NTP.
Para voltar ao padrão, emita o comando
echo 0 > /proc/sys/xen/independent_wallclock
Antes da atualização:Provavelmente é um problema de virtualização. Que tipo de software de virtualização você está usando? E quais são as configurações de horário no host?
Responder2
A primeira coisa que vem à mente é para qual fuso horário você está configurado?
A segunda coisa que vem à mente tem a ver com a configuração do relógio do hardware - você está usando o UTC no hardware ou a hora local? A maioria das instalações recomenda usar o horário UTC no hardware e então o sistema se ajustará por fuso horário, embora existam opções para fazer o oposto e ter o relógio do sistema e do hardware no horário local. Isso pode levar a confusão ocasional.
Para Linux, você pode tentar usar ohoras(8)programa, que tem opções para definir a hora do sistema para o relógio do hardware e definir o relógio do hardware para a hora do sistema. Sim, você deve ser capaz de definir a hora através dodata(1)comando, mas é melhor usar isso.
Eu também consideraria o uso do pool NTP mundial em comparação ao pool fornecido pelo fornecedor. Você pode usá-lo a qualquer momento acessando pool.ntp.org.
Responder3
Se você está falando sobre um Xen VPS, geralmente o relógio é gerenciado pelo domínio privilegiado dom0, do qual eu presumo que o provedor de hospedagem cuidaria. Contanto que o dom0 tenha a hora correta e/ou esteja executando um daemon NTP para manter a hora do sistema sincronizada, não deverá haver necessidade de nenhum domU executar o próprio ntpd.
Tenho vários servidores Xen nos quais só executo o ntpd no dom0 e todas as máquinas virtuais domU estão com a hora correta. Se você estiver de fato em um Xen VPS, arriscaria supor que o provedor de hospedagem tem um problema com o horário na própria máquina. Eu sei que na maior parte da documentação do Xen é recomendado zerar o /sbin/hwclock como um arquivo vazio, pois isso causará problemas na inicialização se ele realmente tentar interagir diretamente com o relógio do hardware por causa da virtualização.
Responder4
tente dpkg-reconfigure tzdata para ter certeza de que está configurado para utc. Além disso, verifique se você tem o ntpd instalado e apontou para um dos conjuntos de servidores NTP do pool.ntp.org.