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

[Pali Rohár <pali.rohar@xxxxxxxxx>]

On Monday 18 May 2020 13:45:04 FUSTE Emmanuel wrote:
> 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.

Hm... I remember that in past it was needed to blacklist broken daemons,
software and kernel modules which did not work correctly during S3 or
hibernate state. It was in some pm scripts utils...

But I thought that these days are already passed and software can deal
with fact that machine may be put into suspend or hibernate state.

So what you are suggesting is to put chronyd daemon into list of broken
software (which needs to be stopped prior suspend / resume)?

It does not make sense for me as the immediate step after putting
software or kernel module into such "blacklist" was to inform upstream
authors of that daemon or kernel module they it is broken / incompatible
with suspend state and it should be fixed.

That "blacklist" was just workaround for buggy software and not
permanent solution.

> Exactly as networkmanager, ifupdown scripts, systemd-networkd 
> reload/restart some network services when interfaces/tunnels/vpn are 
> upped/downed.

This is something totally different. all those mentioned "services" are
just independent part of system which manages network connections.

chronyd is there to manage time synchronization.

> >>> 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.

And what is the faulty system?

I think this is something general and not related to particular machine.
I guess under specific conditions it may happen on any system.

> 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.

This database is for describing hardware differences or issues.

But above problem with time synchronization is general and hardware
independent. You can simulate same issue on your machine.

Just put your computer into hibernation. Then boot from liveUSB some
Linxu distribution and change RTC time. Turn off liveUSB and boot your
hibernated system. And you should be in same situation as I described.

> 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.

-- 
Pali Rohár
pali.rohar@xxxxxxxxx

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.