Fossil Forum
Post: Longish sync wrongly gave time skew warning
I performed a sync operation with my local fork of fossil between desktop and home fossil server and saw this output:
$ /usr/bin/fossil sync --once paranor
Sync with http://paranor.internal/fork/fossil
Round-trips: 6 Artifacts sent: 604 received: 2
*** time skew *** server is slow by 40.4 seconds
Sync done, wire bytes sent: 670170 received: 67099 remote: 192.168.31.254
The thing is, the times on both machines are exactly the same (i ssh'd in and double checked with the linux date command).
The operation took about 5 minutes in total and completed successfully.
Both client and server used fossil v2.27 packaged by Void Linux.
Also probably of note: the server itself is a low horse power raspberry pi 1 model b+.
Afterwards, the timestamps for the latest commit were the same on both desktop and server timelines, so i assume there's no data corruption. ie, the only problem is that a time skew was wrongly detected.
i assume there's no data corruption...
Correct. the "time skew" warning arose because some users were doing "fossil commit" on systems where the NTP daemon was not running correctly and their clocks had drifted off, and thus was putting a timestamp of check-ins that did not match reality. A "fossil sync" does not add any new content, so no new timestamps are added, so nothing can go wrong. The warning is there only so that users will more quickly realize that their system clock isn't right and that they need to do something about that before doing the next commit.
the server itself is a low horse power raspberry pi 1 model b+.
Ha! Betcha can't run GitLab on that machine!!! :-)
Correct. the "time skew" warning arose because some users were doing "fossil commit" on systems where the NTP daemon was not running correctly and their clocks had drifted off...
Thanks for the reassurance and background info.
My little rpi server also runs an ntpd for my local network which is what set my spidey-senses tingling.
Ha! Betcha can't run GitLab on that machine!!! :-)
You've gotten me curious and it seems that gitlab's minimum requirements are well outside the 500M memory of an humble rpi1.
Fossil definately punches well above its weight!
My little rpi server also runs an ntpd
If that's ye olde ntpd, it isn't suited to machines that don't stay up. Its core design depends on sllloooowwly slewing from an incorrect time toward whatever the upstream NTP server reports, and when it's sufficiently far off correct, it can decide not to move at all.
Then the kicker: a freshly booted Pi is always far off the correct time because none of them have an RTC, not even the newest Pi 5.
The current Debian 13 (Trixie) based Pi OS uses systemd-timesyncd for this. Cringe all you like about systemd, it's properly suited to this class of host.
The prior darling in this space was chrony.
If that's ye olde ntpd...
Apologies, i'd meant ntpd as the type of server and not the actual reference implementation.
I do use the prior darling :), both as client (on all machines where i have the choice) and as my local server.
I've got Void Linux on all my computers so i'm not familiar with systemd-timesyncd, but its manual page says it is client only and implements Simple Network Time Protocol which has limitations.
I appreciate your proactive concern though; it's very kind of you to take the time to raise these points.