Am 16.07.20 um 15:48 schrieb Vincent Lefevre: > Here's what I got: > > zira:~> timedatectl timesync-status > Server: 62.210.244.146 (2.debian.pool.ntp.org) > Poll interval: 2min 8s (min: 32s; max 34min 8s) > [...] > > zira:~> timedatectl timesync-status > Server: (null) (3.debian.pool.ntp.org) > Poll interval: 4min 16s (min: 32s; max 34min 8s) > [...] > > zira:~> timedatectl timesync-status > Server: (null) (3.debian.pool.ntp.org) > Poll interval: 8min 32s (min: 32s; max 34min 8s) > [...] > > Then I reenabled the mobile data, and after some time: > > zira:~> timedatectl timesync-status > Server: 37.187.122.11 (0.debian.pool.ntp.org) > Poll interval: 17min 4s (min: 32s; max 34min 8s) > [...] > > The fact that the poll interval increases even when there are > connection issues makes synchronization less likely to have a > chance to work. When I reported the bug, it was 34min 8s (i.e. > the maximum in its default configuration). I suppose that a > workaround would be to change the PollIntervalMaxSec value, > but this would affect the normal usage.
Hm, yeah. I guess it would make sense to reset the poll interval when there is a failure to synchronize (or at least not increase it) > BTW, the way it is handled should be documented (the man pages > don't say anything on its evolution). And I think that failures > should be logged in some way. > > I could report upstream bugs (behavior + documentation + logging). This would be great, thanks. The upstream bug tracker is at https://github.com/systemd/systemd/issues Please report back once you have an issue number so we can cross-link the bug reports. Regards, Michael
signature.asc
Description: OpenPGP digital signature
