How to fix time in Arch Linux
systemd-timesyncd will not require you to reboot. I've tested timedatectl on my system. It might be necessary to wait a minute for a connection.
man timedatectl
status
Show current settings of the system clock and RTC, including whether network time synchronization is on. Note that whether network time synchronization is on simply reflects whether the systemd-timesyncd.service unit is enabled. Even if this command shows the status as off, a different service might still synchronize the clock with the network.
$ 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 is lying on my system. Possibly the implementation was patched by Fedora, without patching the manpage. I do not know how to query which service is used; my system happens to use chronyd. I imagine it might also be possible to use ntp/ntpd.
However in your case I would be quite confident that Arch uses the upstream default of 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
You might have errors logged underneath the status. Make sure to run systemctl
as a user with access to the system journal, e.g. using sudo
.
Unlike chronyd with chronyc
, there is no documented way to additionally query systemd-timesyncd
for... anything really, beyond "NTP synchronized: no". Hope it has useful logs!
I suggest aiming to
- Identify which well-known
pool.ntp.org
alias your system is trying to use. - Test the alias e.g.
ntpdate -q arch.pool.ntp.org
. traceroute
to the alias to see if there is a nearby block i.e. a firewall preventing access. As always, I would useping
first because it gets results quicker (and is less prone to mis-interpretation), or use themtr
version of traceroute (this also defaults to ICMP traceroute, which avoids lots of output from multi-path networks). Ultimately you want something liketraceroute -U -p ntp pool.ntp.org
, i.e. using the same UDP port as NTP does.
EDIT: previous versions of this answer were confused about systemd-timesyncd's default NTP servers. Although they are commented out (disabled) in timesyncd.conf
, it should only be necessary to uncomment the line if you need to change the server. The default values are built in to timesyncd at compile time. This is mentioned in all documentation.
https://www.cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working/
https://wiki.archlinux.org/index.php/Systemd-timesyncd