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

Josh Marshall joshua.r.marshall.1991 at gmail.com
Fri Oct 13 19:19:00 EDT 2023


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.

I do mean as a long running process.  Full fat unambiguous this is a system
service and daemon.  Using Mosh over ssh addresses some of the partial
action, but so too would atomic file commits.  I still don't think
addressing handling multiple users needs to be included yet.

On Fri, Oct 13, 2023, 6:53 PM Greg Troxel <gdt at lexort.com> wrote:

> Josh Marshall <joshua.r.marshall.1991 at gmail.com> writes:
>
> > 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?
>
> Are you aware of the various fsmonitor implementations?  Leaving unison
> running (and the corresponding remote) seems to be routine for many
> already.  So I'm not sure which piece you think is missing, and what it
> might do instead.  See "-repeat watch" and src/fsmonitor*.
>
> Certainly the fsmonitor world could be better documented.
>
> I wonder if you mean support for closing stdin/stdout, using syslog for
> logging, controlling terminal dissociation, etc.  This is fairly minor,
> and can be achieved with nohup(1) and redirection, plus some futzing
> around for logging.  If so, that seems like a reasonable thing to add.
>
> You also might mean support for long-running processes on both sides
> that survive disconnection.  That raises issues about partial processing
> while disconnected, vs only doing connected processing and queuing
> input.  It also raises issues about ssh and reconnection in terms of
> future access to authentication, vs running over D-TLS or some other
> schemes.
>
> You didn't mention this, but unison operates under a single uid, and one
> could want synchronization of files belonging to multiple users.  So far
> we haven't really crossed that line fully.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20231013/2135d491/attachment.htm>


More information about the Unison-hackers mailing list