Re: [chrony-users] Resume from suspend and default makestep configuration

[FUSTE Emmanuel <emmanuel.fuste@xxxxxxxxxxxxxxx>]

Le 18/05/2020 à 13:15, Pali Rohár a écrit :
> On Monday 18 May 2020 10:45:02 FUSTE Emmanuel wrote:
>> Hello Pali,
>>
>> Le 18/05/2020 à 12:37, Pali Rohár a écrit :
>>> The main problem is when system is put into suspend or hibernate state.
>>>
>>> In my opinion resuming from suspend / hibernate state should be handled
>>> in the same way as (re)starting chronyd. You do not know what may
>>> happened during sleep.
>> Yes and in case of needed workaround, it should be done at the system
>> level, not chrony.
>> A job for systemd.
> Hello! Sorry for a stupid question, but what has systemd in common with
> chronyd? Why should systemd care about chronyd time synchronization?
Nothing.
But it is to your "process manager" being systemd, sysvinit pile of 
scripts or whatever to restart or notify chrony, it has do do 
housekeeping anyway for other things when you suspend/resume.
Exactly as networkmanager, ifupdown scripts, systemd-networkd 
reload/restart some network services when interfaces/tunnels/vpn are 
upped/downed.
>>> And as I pointed there are existing problems that UEFI/BIOS firmware
>>> changes RTC clock without good reason which results in completely wrong
>>> system clock.
>>>
>> Could well be identified by blacklist at the udev/systemd level for
>> applying or not the workaround (restart chrony or launch a chronyc
>> command at resume)
> Could you describe in details what do you mean by blacklist? Which udev
> blacklist you mean and what should be put into that blacklist? I have
> not caught this part.
Faulty systems could be identified by DMI/ACPI strings and quirk applied.
See for example /lib/udev/hwdb.d/60-sensor.hwdb  for some laptop sensors.
We could add an attribute to the RTC if it matche some vendor/bios 
version/model etc... to put in the hwdb (the blacklist)
A udev rule will assign this attribute to the RTC if you are running on 
a known buggy system.
A script could do anything you want at suspend/resume time in 
/lib/systemd/system-sleep if your RTC has the offended attribute (see 
systemd-sleep man page).
Or better, a unit run at resume time could do anything too.
The hwdb abstraction is not need if it is a local hack and should be 
properly defined with the hwdb/udev/systemd developers.

If raised to the systemd developers, systemd-sleep / resume could take 
care directly and fire an appropriate target with a formally defined 
attribute in the hwdb.
What to do with this target could be configurable and default to time 
daemon restart.
I'm not a systemd/udev/hwdb expert/develloper, but I think this is a 
good track and deserve a discussion with them.

Anyway, the level to tackle the problem is not chrony and the proper 
level for managing the problem is the init/process manager. Hwdb/udev is 
"a" way to share the faulty systems information across "init" ecosystem. 
Information that is usefully not only for chrony.

Emmanuel.