Re: Multiple instances of Unison with same profile

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)? This might
> be the case if Unison runs as a cron job and this one particular time
> there happens to be a lot of data that needs to be synced, so the next
> cron job starts before the previous one finishes.
>
> From what I have noticed, I’ll end up with two Unison processes running
> on my system. However, I have not examined in detail what the second
> instance does.
>
> 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.

> If one Unison instance is already running, would another instance
> running against the same pair of roots wait for the first instance to
> finish? Or would it start syncing files on its own, provided they are
> not locked and have not changed (e.g. by the other instance) during sync?

It really seems like it should wait.

There's also the question of simultaneous processing of a root with a
different pair, A to C and B to C.

Of course user changes can happen regardless of unison archive locking.

I am now thinking that the locks are about protecting ar/fp from
multiprocessing hazards.

If NFS is used because the .unison and the roots are dissociated, that
would still allow ar/fp locking.

> Right now I am preventing multiple instances by running `flock -n
> /var/lock/unison unison`, but I am wondering whether this is necessary
> at all and whether there is a more elegant solution.

I'd say that unison ought to do the right thing and if not it's a bug.

See src/update.ml, section "Archive locking", and pref 'ignorelocks'.

It looks like finding a lock file is fatal, rather than waiting.


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