On 19/07/16 07:06, Mart Raudsepp wrote: > Ühel kenal päeval, E, 18.07.2016 kell 16:25, kirjutas james: >> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote: >>> * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr: >>>> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko <bircoph@gento >>>> o.org> wrote: >>>>> Set it for a minute or two. This will protect from commits from >>>>> really out-of-sync systems (like 14 days mentioned above) and >>>>> will >>>>> keep usablity hight for others. >>>> >>>> I second this "request" :) >>>> >>>> remote: Your system clock is off by 6 seconds (limit 5) >>> >>> Why not fix your system clock? No ntpd running? >>> >>> Check 'ntpq -pn' >>> >>> -Marc >>> >> >> net-misc/openntpd is simple and might do the job well enough, or is >> net-misc/ntp a hard requirement ? >> > > or just > > systemctl enable systemd-timesyncd.service > systemctl start systemd-timesyncd.service > > if you are fortunate enough to run systemd. > If not, well, some other ntp client indeed, no need to debate fortunes > further :) > > If there's no RTC clock ticking and syncing during/after suspend, > something seems off in my experience. Disabled ACPI? :D > > I didn't find any indications of why this is actually a problem in the > announcement or replies, and I couldn't read the backlog for the > explanation that I saw might have skimmed through. I think if we want > to nitpick what the actual drift allowed is, we need to know the > reasons this restriction is needed and what could be the difference to > that unspecified potential rsync issue between a seconds of drifts and > a couple minutes or an hour or so of drift. > I'm sure infra will adjust if possible and choose what's best :) > > > Mart >
or configure ntpd appropriately - look into the -g argument to ntpd, or "tinker panic 0", burst and iburst in the config file to quickly step if the error is greater than 1000s. Chrony has worked better than ntp for me in libvirt managed qemu instances but may still not sync for quite awhile. If you have a raspberry pi or similar (no hwclock) use swclock instead to prime the system time with a close value - just ran into this on a pi where the default date (1st Jan 1970) was outside a networks certificate range so it couldn't get a network connection to set the time so it could access the network :) Systemd can do this too - but I have read (cant find the reference) that its time mechanism is non-standard (who would have thought!) and is very primitive compared to alternatives - good enough for non-critical applications though. BillK
