Re: [gentoo-dev] Signed push & clock drift rejection

[Mart Raudsepp]

Ü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