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

Josh Marshall <[email protected]> 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.