Re: Fwd: Error: Warning: the archives are locked.

"'Daniela Rivas' via unison-users" <[email protected]> writes:

> We have been using Unison for more than a year and we are very satisfied
> with the program, however we are reaching out to you because we encountered
> a small issue with the sync file in unstable network conditions.

Thank you for writing from the company address when asking for help for
the company.

> Let me explain our use case: We have more than 20 clients that sync to one
> server. The clients and the server have Unison installed. These clients can
> lose connection and get it back hours after.

I am guessing that people are places where the network is unstable and
this is really how it is.

Unison creates lock files for the usual reason of ensuring that only one
instance of unison modifies ar/fp files and the root at the same time.
Normally these are removed on exit.

> In the last past months we have seen this error repeat across the clients.
>
> Roots:
>   /www/uploads
>   ssh://user@server//www/uploads
>
>
> *Error: Lost connection with the server*
> Unison 2.53.5 (ocaml 4.14.2) log started at 2025-09-17 at 12:29:52

That is not quite up to date (2.53.7 was released in November 2024) but
I do not recall any relevant significant changes.  It would be good to
update anyway, to 2.53.7 or the tip of master.

You didn't mention OS, and I wonder if any signals are delivered to the
unison process as a result of network problems.  Particularly on the
server, does sshd get a write error and then what is sent to the shell
and to unison?  Is it SIGHUP?  How does that relate to what's documented
in "Interrupting Unison" in the manual?  It could be that the mechanisms
were written for socket mode, now deprecated, and are not working well
with ssh - but that's unwarranted speculation as an example.

If Windows, then perhaps try GNU/Linux or BSD in the same network to see
if there is differing behavior.  I have no understanding of how ssh,
signals, etc. work under Windows.

With ssh: (the standard approach), the unison program is run on the
remote host but at any time data may stop flowing.  At some point each
side gets a write error, or some kind of read timeout, and then each
should clean up and exit nicely.  I can believe that these code paths
are not exercised often and may not be right.  Or it may be something
else.

You didn't explain if you are using "-repeat watch", and GUI vs TUI.
Try to simplify to not repeating, and TUI, in working towards the
simplest repro recipe you can find.

> Roots:
>   /www/uploads
>   ssh://user@server//www/uploads
>
> *Error: Warning: the archives are locked.*
>
> If no other instance of unison is running, the locks should be removed.
> The file /unison/lkb3c54ad2dbed82fb3d2ee570190a9551 on host myclient should
> be deleted
> The file /home/
> [email protected]/.unison/lka45db4ec67afbd5f4fbc6a3bc9ba8225 on host
> myserver12 should be deleted
> Please delete lock files as appropriate and try again.
>
> Once we delete the files in the client and the server (sometimes the lock
> file is only present on the server) the program resumes to run
> successfully.

You should check, before deleting on server, that any server process has
exited.  And similarly on the client.

> Would you have any suggestions/improvements or any unison commands that we
> can run to prevent this type issue? We appreciate any feedback you could
> give us.

I would suggest that someone (who can read and write ocaml ideally, but
raelly debug network programs - but you said devops!) enable debug logs
and trace what happens in one of these failure instances.  Probably not
just unison debug but ktrace (assuming you're on BSD :-) or
ktruss/strace/struss/whatever.  for unison, and also for the ssh
processes.

Also, review the code surrounding locking and unlocking.

My other suggestion is to try to create a reproduction recipe that is
minimal.  Can you provoke this with one client, not writing to a shared
space?  Can you just start a sync that will take 10 minutes and walk a
laptop out of wifi range and provoke this every time?  If you let it sit
for hours, do all the processes exist and is all cleaned up or not?  Is
the state of spurious lockfiles the same way every time?


There may be a unison bug lurking, but there may not be.  The list is
the right place until you can make a clear argument that there is a bug,
preferably with a minimal repro recipe.

Greg

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].