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

[Greg Troxel]

Josh Marshall <joshua.r.marshall.1991 at gmail.com> writes:

> I am entirely unfamiliar with fs monitor.  It never came up in my searches
> or unison documentation.  One easy thing could be to mention fsmonitor in
> the README.

It is described in the man page, in the examples section:

   Synchronize continuously

             unison -repeat watch /path/to/dir ssh://host/path/on/server

       This command first fully synchronizes the roots and then remains
       dormant, waiting for any file changes within either root and then
       automatically synchronizes these changes. This also works in a profile
       (repeat = watch).  If the filesystem monitoring helper program is not
       available or not desired for other reasons, it is possible to make
       Unison synchronize repeatedly with a defined time interval:

             unison -repeat 60 /path/to/dir ssh://host/path/on/server

       This command synchronizes every 60 seconds. Using -repeat implies
       -batch.

       Currently, continuous synchronization is not possible when using the
       GUI.

I suppose it could be in the README, but adding everything someone might
want to know there means it asymptotically appoaches the full manual :-)
In general unison is too complicated and has too many options and as
maintainer I start out with a strong bias against making things bigger
or more complicated, as while every bit helps somebody, increased sizes
is a cost for all.  I can see adding a 2 line bullet point, but not
really much more.  README is meant to be a very high-level description
of what unison is, rather than documentation of how to use it.

It would probably be good to improve the documentation in the man page.
And to install a man page along with the monitors that exist, and xref
them somehow.   This is a known issue, awaiting a contribution:
  https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/803__;!!IBzWLUs!QTX0ssrAD-qKBjH-96SPPzybOKrmEdwOlgDVuWxYH_124ewjn0uSEhNdyy-IEIVjtIlXHCuiJtCBQkNFN_gEomWm$ 

> I do mean as a long running process.  Full fat unambiguous this is a system
> service and daemon.

I don't see it that way.  unison is a program that a user runs on a
multi-user system, without needing permission from or arrangements with
the system administrator.  Multiple users can run it on a system at
once, each synchronizing their own files.  Running user programs as
system daemons crosses into how that's configured and operated
separately for each user.  Syncthing has the same issue.

Normally, "system daemon" has an implication of a singleton system-wide
service process, operating in restricted scope as that service's uid, or
as root.

If you want to start up unison, with the watcher, and leave it running,
handling redirection, nohup and so on, after configuring it not to ask
questions, I think you can do that now.  Please let us know how it went.

(I personally run unison not in fsmonitor/auto mode, and not in batch,
because I use it for keeping copies on other disks, and don't tend to
work on those other machine, but that's just me.)

>  Using Mosh over ssh addresses some of the partial action, but so too
> would atomic file commits.

I think that right now ssh:/ as a root hardcodes "ssh", and there is
certainly not a widespread practice of using other programs.  But being
able to use other programs as wrappers makes sense.

I don't follow what "atomic file commits" means.

> I still don't think
> addressing handling multiple users needs to be included yet.

That's good, because no one has articulated what that would mean
precisely, much less volunteered to write the code...