[RFE] systemd-timesyncd: Use UEFI variable for /usr/lib/systemd/systemd-timesyncd

[ribalda]

systemd-timesysncd does not work on read-only filesystems.

With the almost ubiquity of uefi these days in both ARM and X86, it would be a great addition that systemd-timesyncd would save the last synchronised time on a uefi variable, as well as on /usr/lib/systemd/systemd-timesyncd.

This way we would have the assurance of a monotonic clock on the system even with the absence of a RTC and Internet connection.

[poettering]

I am sorry, but I doubt that's a good idea. The memory chips that back efi vars are typically of not so great quality. They don't survive many write cycles. Hence we shouldn't write to it regularly. It's fine to write them when configuration changes, but change them otherwise (i.e. during every clean shutdown) sounds wrong.

Are you sure that the set of systems with UEFI but without RTC is particularly high? I'd guess it's the empty set...

[ribalda]

Hi Lennard

The memory chips are not that bad. We are looking at around 100K cycles (>200 years if we reboot daily). https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128mb_1_8v_65nm.pdf

The linux kernel, is writing the reboot/shutdown reason on every clean stop: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/efibc.c

And yes, there are not many systems with UEFI, not rtc, no nework and no read-write rfs, at least on the commercial systems. But there are also industrial systems that cannot afford to have a battery due to corrosion, or because they are in accessible places that you do not want to maintain (think about the top of an aerogenerator in the sea).

So, probably this is very low priority for systemd ;). But would it be mergeable, if I work on it, and the code has the expected quality?

Thanks!

[boucman]

please try to not be too tied to EFI... there are lots of systems that are note UEFI at all

Despite all of ARM's claim, there are basically no such systems in the embedded world and we are the ones that are the most likely to need the feature (no RTC, read-only rootfs).

Our bootloaders usually store their environment on a dedicated sector on the NAND which is usually reliable enough... but is not UEFI. So a generic, overridable way to do that would be more usefull for us.

[poettering]

well, if its configurable, sure, why not. but i figure it should be opt-in to set it. (but i'd always use it if it is already set)

[nolange]

Well, on x86 writing to EFI causes a metric ton of issues, those are SMI Handlers (at best the cpu has a counter for those, otherwise they are completely isolated from diagnosis after the Bios startup) which will typically block all cpu cores for up to a ms. If your embedded device is expected to run realtime, then this feature is a good way to cause random hickups.

I need to check this, but AFAIR I need to precreate the private state directory to allow systemd-timesync to work on an RO filesystem (service fails at creation of that dir, but works if it can't write to it) . That could be improved.

Otherwise you should use a custom solution like an F-Ram if you really need some bytes of nvram.

[ribalda]

I am not very concerned abut the SMI handlers, as this would only run during poweroff. So even if the system is stalled for a second, it won't matter that much.

The F-ram is definitely an option, and whatever we implement to modify timesync should support any NV memory on a configurable way, not only EFI / filesystem, as @boucman requested.