Bug 86292

Summary: RFE: systemd-timesyncd: Do not save clock to disk on every NTP fix
Product: systemd Reporter: philipp.reinkemeier
Component: generalAssignee: systemd-bugs
Status: RESOLVED NOTABUG QA Contact: systemd-bugs
Severity: trivial    
Priority: medium CC: philipp.reinkemeier
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Patch to make saving to disk on every NTP fix optinal

Description philipp.reinkemeier 2014-11-14 20:18:10 UTC
Hi.
I have a system running with systemd-networkd and systemd-resolved. Main HDD is an external USB drive. Of course to have a long lifetime of that drive i want it to spin up as few times as possible. Recently i discovered systemd-timesyncd and wanted to use that instead of the standard ntp client server implementation.
However i discovered that systemd-timesyncd saves the current clock value to disk ("/var/lib/systemd/clock") every time it gets a new NTP fix. It seems this behavior is introduced by the following commit http://cgit.freedesktop.org/systemd/systemd/commit/?id=ece6e766cf89c8ec82ad135969dedf16cd7c1ee8.
While i see the usefulness of saving the clock to disk and restore it on the next start of the daemon, i do not understand why this has to happen on every NTP fix. Isn't it sufficient to save the clock value to disk when the daemon terminates? This has also been introduced by the commit above. Doing it that way would prevent unnecessary disk accesses during runtime of the daemon.

To sum up: This is a request to remove the call to "save_clock()" from within the "manager_adjust_clock(...)" function.
Comment 1 Zbigniew Jedrzejewski-Szmek 2014-11-16 23:44:41 UTC
This is done this way so that the time saved even if the system crashes. How often does it write to the disk for you?
Comment 2 Zbigniew Jedrzejewski-Szmek 2015-01-06 05:17:55 UTC
Closing because of lack of response.
Comment 3 philipp.reinkemeier 2015-01-26 17:13:13 UTC
Sorry for being not responsive. Regarding the issue: As expected from the source code (the monotonically increasing poll interval set in method manager_adjust_poll(...)), the interval when the clock is written to disk is finally 2048 seconds. 2048 seconds seems to be the maximum value of the poll interval.

I perfectly understand the argument about the system crash you mentioned. But would it be possible to just make this a configurable option (via timesyncd.conf file)? This could default to the behavior you habe right now, with an option for the user to disable the periodic sync to disk if he is concerned about keeping disk spin-ups at a minimum.
Comment 4 Zbigniew Jedrzejewski-Szmek 2015-01-26 18:33:27 UTC
That, or an option to simply disable syncing to disk. Not high priority though, if you write a patch and send it to systemd-devel, than the chances of something happening with this will be higher.
Comment 5 philipp.reinkemeier 2015-01-29 08:27:28 UTC
Created attachment 112931 [details] [review]
Patch to make saving to disk on every NTP fix optinal

This patch introduces a new boolean configuration flag in timesyncd.conf. If enabled everything works as before (clock is saved to disk on every NTP fix). If not enabled, then the clock is only saved when the daemon exists.
Comment 6 Zbigniew Jedrzejewski-Szmek 2015-02-01 15:00:16 UTC
As mentioned in the mailing this discussion:
symlinking /var/lib/systemd/clock to /dev/null achieves the same effect.

Sorry for wasting your time.
Comment 7 julian 2015-06-11 17:11:09 UTC
I'm running arch on a Raspberry Pi. I'd greatly prefer that the time not be set instead of being set wrong.

I tried the /dev/null trick above and it doesn't work 100%. During boot I get this:

Dec 31 16:00:10.739020 captureserver systemd-timesyncd[129]: System clock time unset or jumped backwards, restoring from recorded timestamp: Mon 2015-02-16 12:55:07 PST

I'd like the option to leave the clock alone until it contacts a NTP server. A setting in timesyncd.conf would be great.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.