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

--===============4802580207158449492==
Content-Type: multipart/alternative; boundary="000000000000b2d63f0607a148f7"

--000000000000b2d63f0607a148f7
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]> wrote:

> 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.
>
>
>
>

--000000000000b2d63f0607a148f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>I am entirely unfamiliar with fs monitor.=C2=A0 It n=
ever came up in my searches or unison documentation.=C2=A0 One easy thing c=
ould be to mention fsmonitor in the README.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">I do mean as a long running process.=C2=A0 Full fat una=
mbiguous this is a system service and daemon.=C2=A0 Using Mosh over ssh add=
resses some of the partial action, but so too would atomic file commits.=C2=
=A0 I still don&#39;t think addressing handling multiple users needs to be =
included yet.<br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"lt=
r" class=3D"gmail_attr">On Fri, Oct 13, 2023, 6:53 PM Greg Troxel &lt;<a hr=
ef=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Josh Marshall &lt;<a href=3D"mailto:joshua.r.marsha=
[email protected]" target=3D"_blank" rel=3D"noreferrer">joshua.r.marshall.1=
[email protected]</a>&gt; writes:<br>
<br>
&gt; Having my two computers sync as changes happen seems nice and<br>
&gt; ostensibly easy to implement.=C2=A0 Famous last words, I know.=C2=A0 B=
ut why<br>
&gt; would a Unison daemon be difficult to impractical?<br>
<br>
Are you aware of the various fsmonitor implementations?=C2=A0 Leaving uniso=
n<br>
running (and the corresponding remote) seems to be routine for many<br>
already.=C2=A0 So I&#39;m not sure which piece you think is missing, and wh=
at it<br>
might do instead.=C2=A0 See &quot;-repeat watch&quot; and src/fsmonitor*.<b=
r>
<br>
Certainly the fsmonitor world could be better documented.<br>
<br>
I wonder if you mean support for closing stdin/stdout, using syslog for<br>
logging, controlling terminal dissociation, etc.=C2=A0 This is fairly minor=
,<br>
and can be achieved with nohup(1) and redirection, plus some futzing<br>
around for logging.=C2=A0 If so, that seems like a reasonable thing to add.=
<br>
<br>
You also might mean support for long-running processes on both sides<br>
that survive disconnection.=C2=A0 That raises issues about partial processi=
ng<br>
while disconnected, vs only doing connected processing and queuing<br>
input.=C2=A0 It also raises issues about ssh and reconnection in terms of<b=
r>
future access to authentication, vs running over D-TLS or some other<br>
schemes.<br>
<br>
You didn&#39;t mention this, but unison operates under a single uid, and on=
e<br>
could want synchronization of files belonging to multiple users.=C2=A0 So f=
ar<br>
we haven&#39;t really crossed that line fully.<br>
<br>
<br>
<br>
</blockquote></div></div></div>

--000000000000b2d63f0607a148f7--

--===============4802580207158449492==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Unison-hackers mailing list
[email protected]
https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers

--===============4802580207158449492==--