On an old Windows OS:

>fossil.exe commit --verbose --user XXXXX -m "comment"
Auotosync: http://xxxxx@ip:8080
Round-trips: 1   Artifacts sent: 0  received: 0
*** time skew *** server is slow by 23.8 seconds
Pull done, wire bytes sent: 446  received: 1885  ip: yyy.yyy.yyy.yyy
continue in splite of time skew (y/N)?

When comitting with --verbose I get this message and fossil.exe is waiting for a user input. The script which runs the commitment is supposed to run automatically once a day and there is no user to do anything in this case. The script should succeed despite of any warning.

Question 1: What kind of issue do I have here when this message shows up? Where can I find the documentation about it on fossil-scm.com site? Or can someone please explain to me?

Question 2: Does one collection of all possible warnings with hints how to react and solve each reason and case exist on fossil-scm.com site?

Question 3: Is the additions of option --no-warnings the right answer to this to avoid the question? Help text is only about file contents.

The help text lists also an option of --no-prompt but it also says ...assumes an answer of 'No' for every question., which is the wrong answer to what I want in my case; the answer should be 'Yes', continue and succeed.

If time out of sync between Server and local PC may be the reason, how much mismatch is accepted by fossil.exe? And how can I ignore this case? The relevant timestamp should be the one from the Server.

*** time skew *** server is slow by 23.8 seconds

That warning means that the server and your local machine disagree about the current time. One or both of the two machines need to update their clock.

This warning exists to help you avoid creating a new check-in which has an inaccurate timestamp. In this particular case, the error in the clock seems to be less than half a minute. It probably wouldn't be so bad if you created a new check-in where the timestamp was off by only 30 seconds. But the warning is completely general. It would be rather confusing if you made a commit that was off by a few days.

Thanks for your instant feedback.

It would not hurt my project if the time would be out of sync by up to one day because the automated commitment will not happen more often.

Is there any way to relax the time skew warning to a longer time period or to auto-answer the question with a 'Yes' to let the automated loop continue?

This warning is issued if the disagreement between the client clock and the server clock exceeds 10 seconds.

There is no way to relax the warning. You can ignore it, if you like.

The best solution, it seems to me, would be to synchronize the clocks on your machines. That will prevent all kinds of problems in the long run, with all kinds of software, not just Fossil.

I agree and we will search for and find a solution. These 10 seconds tolerance was new to me and I could not find a hint about it...

Suggestion for future versions:

A general option --silent to suppress any user interaction in automated environments. Or alternatively a maximum time waiting for user interactions with an abortion. The most disturbing was not the warning or non-commitment but that the process did not finish because of infinite waiting time.

A general option --silent to suppress any user interaction in automated environments.

I would be against that. If you don’t care about any interactive prompts, test always passing a y for yes.

Is there a way to use the local fossil.exe [version 2.17] to receive the current date/time of the server on command line?

And that with less latency than would cause the time skew issue in case the received time is used to adjust the local PC's time prior to the commit?

If not then I suggest a new command, which acts like a ping to the server where the timestamp would be the pong response.

Is there a way to use the local fossil.exe [version 2.17] to receive the current date/time of the server on command line?

I’m not familiar with such a command. Maybe take a look at things like ‘fossil update’ immediately following a commit and see if it displays the server time and matches what you expect.

If not then I suggest a new command, which acts like a ping to the server where the timestamp would be the pong response.

Then what? Just prints the time from the remote host? Should that command be ran by anyone who can clone the repo?

Maybe it’s only me but I don’t see the value in it.

ping to the server where the timestamp would be the pong response

Then what? Just prints the time from the remote host? Should that command be ran by anyone who can clone the repo?

Yes, just print the received time to stdout, so that it can be logged or used for comparison with local time to avoid the *** time skew *** in case of more than 10 seconds deviation.

The command should be low restricted. Any user who has permission to check-in, check-out or pull, push, sync should also have the permission to ping the server for its time stamp. Permissions to ping could be linked to the URLs existing and viewed with fossil.exe remote list.

fossil.exe ping would simply use the URL from fossil remote default. fossil all ping could also be some new help to see which sites are responsive and time wise synchronized.

This is all about avoidance of the *** time skew *** reaction of fossil.exe (on Windows) because when user interaction is requested in an automatic called batch then the application is dead; dead like non-responsive, will never return and wait forever until PC becomes rebooted or an authorized user does maintenance and kills the ever-waiting, pending application. What we would like is an option which causes this blockage from being released in some way - even after some minutes of waiting without any user reaction an automated abort of the application would allow the batch file to react on its return code at least and to continue in normal ways. The time from server would be good to show what the mismatch is; likely the local PC is wrong but it could also be the server's time or both a little bit and together more than 10 seconds - who knows without visibility?

In our case we would trust the time of the server (as that is synchronized via NTP) and like to auto adjust the local time to the one returned from the server; if possible. It would not be as precise as with NTP but it would be good enough for our use case.

Is there a way to use the local fossil.exe to receive the current date/time of the server on command line?

A new command, in particular one which accesses remotes, for this far-fringe case feels like unnecessary over-engineering to me. Clock skews nowadays are exceedingly rare in most environments. Whether or not an unauthenticated ping request on a remote to reveal its local time is a potential security hole, or could be used to assist in other attack vectors, is a question i'll leave for those better versed in those topics.

Locally i have a patch which adds an --ignore-clock-skew flag which simply behaves as if the user answers "yes" to the corresponding prompt. Before checking it in i'd like to hear from the other developers whether that seems appropriate or sufficient.

An additional step would optionally be to skip the interactive prompt if fossil is running non-interactively (that is, it has no terminal attached to stdin), in which case it would behave as if the user had typed "no" to the prompt (aborting the checkin).

$ f diff
Index: src/checkin.c
==================================================================
--- src/checkin.c
+++ src/checkin.c
@@ -2134,10 +2134,14 @@
 **    --close                    close the branch being committed
 **    --date-override DATETIME   DATE to use instead of 'now'
 **    --delta                    use a delta manifest in the commit process
 **    --hash                     verify file status using hashing rather
 **                               than relying on file mtimes
+**    --ignore-clock-skew        If a clock skew is detected, ignore it and
+**                               behave as if the user had entered 'yes' to
+**                               the question of whether to proceed despite
+**                               the skew.
 **    --integrate                close all merged-in branches
 **    -m|--comment COMMENT-TEXT  use COMMENT-TEXT as commit comment
 **    -M|--message-file FILE     read the commit comment from given file
 **    --mimetype MIMETYPE        mimetype of check-in comment
 **    -n|--dry-run               If given, display instead of run actions
@@ -2207,10 +2211,11 @@
   int abortCommit = 0;   /* Abort the commit due to text format conversions */
   Blob ans;              /* Answer to continuation prompts */
   char cReply;           /* First character of ans */
   int bRecheck = 0;      /* Repeat fork and closed-branch checks*/
   int bAutoBrClr = 0;    /* Value of "--branchcolor" is "auto" */
+  int bIgnoreSkew = 0;   /* --ignore-clock-skew flag */
 
   memset(&sCiInfo, 0, sizeof(sCiInfo));
   url_proxy_options();
   /* --sha1sum is an undocumented alias for --hash for backwards compatiblity */
   useHash = find_option("hash",0,0)!=0 || find_option("sha1sum",0,0)!=0;
@@ -2264,10 +2269,11 @@
   sCiInfo.zUserOvrd = find_option("user-override",0,1);
   db_must_be_within_tree();
   noSign = db_get_boolean("omitsign", 0)|noSign;
   if( db_get_boolean("clearsign", 0)==0 ){ noSign = 1; }
   useCksum = db_get_boolean("repo-cksum", 1);
+  bIgnoreSkew = find_option("ignore-clock-skew",0,0)!=0;
   outputManifest = db_get_manifest_setting();
   verify_all_options();
 
   /* Get the ID of the parent manifest artifact */
   vid = db_lget_int("checkout", 0);
@@ -2347,11 +2353,14 @@
 
   /* Require confirmation to continue with the check-in if there is
   ** clock skew
   */
   if( g.clockSkewSeen ){
-    if( !noPrompt ){
+    if( bIgnoreSkew!=0 ){
+      cReply = 'y';
+      fossil_warning("Clock skew ignored due to --ignore-clock-skew.");
+    }else if( !noPrompt ){
       prompt_user("continue in spite of time skew (y/N)? ", &ans);
       cReply = blob_str(&ans)[0];
       blob_reset(&ans);
     }else{
       fossil_print("Abandoning commit due to time skew\n");

Why should Fossil be concerned with managing the computer's timekeeping? Isn't that a responsibility of the operating system?

Timekeeping on a computer is usually determined by regular use of NTP. The original poster referred to "old Windows OS" but was not more specific.

This reference describes a couple of operating system level fixes for Windows XP:

https://superuser.com/questions/288404/how-to-synchronize-to-a-ntp-server-on-windows-xp

Chris

Why should Fossil be concerned with managing the computer's timekeeping?

I think, a good timeline and history can only be had with good time keeping. By the way, many systems deny access when your clock is skewed (one example is Kerberos). Fossil obviously doesn't care about local time as you can commit to your hearts content if you're the only one making commits; only when you try to synchronize with others does it become an issue.

Though, I do think it should be possible to force a commit even if the time is skewed, but that should not be the default.

Andy

I think a better fix would be to just have the --no-prompt option assume an answer of "no". (Maybe it already does so?)

I don't have a lot of sympathy for the anonymous OP's assertion that timestamps and synchronized clocks don't matter. Timestamps do matter, a lot. And having accurate clock settings for all systems in a collaborative environment also matters, a lot. Getting early warning of mis-configured clocks via the initial "pull" of a "fossil commit" is a great feature, and one that shouldn't be made optional. In the exceedingly rare case where you might want to work around it, you can either run the command interactively and answer "Y" to the prompt, or if a script is required, use an interface like expect to write a script that can anticipate the time skew warning and reply the the prompt automatically.

The --ignore-clock-skew option seems out-of-scope to me.

The --ignore-clock-skew option seems out-of-scope to me.

FWIW i agree, but per /chat agreement it's in now: src:93de7b27c3fcf555

--no-prompt causes the prompt to default to "no", which aborts the checkin in this case. Before this commit, there was no way, short of a local fossil patch, correcting the clock, or using the --date-override flag, to check in with a clock skew (the latter being tricky when used to try to account for a skew).

thank you very much to all who contributed in this thread - and especially for this solution, which I appreciate very much

Thanks Andy, this is very helpful. How did you find out about this option --httptrace? In my version 2.17 it is not listed in the help response from the sync command or any of the other mentioned commands.

Options:

  -B|--httpauth USER:PASS    Credentials for the simple HTTP auth protocol,
                             if required by the remote website
  --ipv4                     Use only IPv4, not IPv6
  --no-http-compression      Do not compress HTTP traffic
  --once                     Do not remember URL for subsequent syncs
  --proxy PROXY              Use the specified HTTP proxy
  --private                  Sync private branches too
  -R|--repository REPO       Local repository to sync with
  --ssl-identity FILE        Local SSL credentials, if requested by remote
  --ssh-command SSH          Use SSH as the "ssh" command
  -u|--unversioned           Also sync unversioned content
  -v|--verbose               Additional (debugging) output
  --verily                   Exchange extra information with the remote
                             to ensure no content is overlooked

See also: clone, pull, push, remote

It's a global flag, so you'd see it with fossil help -o.

Thanks Warren, I was not yet aware of this ....

but when I tried now to get help on the help commend using fossil help help then I found this -o option and even more. ... I'll study that now.

Is there a reason why fossil help -o is not also mentioned?

An oversight. It's added now.

Are there other hidden help options?

Not any which were revealed by a casual search through the help source code.

Just some feedback from the wild: It is working fine

>fossil.exe commit --ignore-clock-skew --verbose --no-warnings -m "...."
*** time skew *** server is slow by 25.1 seconds
Clock skew ignored due to --ignore-clock-skew
*** time skew *** server is slow by 25.9 seconds

>fossil.exe help options
unknown command or setting: options
Did you mean one of these TOPICs:
  *  configuration
  *  ssl-ca-location
  *  open
  *  test-contains-selector
  *  auto-shun
Also consider using:
   fossil help TOPIC     ;# show help on TOPIC
   fossil help -a        ;# show all commands
   fossil help -w        ;# show all web-pages
   fossil help -s        ;# show all settings
   fossil help -o        ;# show global options
>fossil.exe version
This is fossil version 2.18 [a36cddb453] 2022-01-05 13:09:53 UTC