Uso una Raspberry Pi 3 y necesito actualizar la hora a través de ntp después de reiniciar el sistema.
Se debe actualizar vía wifi con dhcp. Generalmente funciona, pero la sincronización necesita aprox. media hora y no entiendo por qué.
Cuando quiero iniciar el servicio ntp manualmente con
>>sudo /etc/init.d/ntp restart
Dice „ok“, pero el sistema no hace nada; la hora equivocada todavía está en el RTC.
¿Tienes una idea, cuál podría ser el problema?
Otra información es que la Pi se ejecuta en modo de solo lectura... pero si no funciona sin acceso de escritura, no se actualizará después de media hora, ¿no es así?
Más detalles:
Para completar mi problema aquí está el ntp.conf:
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
Driftfile /var/lib/ntp/ntp.drift
Statistics loopstats peerstats clockstats
Filegen loopstats file loopstats type day enable
Filegen peerstats file peerstats type day enable
Filegen clockstats file clockstats type day enable
...
Server 0.de.pool.ntp.org iburst
Server 1.de.pool.ntp.org iburst
Server 2.de.pool.ntp.org iburst
Server 3.de.pool.ntp.org iburst
Server 127.127.1.0 #local clock
Fudge 127.127.1.0 stratum 10
...
Para ampliar mi explicación sobre mi proyecto. Quiero usar el Pi como servidor NTP. El primer problema fue que el RTC "se escapa" después de un reinicio o cuando el Pi se apaga, especialmente durante un tiempo prolongado. Es por eso que tuve la idea de que la Pi debe ser un cliente NTP la primera vez para configurar el RTC y luego la Pi debe ser un servidor NTP para el dispositivo, que está conectado a través de ethernert con la Pi. Entonces conecté el Pi a través de Wifi para obtener la hora actual. Como ya dije, generalmente funciona, pero lleva demasiado tiempo.
Luego quise hacer la sincronización manualmente con este comando que publiqué antes. Mi idea era hacer esto como un cronjob, pero existe el siguiente problema:1. Pi ignoró el comando; 2. El cronjob también se ignora o se elimina después de reiniciar.
Pero quiero ir paso a paso y el primer problema que quiero resolver es disminuir el tiempo de sincronización.
Espero que ahora tengas una mejor visión general de mi situación...
¿Necesitas más detalles?
NUEVA INFORMACIÓN:01.02.2018
Bien, ahora tengo la solución que quiero, PERO hay un comportamiento que no entiendo. Las configuraciones eran correctas.
Sin embargo, utilizo el WiFi integrado para sincronizar la hora del sistema a través de un servidor NTP, que configuré en ntp.conf. Utilizo ethernet (LAN con cable) como servidor NTP para el dispositivo con cable al RPi. Aquí la configuración de IP:
WLAN (DHCP): 192.168.1.x
Ethernet (static): 192.168.10.10
Puse ambas interfaces en redes diferentes, porque de lo contrario solo funcionaría una conexión. Pero, ¿por qué en realidad?
Y este es el problema principal, por qué la sincronización tomó tanto tiempo. Cuando comento la línea con el reloj local
Server 127.127.1.0
Entonces la sincronización a través de la red funciona inmediatamente...
¿Por qué sucede?
Respuesta aceptada:
El rpi no tiene un RTC, por lo que arranca siempre el 1 de enero de 1970:el tiempo para sincronizar el servidor y el NTP de forma lenta e incremental es mayor; por lo que, de forma predeterminada, NTP no comienza a funcionar con normalidad hasta que se corrige la diferencia entre NTP y el sistema.
Agregaría a su ntp.conf archivo como la primera línea (tiene que ser la primera línea):
tinker panic 0
Se recomienda esta configuración para máquinas virtuales y dispositivos iOT.
tinker panic:especifica el umbral de pánico en segundos con el valor predeterminado
1000 s. Si se establece en cero, la verificación de cordura de pánico se desactiva y se aceptará una compensación de reloj
de cualquier valor.
También consideraría comprar un RTC, ya que es barato, especialmente si tiene la intención de tener proyectos sin conectividad a Internet. ver hwclock no puede abrir el archivo rtc