Re: Fwd: Daemonizing Unison and why this is easier said than done

On Fri, 13 Oct 2023 at 23:22, Josh Marshall
<[email protected]> wrote:
>
> Having my two computers sync as changes happen seems nice and
> ostensibly easy to implement.  Famous last words, I know.  But why
> would a Unison daemon be difficult to impractical?

As Greg already mentioned, all this is already possible today. I have
some vague and tentative plans to improve on this and submit patches
upstream but this may not happen for several years, if ever.

Below is a short summary of what is possible today.

You should use the "repeat" preference. When the value of this
preference is "watch" then it will start the fsmonitor and sync when
changes happen. Also note that it is possible to combine fsmonitor and
time-interval syncing by adding number of seconds. For example,
"watch+3600" would sync with fsmonitor and additionally do a scan
every hour. (You can also specify just seconds without "watch" but
that's probably not what you want.) The repeat mode can tolerate some
failures, such as connection to the server dropping.

You can redirect the output to /dev/null because Unison by default
logs much of the same output to a file anyway (also see the "logfile"
preference). You can see the log file under the .unison dir.

You can use nohup.

If you want to manage the "daemon" you can send signals:
- SIGUSR1 to close the logfile for log rotation (logfile will be
  re-opened and re-created, if needed, automatically)
- SIGUSR2 to gracefully shut down the daemon -- this will wait for
  any ongoing sync to finish
- SIGTERM to shut down the daemon even if in the middle of a sync
  (it will still try to be graceful, though) -- send the signal
  multiple times to make the shutdown more quickly

Simply using the repeat mode with "watch" is likely to be appropriate
and sufficient for your use case.