Score:1

Does chrony need driftfile to survive a reboot

es flag

I'm setting up chrony to run on a flash-based embedded system. Should I put the driftfile in a volatile filesystem (/tmp or /var/run) or one of our flash-based partitions? If I do the former then, obviously, the file will disappear on reboot, but if I do the latter then I'm potentially opening up a problem with a lot of writes to the flash filesystem causing the device to wear out more rapidly.

Score:1
ar flag

This is what the manual says about the file:

One of the main activities of the chronyd program is to work out the rate at which the system clock gains or loses time relative to real time. Whenever chronyd computes a new value of the gain or loss rate, it is desirable to record it somewhere. This allows chronyd to begin compensating the system clock at that rate whenever it is restarted, even before it has had a chance to obtain an equally good estimate of the rate during the new run. (This process can take many minutes, at least.)

You don't need a drift file. A drift file will allow Chrony to figure out how the local clock behaves, and discipline local clock even without any reference. It's a tradeoff. Having it in memory would mean that after a reboot the local clock will not be as accurate.

Ultimately it depends on how accurate you need time to be. Do you use it to know when TLS certs expire? If so, five minutes probably doesn't matter to you. Do you use it to timestamp bullet impacts to triangulate the sound? If so, accuracy is vital. How often do you expect your device to be powercycled? In short: You have to decide based on your application.

es flag
thanks, so in my situation it only makes sense to have the file if I put it in flash to survive a reboot because we won't be stopping and restarting the daemon during normal operation. This begs the question of how frequently chrony updates the driftfile so I can factor that into our flash lifetime calculations.
vidarlo avatar
ar flag
That probably depends on the device. Large temperature swings will typically lead to the drift to change, which means updating more often. One way would be to store driftfile in RAM, and copy it to flash before shutdown.
es flag
The device will be in a rack in a server room so temperature should be constant, which sounds good. We aren’t expecting to powercycle the device at all, but the process watchdog will trigger a reboot if one of the embedded applications exits. The watchdog already copies log files to flash when that happens, so it could be extended to capture the drift file too. Many thanks - I think you’ve solved my problem!
es flag
More good news. When "reboot" command is run the system does a controlled shutdown, so "chrony stop" gets run, giving me the opportunity to stash the driftfile in flash before the shutdown completes. For an out-and-out powerfail I'll have to stash the driftfile periodically from a cron job.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.