[Unison-hackers] Fwd: Daemonizing Unison and why this is easier said than done

[Tõivo Leedjärv]

On Sun, 15 Oct 2023 at 20:19, Josh Marshall
<joshua.r.marshall.1991 at gmail.com> wrote:
>
> I'll try your configuration suggestion for making a hand-rolled
> daemon, but I may also look into watchman as well.

You don't need watchman. Unless you have problems with the built-in
watch mode, in which case you should report bugs.

All you need to do is: unison -repeat watch
(or add repeat = watch in the profile file if you use profiles)
If you want it to be more like a daemon: nohup unison -repeat watch > /dev/null
In either case, you should see what is going on by looking at the log
file .unison/unison.log (can be overridden by the "logfile"
preference).

> For atomic file actions, I was thinking of something like
> https://urldefense.com/v3/__https://linux.die.net/man/1/flock__;!!IBzWLUs!Su5HMM499zdhKAExJSOo8a8VwSPciEabzKOk1exxIqQzRT7E4VTwTJTZLA5qnBxx5-DL0AaG5PP5LAqjiQMnoc2qe-M$  to lock all files to the acting
> process.  The reason for this being that if there is an interruption
> of some sort which prevents a clean change, then it could be safely
> re-attempted and prevent use by the system where the target file is
> from using the target file.

Unison does not use flock directly because it doesn't need to, but you
should know that integrity and correctness are its highest priorities.
Unison uses a sort of two step commit transaction method that is
resilient to failures (as much as is possible without the underlying
OS providing actual transactions). This is done for each update, not
for a combination of updates (the "foo and bar" example given by
Greg). Even for the "foo and bar" example there is a workaround: see
the "atomic" preference. (I've never used "atomic" myself, so can't
comment on it.)

Have you had actual problems with non-clean sync?

> > The repeat mode can tolerate some failures, such as connection to the server dropping.
> Is this something worth poking at to improve?

You may have misunderstood me. I meant that it is resilient and fault
tolerant. If it isn't then you should report bugs.

> > I think that right now ssh:/ as a root hardcodes "ssh", and there is It is not hardcoded. See the "sshcmd" preference.
> I'll take a look.

You don't need to use mosh either. The scenario you have in mind
should work just fine with plain ol' ssh. If it doesn't, you should
report bugs.