Solución:
systemd-timesyncd no requerirá que reinicie. He probado timedatectl en mi sistema. Puede que sea necesario esperar un minuto para establecer la conexión.
hombre timedatectl
estado
Muestra la configuración actual del reloj del sistema y el RTC, incluido si la sincronización de la hora de la red está activada. Tenga en cuenta que si la sincronización de la hora de la red está activada simplemente refleja si la unidad systemd-timesyncd.service está habilitada. Incluso si este comando muestra el estado como apagado, un servicio diferente podría sincronizar el reloj con la red.
$ timedatectl status
Local time: Wed 2017-01-11 13:45:07 GMT
Universal time: Wed 2017-01-11 13:45:07 UTC
RTC time: Wed 2017-01-11 13:45:07
Time zone: Europe/London (GMT, +0000)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: yes
timedatectl manpage está en mi sistema. Posiblemente la implementación fue parcheada por Fedora, sin parchear la página de manual. No sé cómo consultar qué servicio se utiliza; mi sistema usa chronyd. Imagino que también podría ser posible usar ntp / ntpd.
Sin embargo, en su caso, estaría bastante seguro de que Arch usa el valor predeterminado upstream de timesyncd.
$ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled;
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
$ systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor pres
Active: active (running) since Mon 2017-01-09 19:09:39 GMT; 1 day 18h ago
Main PID: 928 (chronyd)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/chronyd.service
└─928 /usr/sbin/chronyd
Es posible que tenga errores registrados debajo del estado. Asegúrate de correr systemctl
como usuario con acceso al diario del sistema, p. ej., utilizando sudo
.
A diferencia de Chronyd con chronyc
, no hay una forma documentada de consultar adicionalmente systemd-timesyncd
para … cualquier cosa en realidad, más allá de “NTP sincronizado: no”. ¡Espero que tenga registros útiles!
Sugiero apuntar a
- Identifique cuáles conocidos
pool.ntp.org
alias que su sistema está intentando usar. - Pruebe el alias, por ejemplo
ntpdate -q arch.pool.ntp.org
. -
traceroute
al alias para ver si hay un bloque cercano, es decir, un cortafuegos que impida el acceso. Como siempre, usaríaping
primero porque obtiene resultados más rápido (y es menos propenso a malas interpretaciones), o utilice lamtr
versión de traceroute (esto también tiene como valor predeterminado traceroute ICMP, que evita una gran cantidad de resultados de redes de múltiples rutas). Al final quieres algo comotraceroute -U -p ntp pool.ntp.org
, es decir, utilizando el mismo puerto UDP que NTP.
EDITAR: las versiones anteriores de esta respuesta estaban confundidas acerca de los servidores NTP predeterminados de systemd-timesyncd. Aunque están comentados (desactivados) en timesyncd.conf
, solo debería ser necesario descomentar la línea si necesita cambiar el servidor. Los valores predeterminados están integrados en timesyncd en tiempo de compilación. Esto se menciona en toda la documentación.
https://www.cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working/
https://wiki.archlinux.org/index.php/Systemd-timesyncd