Time is not synced on (re)boot automatically after a sysupgrade to 22.03.0 #10843
Comments
|
I've had the same issue for a few months now. This seems to have been a post-21 regression of some sort. It's definitely a dependency management issue, where some network access dependency is missing from start_service() {
. /lib/functions/network.sh
+ sleeptime=20
+ sleep $sleeptime
+ logger "slept $sleeptime"
validate_ntp_section ntp start_ntpd_instance
}... and rebooted, getting: ... but when I set ... |
|
Two problems:
|
|
There's a third problem here: Unrelatedly, there's a hotplug race-condition in the network -> sysntpd Edit: To note, this third problem is most easily packaged as, "network updates don't always trigger a change in the procd line and thus restart the daemon upon reload". It is not a good expectation, however, to have the "reload" trigger a new attempt at connecting if the problem is not with a change of configuration at all. So, 'problems' 2 and 3 really don't matter here; detection of changed procd command line works fine and has its own specific purpose. |
|
A fourth problem might be that although busybox ntpd does not produce errors if it fails to act as an NTP client. Looking into what exactly fails in ntpd now. Of the two sets (1 vs 4) of valid problems, only one need be solved. The OpenWrt config with which ntpd doesn't succeed on boot involves an external DNS resolver, so I'm going to guess the issue is some sort of bug with refreshing DNS resolution after a failure that busybox hasn't yet addressed, which would be easiest solved by just waiting until DNS is back, but probably best solved by a patch to busybox. |
|
OK, it's a clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151348, tv_nsec=377491500}) = 0
open("/etc/hosts", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/resolv.conf", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "", 248) = 0
close(3) = 0
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151348, tv_nsec=391753460}) = 0
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151348, tv_nsec=392073940}) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151348, tv_nsec=403804320}) = 0
sendto(3, "\306M\1\0\0\1\0\0\0\0\0\0\0010\7openwrt\4pool\3ntp\3"..., 40, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 40
sendto(3, "\2522\1\0\0\1\0\0\0\0\0\0\0010\7openwrt\4pool\3ntp\3"..., 40, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 40
poll([{fd=3, events=POLLIN}], 1, 2500) = 0 (Timeout)
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151350, tv_nsec=917659980}) = 0
sendto(3, "\306M\1\0\0\1\0\0\0\0\0\0\0010\7openwrt\4pool\3ntp\3"..., 40, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 40
sendto(3, "\2522\1\0\0\1\0\0\0\0\0\0\0010\7openwrt\4pool\3ntp\3"..., 40, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 40
poll([{fd=3, events=POLLIN}], 1, 2500) = 0 (Timeout)
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151353, tv_nsec=422786220}) = 0
close(3) = 0
write(2, "ntpd: bad address '0.openwrt.poo"..., 43) = 43
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151353, tv_nsec=423631820}) = 0
poll([], 0, 143000n) = 0 (Timeout)
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151496, tv_nsec=524269380}) = 0
fork() = 2
clock_gettime64(CLOCK_REALTIME, {tv_sec=1669151496, tv_nsec=526236600}) = 0
poll([], 0, 109000) = 0 (Timeout)What I don't understand is this bit: open("/etc/resolv.conf", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "", 248) = 0
close(3) = 0Why do I get a successful open, but nevertheless read 0 after attempting to read 248B? |
|
OK. The problem is that for systems which do not use dnsmasq for DNS caching, The first run of root@ap3825i0:/proc/2931# grep resolv mountinfo
43 37 0:16 /resolv.conf.d/resolv.conf.auto//deleted /etc/resolv.conf ro,noatime - tmpfs tmpfs rwAfter a restart of root@ap3825i0:/proc/3540# grep resolv mountinfo
43 37 0:16 /resolv.conf.d/resolv.conf.auto /etc/resolv.conf ro,noatime - tmpfs tmpfs rwThis affects all OpenWrt versions post-ujail-transition, but it's not necessarily showing up on all of them, usually because |
|
... and that is this: #10389 @birdie-github I'd appreciate if you can confirm that on first boot, if you find the process ID |
|
The fix for now for this would be to provide DHCP option 42 on your network. When you have a network reload of any kind, the loss and regain of the additional IP address in option 42 will cause two reloads of ntpd in tandem with the recreation of |
|
Correction: two restarts. Reload only causes a restart when the resulting configuration is different. |
WorkaroundStart ntpd directly, without jail Details: |
By default, ntpd is executed in a sandbox. ujail uses bind mounts to give ntpd access to specific files, including resolv.conf. /etc/resolv.conf is a symlink which ultimately points to /tmp/resolv.conf.d/resolv.conf.auto. The bind mount is created on a single file, therefore the mount breaks as soon as the file gets deleted. The bind mount still refers to the deleted source file, even if a new file is created in the same location. The problem can be avoided by not running ujail in a sandbox. The sandbox is disabled by removing the ntpd capabilities file. Upstream issues: - openwrt/openwrt#10389 - openwrt/openwrt#10843 Fixes: #291 Signed-off-by: Fabian Bläse <fabian@blaese.de>
I don't want to file a bug report under packages because I've not been able to find the package for
ntpd. I'm runningOpenWrt 22.03.0 r19685-512e76967f. My device isTP-Link TL-WDR3600 v1. After a sysupgrade the date was set to September 3rd, 2022. Today it's the 29th of September.Of course
opkg updatefailed withwget returned 5.I couldn't find a command to sync the time in a SSH session, so I simply ran
/etc/init.d/sysntpd restartwhich fixed the issue. I waited at the very least 10 minutes for the time to sync automatically. Didn't happen.Please make sure after a sysupgrade time is indeed getting synced.
There are zero
ntprelated messages in the System Log.I've never touched any NTP related settings, everything is AFAIK by default. My Internet connection is working perfectly.
The text was updated successfully, but these errors were encountered: