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

[Josh Marshall]

Hold on guys.  I still need to go through the new information here and
apply it.

On Mon, Oct 16, 2023, 2:07 AM Tõivo Leedjärv <toivol at gmail.com> wrote:

> 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!UxgyypTxKgBDlFZfkDT57Le9rH97d2NuA5SjdsvIXtRjYO07_HGdTvqPhkFyeushX9X7Gk5Ybn5uzkirAxM4pOXlpEnm3TXF-fcXQE_p$  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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20231016/7afac015/attachment-0001.htm>