Re: Multiple instances of Unison with same profile

On 19/05/2024 14:31, Greg Troxel wrote:
> Michael von Glasow<[email protected]>  writes:
>
>> How does Unison behave if two instances of it are running with the same
>> profile (in particular, when one root is accessed via SSH)?
>>
>> Is such a situation safe? Or should I take measures to prevent it?
> That's a good question that I don't think is adequately documented.  I
> will observe that lock files for profiles are created, and unison will
> refuse to run if there are stale lock files.  I would guess that it
> waits for a non-stale file to be removed and continues.
>
>> Where does Unison place lock files, and what do they refer to (a root, a
>> single file or something else)?
> I see them in ~/.unison and they appear to be named for a pair of roots
> just like ar/fp.
I currently have a longish sync job running between two systems. Either
system has one lk file, however it is 9 months old and its hash does not
match any ar/fp files. That file has not prevented that sync job from
running over the past couple of months. Looks like it has nothing to do
with the sync job in progress, which would mean no .unison/lk* file has
been created for that job.
> There's also the question of simultaneous processing of a root with a
> different pair, A to C and B to C.
Also A to C and B to C/.../D – that is, anything underneath C.
> I am now thinking that the locks are about protecting ar/fp from
> multiprocessing hazards.
That’s my impression as well – the .unison/lk* file are locks on the
archives, not on the roots or parts thereof. However, I would expect the
hash to match that of the corresponding ar/fp files.
> It looks like finding a lock file is fatal, rather than waiting.

https://urldefense.com/v3/__https://unix.stackexchange.com/a/776555/91283__;!!IBzWLUs!XnmEoDi-fYPtwTsLM5Rxb_jP6TSn709iD-VV4RaPVJK-F6ctV-4oBjjNwdpL1j302FVqFhfpEpqWDtk1Y4HR1J6pSA$  suggests that the fatal
error occurs only when Unison tries to update the archives, which is
after it attempts to sync files that have changed.

Also, another answer to my question there suggested an elegant way to
tun Unison periodically while preventing multiple instances of the same
sync job: run it as a systemd service that is started by a timer. The
service is disabled so it will never run until explicitly started (e.g.
by the timer), and will be considered running until sync finishes. Since
starting an already-started service is a no-op, the timer will never
launch a second Unison instance if one is already running. An added
benefit is being able to start sync from a console at any time (by
starting the service manually) and being able to log out while sync is
still running, without interrupting anything.

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