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