- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Dear all,
I am using Raspbian Bookworm on a Raspberry Pi 4 / 8GB for running an instance of OpenHAB (https://www.openhab.org/) in a smart home context with 100+ devices. When actually living in such a cool environment, reliability is one of the key issues, and much discussion was going on in the OpenHAB forums about SD card wear over time.
Besides doing regular backups, applying the usual techniques like tmpfs or ZRAM and using high endurance cards, I did some deeper investigations about which services do regular writes onto the card and discussed these on the forum (https://community.openhab.org/t/sd-card ... far/165494). Especially inotifywait and iotop provided deep insights there.
One remarkable result I found was that - after optimizing all user-space write cylcles - the majority of physical write processes to the SD card were caused by systemd-timesyncd.service. These writes happen about once per minute, which is absolutely correct and expectable when looking at these docs: https://wiki.archlinux.org/title/Systemd-timesyncd.
The current time is stored into the modification timestamp of every minute and on shutdown to have at least an estimate of the most recent time in a system without RTC after a reboot - while a graceful reboot does not need these minutely writes as it's written on shutdown. The minutely writes are really only about a hard reset.
In the documentation link above, it is stated:
Now, what really surprised me and other people at OpenHAB:
- This is enabled in Raspbian Bookworm and Trixie by default. Though being dedicated for SD card hardware.
- Not only systemd-timesyncd is doing such timestamp-saving, the functionally redundant fake-hwclock service is active in parallel!
fake-hwclock (see https://manpages.debian.org/jessie/fake ... .8.en.html) is not doing any NTP sync, of course. But its regular saving period is one hour instead of one minute, which is much more reasonable and stretches the time to SD card wearout into tens of years.
Did anyone already stumble upon this topic - too frequent and redundant timestamp saving on Raspbian? I did not find much about it, only some smaller discussions that one should not worry about this, as it's catered for by wear leveling and it's being cached by the OS anyway.
Which is not true, because:
- iotop shows that it actually is physically writing to the card once per minute.
- the time estimation (1 to 6 years) already includes typical SD card sizes, block sizes and wear leveling
- a hard reboot would also prevent the cache to be written, making a once-per-minute scheme useless for that case
- two redundant services are enabled by default, which is unnecessary
Therefore, I would like to ask you how you see that topic. Thanks in advance!
I am using Raspbian Bookworm on a Raspberry Pi 4 / 8GB for running an instance of OpenHAB (https://www.openhab.org/) in a smart home context with 100+ devices. When actually living in such a cool environment, reliability is one of the key issues, and much discussion was going on in the OpenHAB forums about SD card wear over time.
Besides doing regular backups, applying the usual techniques like tmpfs or ZRAM and using high endurance cards, I did some deeper investigations about which services do regular writes onto the card and discussed these on the forum (https://community.openhab.org/t/sd-card ... far/165494). Especially inotifywait and iotop provided deep insights there.
One remarkable result I found was that - after optimizing all user-space write cylcles - the majority of physical write processes to the SD card were caused by systemd-timesyncd.service. These writes happen about once per minute, which is absolutely correct and expectable when looking at these docs: https://wiki.archlinux.org/title/Systemd-timesyncd.
The current time is stored into the modification timestamp of
Code: Select all
/var/lib/systemd/timesync/clockIn the documentation link above, it is stated:
Roughly estimating the number of writes this causes lead to timescales between 1 (cheap card) and 6 (good card) years until a SD card may start to wear out. Just for having a timestamp for the rare case a hard reset happens.This writing may be problematic for running off read-only root partition or trying to minimize writes to an SD card.
Now, what really surprised me and other people at OpenHAB:
- This is enabled in Raspbian Bookworm and Trixie by default. Though being dedicated for SD card hardware.
- Not only systemd-timesyncd is doing such timestamp-saving, the functionally redundant fake-hwclock service is active in parallel!
fake-hwclock (see https://manpages.debian.org/jessie/fake ... .8.en.html) is not doing any NTP sync, of course. But its regular saving period is one hour instead of one minute, which is much more reasonable and stretches the time to SD card wearout into tens of years.
Did anyone already stumble upon this topic - too frequent and redundant timestamp saving on Raspbian? I did not find much about it, only some smaller discussions that one should not worry about this, as it's catered for by wear leveling and it's being cached by the OS anyway.
Which is not true, because:
- iotop shows that it actually is physically writing to the card once per minute.
- the time estimation (1 to 6 years) already includes typical SD card sizes, block sizes and wear leveling
- a hard reboot would also prevent the cache to be written, making a once-per-minute scheme useless for that case
- two redundant services are enabled by default, which is unnecessary
Therefore, I would like to ask you how you see that topic. Thanks in advance!
- jdb
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 3576
- Joined: Thu Jul 11, 2013 2:37 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
I disagree that this level of write throughput would cause premature flash wearout. If the service was writing at that rate, it would update the inode which is a write of 4KiB (and probably some coincidental writes to the journal, say 16KiB). This activity would perform ~525k writes over a year, for a rough total of 10GB written. At a pessimistic 1k P/E cycle max and a erase amplification factor of 16x, you're still looking at >10 years of lifespan for a 16GB card.
Still, relying on the time that a file was updated as close to the "real" time serves little purpose if the board's been powered off for ages. Or if you have overlayFS enabled. It'll still be wildly out of sync even if the interval was an hour.
Still, relying on the time that a file was updated as close to the "real" time serves little purpose if the board's been powered off for ages. Or if you have overlayFS enabled. It'll still be wildly out of sync even if the interval was an hour.
Rockets are loud.
https://astro-pi.org
https://astro-pi.org
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
It's true that the actual size of the inode is small, but the erase blocks of a SD card is usually in the range of hundreds of kilobytes up to even megabytes, strongly varying from type to type. This needs to be erased and rewritten even if only one byte was changed. So the internal erased and written size is way larger. Sure, this is the main target to be mitigated by wear leveling and it does definitely not happen at every small write. But it happens.
I evaluated the wear in a rather pessimistic way; kind of worst-case analysis. So in practice, it might be way more benign that I posted (but no guarantee), but I would be truly surprised if it was as optimistic as just 10GB in a year. Most "Endurance" type SD cards are optimized for video recording (dashcams, surveillance) and survive hundreds of gigabytes - but the model in the background is continuous writing in large blocks, which is typical for video streams. Not so sure about their longevity if the model assumptions are broken by frequent, periodic writes of minimal size.
Well - and even if!
- The main purpose of these timestamps is to have a reasonable system clock after a reboot.
- Not reasonable would be UTC-0, throwing the system back into the 70s ;-) but if the clock is shortly (just until NTP sync) off by one hour or so surely does not matter to most applications.
- By the way, NTP synced so fast in any reboot I remember that I never saw corrupted timestamps even in the range of seconds.
- Those use cases which really cannot bear such deviations or run offline from NTP usually attach a "real" RTC anyway.
- It's redundant with fake-hwclock. No matter which is better, there's no reason to have both services on by default.
I evaluated the wear in a rather pessimistic way; kind of worst-case analysis. So in practice, it might be way more benign that I posted (but no guarantee), but I would be truly surprised if it was as optimistic as just 10GB in a year. Most "Endurance" type SD cards are optimized for video recording (dashcams, surveillance) and survive hundreds of gigabytes - but the model in the background is continuous writing in large blocks, which is typical for video streams. Not so sure about their longevity if the model assumptions are broken by frequent, periodic writes of minimal size.
Well - and even if!
- The main purpose of these timestamps is to have a reasonable system clock after a reboot.
- Not reasonable would be UTC-0, throwing the system back into the 70s ;-) but if the clock is shortly (just until NTP sync) off by one hour or so surely does not matter to most applications.
- By the way, NTP synced so fast in any reboot I remember that I never saw corrupted timestamps even in the range of seconds.
- Those use cases which really cannot bear such deviations or run offline from NTP usually attach a "real" RTC anyway.
- It's redundant with fake-hwclock. No matter which is better, there's no reason to have both services on by default.
- jdb
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 3576
- Joined: Thu Jul 11, 2013 2:37 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
The smallest quantum of NAND flash programming is a page, not an entire erase block. Page sizes of 16/32KiB are common, 64KiB and up are rare. Blocks can be written to multiple times.
Rockets are loud.
https://astro-pi.org
https://astro-pi.org
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Okay, I see that it might be not as bad as I assumed concerning the total sum of written bytes to the actual hardware.
Still, these writes contribute to the total amount of written data / write cycles, so the cumulative load rises anyway. As I mentioned, this is a significant amount; in my system that vast majority of writes was only due to timesyncd. And: The docs of timesyncd surely do mention the minutely timestamp as problematic for flash storage for a reason.
One question that remains is if it is really worth the effort. These regular timestamps only cater for the situation of an unexpected hard reboot - a rather rare context, which additionally is prone for file system corruption, which would even render the saved timestamp useless.
So is it really sensible to do so much writing for such a rare situation with easily renders a minute-precise timestamp unimportant due to much bigger problems that may occur? Would a hourly timestamp (plus right before regular shutdown of course) not be sufficient?
The second question is about redundancy. The fake-hwclock service is active by default in parallel, and (hourly!) saves the system time, as well as on shutdown. So (apart from not syncing with NTP) the same functionality as timesyncd only with a more reasonable period.
Both services active by default, both services set the system clock to the last known time on bootup.
A classic race condition, it may therefore be possible that either the hourly or the minutely timestamp wins.
Still, these writes contribute to the total amount of written data / write cycles, so the cumulative load rises anyway. As I mentioned, this is a significant amount; in my system that vast majority of writes was only due to timesyncd. And: The docs of timesyncd surely do mention the minutely timestamp as problematic for flash storage for a reason.
One question that remains is if it is really worth the effort. These regular timestamps only cater for the situation of an unexpected hard reboot - a rather rare context, which additionally is prone for file system corruption, which would even render the saved timestamp useless.
So is it really sensible to do so much writing for such a rare situation with easily renders a minute-precise timestamp unimportant due to much bigger problems that may occur? Would a hourly timestamp (plus right before regular shutdown of course) not be sufficient?
The second question is about redundancy. The fake-hwclock service is active by default in parallel, and (hourly!) saves the system time, as well as on shutdown. So (apart from not syncing with NTP) the same functionality as timesyncd only with a more reasonable period.
Both services active by default, both services set the system clock to the last known time on bootup.
A classic race condition, it may therefore be possible that either the hourly or the minutely timestamp wins.
- dom
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 8472
- Joined: Wed Aug 17, 2011 7:41 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
If you disable fake-hwclock you will get a very inaccurate year on boot (1970).
systemd-timesyncd does not use /var/lib/systemd/timesync/clock to set the clock on boot if NTP is not available.
If you disable systemd-timesyncd, you will not get NTP accurate time when it is available.
What do you think should be changed?
systemd-timesyncd does not use /var/lib/systemd/timesync/clock to set the clock on boot if NTP is not available.
If you disable systemd-timesyncd, you will not get NTP accurate time when it is available.
What do you think should be changed?
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
This is new to me.systemd-timesyncd does not use /var/lib/systemd/timesync/clock to set the clock on boot if NTP is not available.
To my understanding, this saved timestamp is used while booting to set the "best guess" time as early as possible (and when it's still unknown if NTP is available or not), and then, when all services are up, timesyncd checks if NTP is available and tries to get the most accurate time from there.
If that is not the case, what is the reason for storing a timestamp once per minute at all?
In my system, I configured timesyncd to not store any timestamps at all (/var/lib/systemd/timesync/clock does not even exist), and just sync with NTP (which works fine). I use fake-hwclock to restore the last known time with a saving period of once per hour.
With that, I never experienced any trouble, while I admit not having done thorough tests with rebooting while NTP is unavailable.
But as far as I can see, I have the nice and simple client-only NTP functionality of timesyncd and the hourly saved restoration from fake-hwclock, and one write per hour to the SD, not per minute.
I might be mistaken of course, there might be critical edge cases I overlooked, but as far as I can see, this has the same net effect on the system without the high amount of write cycles and without a possible race condition on boot.
- dom
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 8472
- Joined: Wed Aug 17, 2011 7:41 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
My more knowledgable AI adviser says:
Can you show any evidence that systemd-timesyncd is meant to set the time to the value of a previously
saved /var/lib/systemd/timesync/clock on a reboot?
which I'm inclined to agree with, assuming there is not evidence of it being incorrect.systemd-timesyncd uses /var/lib/systemd/timesync/clock internally to:
Record when the last successful sync occurred
Estimate how old the last known time is
Help other tools like timedatectl report sync state (System clock synchronized: yes/no)
Allow other services (e.g., log rotation, journald) to see that there’s a recently confirmed timestamp
It’s not intended as a persistence mechanism for the system clock itself.
Can you show any evidence that systemd-timesyncd is meant to set the time to the value of a previously
saved /var/lib/systemd/timesync/clock on a reboot?
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Interestingly, I found evidence that we both have a point ;)
There is some good documentation here: https://www.freedesktop.org/software/sy ... rvice.html
It is stated:
- /var/lib/systemd/timesync/clock is updated not only on NTP sync, but also periodically with SaveIntervalSec=
- /var/lib/systemd/timesync/clock is used to set the the system clock before NTP is running
But yours as well:
- /var/lib/systemd/timesync/clock merely is created only if at least one NTP sync was successful, and the SaveIntervalSec= updates only start then as well
- A standalone / offline system never seeing a NTP server would lose its clock on reboot if fake-hwclock was not running
AFAIK, systemd-timesyncd by default auto adjusts the NTP connection interval to something between 30 seconds and 30 minutes, depending on the observed clock drift. Which is completely fine for quick adjustment and not picking up too much jitter. Even extending this to 1 minute to 1 hour or even longer would not hurt at all. Most applications don't need (sub)microsecond accuracy, and even within 24 hours, typical clock drifts are within a few milliseconds. Those people in need of higher accuracy (into nanosecond domain) usually know what they are doing and use techniques like connecting a real hardware RTC, "full" NTP, PTP, GNSS timepulse sync, clock drift modelling etc. and don't rely on a simplistic NTP client like timesyncd anyway.
Finally, for me, two questions remain:
- On systems connected with NTP, (aka /var/lib/systemd/timesync/clock existing) there still is a possible race condition on startup when both systemd and fake-hwclock try to set their best estimates. As many (almost all?) systems obviously run smoothly with this config, I very strongly assume that someone already thought about this already some time ago and set the service start order reasonably. So.... just asking. ;)
- If it's acceptable for offline systems to save the current time once per hour per fake-hwclock, why not increase SaveIntervalSec= to one hour as well? That would relax SD activity without losing much (and sticking to what is acceptable for offline systems anyway).
There is some good documentation here: https://www.freedesktop.org/software/sy ... rvice.html
It is stated:
About the mentioned epoch used by systemd: https://www.freedesktop.org/software/sy ... temd.html#/var/lib/systemd/timesync/clock
The modification time ("mtime") of this file is updated on each successful NTP synchronization or after each SaveIntervalSec= time interval, as specified in timesyncd.conf(5).
If present, the modification time of this file is used for the epoch by systemd(1) and systemd-timesyncd.service.
So this means that my assumption was right indeed:When systemd is started or restarted, it may set the system clock to the "epoch". This mechanism is used to ensure that the system clock remains somewhat reasonably initialized and roughly monotonic across reboots, in case no battery-backed local RTC is available or it does not work correctly.
The epoch is the lowest date above which the system clock time is assumed to be set correctly. When initializing, the local clock is advanced to the epoch if it was set to a lower value. As a special case, if the local clock is sufficiently far in the future (by default 15 years, but this can be configured at build time), the hardware clock is assumed to be broken, and the system clock is rewound to the epoch.
The epoch is set to the highest of: the build time of systemd, the modification time ("mtime") of /usr/lib/clock-epoch, and the modification time of /var/lib/systemd/timesync/clock.
- /var/lib/systemd/timesync/clock is updated not only on NTP sync, but also periodically with SaveIntervalSec=
- /var/lib/systemd/timesync/clock is used to set the the system clock before NTP is running
But yours as well:
- /var/lib/systemd/timesync/clock merely is created only if at least one NTP sync was successful, and the SaveIntervalSec= updates only start then as well
- A standalone / offline system never seeing a NTP server would lose its clock on reboot if fake-hwclock was not running
AFAIK, systemd-timesyncd by default auto adjusts the NTP connection interval to something between 30 seconds and 30 minutes, depending on the observed clock drift. Which is completely fine for quick adjustment and not picking up too much jitter. Even extending this to 1 minute to 1 hour or even longer would not hurt at all. Most applications don't need (sub)microsecond accuracy, and even within 24 hours, typical clock drifts are within a few milliseconds. Those people in need of higher accuracy (into nanosecond domain) usually know what they are doing and use techniques like connecting a real hardware RTC, "full" NTP, PTP, GNSS timepulse sync, clock drift modelling etc. and don't rely on a simplistic NTP client like timesyncd anyway.
Finally, for me, two questions remain:
- On systems connected with NTP, (aka /var/lib/systemd/timesync/clock existing) there still is a possible race condition on startup when both systemd and fake-hwclock try to set their best estimates. As many (almost all?) systems obviously run smoothly with this config, I very strongly assume that someone already thought about this already some time ago and set the service start order reasonably. So.... just asking. ;)
- If it's acceptable for offline systems to save the current time once per hour per fake-hwclock, why not increase SaveIntervalSec= to one hour as well? That would relax SD activity without losing much (and sticking to what is acceptable for offline systems anyway).
- dom
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 8472
- Joined: Wed Aug 17, 2011 7:41 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
I've done some digging. Significantly fake-hwclock is not installed by default on trixie, so one of your complaints is solved.
With the trixie code for systemd-timesyncd, it sometimes updates the time on shutdown.
Interestingly the latest master of systemd-timesyncd looks to always update the time on shutdown, which feels like a more desirable behaviour.
With the trixie code for systemd-timesyncd, it sometimes updates the time on shutdown.
Interestingly the latest master of systemd-timesyncd looks to always update the time on shutdown, which feels like a more desirable behaviour.
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Nice findings, thanks for looking this up! :)
I especially like that the functionality now is concentrated to one service instead of multiple.
So the only remaining question is if a saving rate of once per hour was already accepted as default for fake-hwclock before Trixie, this might be a more reasonable value for timesyncd instead of once per minute. Especially with the background that it's anyway saved on graceful shutdown.
Just staying at the (admittedly pessimistic) example of wear times of 1 to 6 years - a multiplication factor fo 60 would boost these durations from the "possibly annoying" range straight into the "surely irrelevant" space.
I especially like that the functionality now is concentrated to one service instead of multiple.
So the only remaining question is if a saving rate of once per hour was already accepted as default for fake-hwclock before Trixie, this might be a more reasonable value for timesyncd instead of once per minute. Especially with the background that it's anyway saved on graceful shutdown.
Just staying at the (admittedly pessimistic) example of wear times of 1 to 6 years - a multiplication factor fo 60 would boost these durations from the "possibly annoying" range straight into the "surely irrelevant" space.
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Is your system normally offline and/or do you you a hardware RTC?
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
While I think the concern many Pi users have about SD Card reliability is misplaced this question is based on a misconception that timedatectl writes to SD Card frequently.
The clock "file" is tiny, and totally contained within the inode and only actually written to storage infrequently.
The clock "file" is tiny, and totally contained within the inode and only actually written to storage infrequently.
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Mine is usually online and has no HW RTC.
I would be fully inclined to agree with that, because I believed it to be like this myself. Until I found proof it's different.Milliways wrote: While I think the concern many Pi users have about SD Card reliability is misplaced this question is based on a misconception that timedatectl writes to SD Card frequently.
The clock "file" is tiny, and totally contained within the inode and only actually written to storage infrequently.
I observed both on Bookwork and Trixie:
- inotifywait found var/lib/systemd/timesync/timer and / or /var/lib/systemd/timesync/clock being touched once per minute, as expected. This made the inode dirty.
- Watching the physical mmc storage for 10 minutes with iotop -o -b -n 600 | grep mmc I found this pattern repeating:
Code: Select all
/var/lib/systemd/timesync/ ATTRIB,ISDIR clock
/var/lib/systemd/timesync/clock/ ATTRIB,ISDIR
/run/systemd/timesync/ ATTRIB synchronizedIt's physically written with a short delay each time, making up the vast majority of all physical writes on an otherwise idle system.
Moreover, if I disable systemd-timesyncd, these writes actually cease and there were 10-minute periods observable with not a single write process happening.
Let me emphasize again: This minutely update is solely catering for the case of an ungraceful sudden shutdown or reset!
The timestamp is also updated on each graceful system shutdown, so a normal reboot or shutdown does not have any benefit from these periodic writes!
So let's imagine the filesystem would actually cache several of these inode updates. If a reset or power loss occured in that case, an unknown number of timestamps would be lost, rendering the high update rate useless, even ending up with a random last saved state (or even file system corruption).
Well, we know that's not the case, so it actually causes a significant write load to the SD card, which is described as "problematic for SD cards" in the timesyncd documentation I cited in my initial post.
The question is, which use case would actually significantly profit from the high rate of timestamp updates? I really made up my mind, but found no better answer than:
"An application which has no NTP connection, with frequent hard resets being expected, the user being both strongly worried about time monotony and at the same time being faithful never experiencing file system corruption from the reboots. Despite caring about timestamps in general, the unknown timespan from the hard resets until the next reboot (and therefore absolute time) does not matter, and the user is refraining from providing an UPS, hardware RTC or other external clock sources which could mitigate these issues for whatever reason."
The world is large and diverse, so I would not even deem that completely impossible. But this does not justify such writing effort to be configured as a default setting. If you have such use case, you usually know about it and can adjust the params.
This is especially true as Bookworm in in offline / no-RTC setups had timesyncd being inherently inactive (as mentioned above) and was relying on fake-hwclock with a default saving strategy "Once per hour and on shutdown". So a hourly period was already acceptable here. Why don't we use this as default for timesyncd in Trixie as well?
- dom
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 8472
- Joined: Wed Aug 17, 2011 7:41 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
My understanding is trixie timesyncd only updates the time on shutdown if it has had a previous successful NTP sync(*).hundertvolt wrote: ↑Thu Oct 30, 2025 9:58 amThis is especially true as Bookworm in in offline / no-RTC setups had timesyncd being inherently inactive (as mentioned above) and was relying on fake-hwclock with a default saving strategy "Once per hour and on shutdown". So a hourly period was already acceptable here. Why don't we use this as default for timesyncd in Trixie as well?
On master branch (and in forky) it does unconditionally update the time on any shutdown.
So, If we boot at 10am with no RTC/network, set the time manually, then reboot at 10.59am we get:
Bookworm: comes back up with clock at 10.59am due to fake-hwclock saving time on shutdown.
Trixie with per-minute timesyncd update: comes back up with clock at 10.59am due to last per-minute update.
Trixie with hourly timesyncd update: comes back up with clock at 10.00am due to no fake-hwclock, hourly update not reached, and no update at shutdown (as no successful NTP update).
Forky with hourly timesyncd update: comes back up with clock at 10.59am due to timesyncd unconditionally updating time at shutdown.
So reducing to an hourly update has made this scenario worse.
(*) this is what the code appears to do - it ideally wants confirmation testing in case other code paths change behaviour.
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
/run is a tmpfs, so that does not matter. If you are interested in minimizing writes generally, you might consider whether the lazytime mount option works for you.hundertvolt wrote: ↑Thu Oct 30, 2025 9:58 am/var/lib/systemd/timesync/clock/ ATTRIB,ISDIR
/run/systemd/timesync/ ATTRIB synchronized
systemd-timesyncd is a very primitive NTP client. It does not discipline the system clock well (viewtopic.php?p=2229534#p2229534). Apparently it only consults one server at a time, so in the worst case it could choose a broken server and set the wrong date.
I suggest you try installing chrony, ntpsec, openntpd, and check whether any of them write less frequently. You may need to test over several hours for them to stabilize. Installing any one of those packages automatically removes the others, and systemd-timesyncd.
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
timesyncd should eventually settle down to 2048 second polling (the default max)
The one minute periodic save shouldn't happen at all if you have successful ntp syncs.
(削除ここまで)
I think something like this cropped up before when someone had two time systems running and they were arguing with each other so always trying to correct.
EDIT: Is there any chance that OpenHab is forcing time updates one way or another?
Last edited by pidd on Thu Oct 30, 2025 6:54 pm, edited 1 time in total.
- ShiftPlusOne
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 6546
- Joined: Fri Jul 29, 2011 5:36 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Hm? Where are you seeing that? 90% sure it happens either way and only the sync on shutdown/reboot is affected by whether you've had an NTP sync (in our current version of systemd).
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
ShiftPlusOne wrote: ↑Thu Oct 30, 2025 5:14 pmHm? Where are you seeing that? 90% sure it happens either way and only the sync on shutdown/reboot is affected by whether you've had an NTP sync (in our current version of systemd).
My interpretation of the only setting related to it.
SaveIntervalSec=
The interval at which the current time is periodically saved to disk, in the absence of any recent synchronisation from an NTP server. This is especially useful for offline systems with no local RTC, as it will guarantee that the system clock remains roughly monotonic across reboots.
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
I'll stand corrected, apparently it does happen and was brought into being in 2021, prior to that it saved every time a ntp sync happened and the periodic save was introduced to happen regardless of ntp sync. That makes the description of the setting I quoted above extremely misleading.pidd wrote: ↑Thu Oct 30, 2025 5:38 pmShiftPlusOne wrote: ↑Thu Oct 30, 2025 5:14 pmHm? Where are you seeing that? 90% sure it happens either way and only the sync on shutdown/reboot is affected by whether you've had an NTP sync (in our current version of systemd).
My interpretation of the only setting related to it.
SaveIntervalSec=
The interval at which the current time is periodically saved to disk, in the absence of any recent synchronisation from an NTP server. This is especially useful for offline systems with no local RTC, as it will guarantee that the system clock remains roughly monotonic across reboots.
- ShiftPlusOne
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 6546
- Joined: Fri Jul 29, 2011 5:36 pm
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Ah, I was about to eat my hat after seeing your previous comment, because I was sure I've seen it behave differently.pidd wrote: ↑Thu Oct 30, 2025 6:10 pmI'll stand corrected, apparently it does happen and was brought into being in 2021, prior to that it saved every time a ntp sync happened and the periodic save was introduced to happen regardless of ntp sync. That makes the description of the setting I quoted above extremely misleading.
When investigating the overall behaviour, I found all statements about it misleading. Commit messages, code comments and documentation all say different things and the actual behaviour varies across versions.
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Just to clarify how I understood how it works from documentation as well as from observation.
timesyncd follows three strategies for saving the current time:
1. On every fresh NTP sync if NTP is reachable.
2. On every graceful shutdown, which should be sufficient to ensure monotonic time across reboots.
3. Periodically in case of unexpected / ungraceful resets or power loss.
1 and 2 are working fine and behave as expected on my system.
3, the periodic syncs, were done only if NTP was at least successful once in earlier versions (e.g. Bookworm) which was the reason why fake-hwclock was active in parallel to cater for offline application (but had a default trigger period of 1 hour).
The current version of timesyncd now took over this functionality and always syncs periodically, independent of NTP availability. Which is a good improvement, IMHO.
What I am asking for is if the periodic sync can be set to one hour (as it was in fake-hwclock), as this seems much more reasonable than one minute for the reasons I described before.
timesyncd follows three strategies for saving the current time:
1. On every fresh NTP sync if NTP is reachable.
2. On every graceful shutdown, which should be sufficient to ensure monotonic time across reboots.
3. Periodically in case of unexpected / ungraceful resets or power loss.
1 and 2 are working fine and behave as expected on my system.
3, the periodic syncs, were done only if NTP was at least successful once in earlier versions (e.g. Bookworm) which was the reason why fake-hwclock was active in parallel to cater for offline application (but had a default trigger period of 1 hour).
The current version of timesyncd now took over this functionality and always syncs periodically, independent of NTP availability. Which is a good improvement, IMHO.
What I am asking for is if the periodic sync can be set to one hour (as it was in fake-hwclock), as this seems much more reasonable than one minute for the reasons I described before.
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
hundertvolt wrote: ↑Thu Oct 30, 2025 7:34 pmWhat I am asking for is if the periodic sync can be set to one hour (as it was in fake-hwclock), as this seems much more reasonable than one minute for the reasons I described before.
Can't see why not, the setting is there to be used.
In my little tests before, it is saved in the last second at the end of the period so it was always up to one period behind apart from the last second of a period.
https://manpages.debian.org/trixie/syst ... .5.en.html
- hundertvolt
- Posts: 12
- Joined: Mon Oct 27, 2025 8:24 am
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
Sure I can set the param for myself :D (of course I already did)....Can't see why not, the setting is there to be used.
But wouldn't it be way sensible to set it to one hour of saving period by default, as this is IMHO the best for most use cases, while anyone who really needs it to be one minute can adjust it accordingly?
Re: Timesync service causing excessive SD card writes / fahe-hwclock redundancy
If the purpose is to avoid overlapping times on future boots (I have not checked), then one minute is a sensible option, and one hour is not.
Booting takes a significant fraction of a minute, but within an hour you might have started something like "make", that relies on relative timestamps.
(fake-hwclock never avoided overlapping timestamps adequately. It basically dealt with the 1970 problem only.)
Jump to
- Community
- General discussion
- Announcements
- Other languages
- Deutsch
- Español
- Français
- Italiano
- Nederlands
- 日本語
- Polski
- Português
- Русский
- Türkçe
- User groups and events
- Raspberry Pi Official Magazine
- Using the Raspberry Pi
- Beginners
- Troubleshooting
- Advanced users
- Assistive technology and accessibility
- Education
- Picademy
- Teaching and learning resources
- Staffroom, classroom and projects
- Astro Pi
- Mathematica
- High Altitude Balloon
- Weather station
- Programming
- C/C++
- Java
- Python
- Scratch
- Other programming languages
- Windows 10 for IoT
- Wolfram Language
- Bare metal, Assembly language
- Graphics programming
- OpenGLES
- OpenVG
- OpenMAX
- General programming discussion
- Projects
- Networking and servers
- Automation, sensing and robotics
- Graphics, sound and multimedia
- Other projects
- Media centres
- Gaming
- AIY Projects
- Hardware and peripherals
- Camera board
- Compute Module
- Official Display
- HATs and other add-ons
- Device Tree
- Interfacing (DSI, CSI, I2C, etc.)
- Keyboard computers (400, 500, 500+)
- Raspberry Pi Pico
- General
- SDK
- MicroPython
- Other RP2040 boards
- Zephyr
- Rust
- AI Accelerator
- AI Camera - IMX500
- Hailo
- Software
- Raspberry Pi OS
- Raspberry Pi Connect
- Raspberry Pi Desktop for PC and Mac
- Beta testing
- Other
- Android
- Debian
- FreeBSD
- Gentoo
- Linux Kernel
- NetBSD
- openSUSE
- Plan 9
- Puppy
- Arch
- Pidora / Fedora
- RISCOS
- Ubuntu
- Ye Olde Pi Shoppe
- For sale
- Wanted
- Off topic
- Off topic discussion