Ü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
