Prized Season software

No último artigo deixei em aberto qual seria a melhor solução para actualizar a data de uma máquina VMware que, já vimos, tem uma resolução de tempo péssima.

• hwclock --systohc

Este comando (tem que ser executado como root) actualiza o relógio interno (PCI/CMOS, ou outro); em detalhe, a hora do sistema (Linux date&time) é escrito no relógio interno. Daí o nome ("sys" = system, "to", "hc" = hardware clock). Façamos então façamos os seguintes passos:

• rm /etc/adjtime
  

Começamos do zero.

• hwclock --systohc --debug

O ficheiro /etc/adjtime é re-escrito.
Vejamos o resultado:

1. [root@fuji log]# hwclock --systohc --debug
2. hwclock 2.4c/util-linux-2.11f
3. hwclock: Open of /dev/misc/rtc failed, errno=2: No such file or directory.
4. Using direct I/O instructions to ISA clock.
5. Last drift adjustment done at 1174827422 seconds after 1969
6. Last calibration done at 1174827422 seconds after 1969
7. Hardware clock is on local time
8. Assuming hardware clock is kept in local time.
9. Waiting for clock tick...
10. ...got clock tick
11. Time read from Hardware Clock: 2007/03/25 13:57:44
12. Hw clock time : 2007/03/25 13:57:44 = 1174827464 seconds since 1969
13. Time elapsed since reference time has been 0.503192 seconds.
14. Delaying further to reach the next full second.
15. Setting Hardware Clock to 13:57:44 = 1174827464 seconds since 1969
16. Not adjusting drift factor because it has been less than a day since the last calibration.

O ficheiro /etc/adjtime é actualizado. Numa máquina VMware (Debian Sarge) o resultado é certamente diferente. Vejamos em baixo: na linha 3 vemos que a chamada ao RTC (real-time clock) funcionou.

1. cock:~# hwclock --debug
2. hwclock from util-linux-2.12p
3. Using /dev/rtc interface to clock.
4. Last drift adjustment done at 1174828004 seconds after 1969
5. Last calibration done at 1174828004 seconds after 1969
6. Hardware clock is on local time
7. Assuming hardware clock is kept in local time.
8. Waiting for clock tick...
9. ...got clock tick
10. Time read from Hardware Clock: 2007/03/25 14:08:02
11. Hw clock time : 2007/03/25 14:08:02 = 1174828082 seconds since 1969
12. Sun 25 Mar 2007 02:08:02 PM WEST -0.672650 seconds
13. cock:~# hwclock --debug | grep ^Hw.clock.time.:
14. Hw clock time : 2007/03/25 14:08:28 = 1174828108 seconds since 1969

Para já não há nada de especial a notar.

Uma nota breve: chateia-me um pouco o facto do resultado do comando hwclock dar a hora em AM/PM.
Por isso, prefiro usar:
% hwclock --debug | grep ^Hw.clock.time.: | sed 's/[A-Za-z: ]*\([0-9/: ]*\).*/\1/'
2007/03/25 14:10:59
Ou:
% hwclock --debug | grep ^Hw.clock.time.: | awk '{print $5,$6}'

No entanto, depois de actualizar o relógio da máquina cock (que é VMware) usando "ntpdate 10.0.0.1" (onde 10.0.0.1 é o servidor ntp que tenho local), depois de tudo limpo, e passado uns cinco minutos:

cock:~# hwclock --debug | grep ^Hw.clock.time.: | awk '{print $5,$6}'
2007/03/25 14:17:59
cock:~# date
Sun Mar 25 14:13:06 WEST 2007

Aqui sim há algo que me surpreendeu realmente. A data a verde está síncrona com a data actual, ao passo que a data a vermelho está realmente atrasada. No ficheiro de /etc/adjtime também não há nada de especial (o drift-time, que é o primeiro parâmetro, está a zero, porque não passou um dia).
Ando há semanas a tentar ver qual a maneira mais simples de actualizar uma máquina virtual: na dúvida se seria o ntpd (que não se aguenta bem, dado o drift brutal), se o ntpdate chamado de 5 em 5 minutos... e chego à conclusão que basta usar o relógio RTC da máquina virtual!



C:\>net time /querysntp
The current SNTP value is: time.windows.com,0x1

The command completed successfully.