Re: Fwd: Daemonizing Unison and why this is easier said than done
Josh Marshall <[email protected]> Mon, 16 Oct 2023 10:56:47 -0400
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <CAFkJGRdF2b=GcFD-oi5LvxBOxtjeUFm0aeMcghz6ivrTJD6+2Q@mail.gmail.com> |
--===============1953988924720898158== Content-Type: multipart/alternative; boundary="000000000000183e7d0607d69ea2" --000000000000183e7d0607d69ea2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hold on guys. I still need to go through the new information here and apply it. On Mon, Oct 16, 2023, 2:07 AM T=C3=B5ivo Leedj=C3=A4rv <[email protected]> w= rote: > On Sun, 15 Oct 2023 at 20:19, Josh Marshall > <[email protected]> wrote: > > > > I'll try your configuration suggestion for making a hand-rolled > > daemon, but I may also look into watchman as well. > > You don't need watchman. Unless you have problems with the built-in > watch mode, in which case you should report bugs. > > All you need to do is: unison -repeat watch > (or add repeat =3D watch in the profile file if you use profiles) > If you want it to be more like a daemon: nohup unison -repeat watch > > /dev/null > In either case, you should see what is going on by looking at the log > file .unison/unison.log (can be overridden by the "logfile" > preference). > > > For atomic file actions, I was thinking of something like > > https://urldefense.com/v3/__https://linux.die.net/man/1/flock__;!!IBzWL= Us!UxgyypTxKgBDlFZfkDT57Le9rH97d2NuA5SjdsvIXtRjYO07_HGdTvqPhkFyeushX9X7Gk5Y= bn5uzkirAxM4pOXlpEnm3TXF-fcXQE_p$ to lock all files to the acting > > process. The reason for this being that if there is an interruption > > of some sort which prevents a clean change, then it could be safely > > re-attempted and prevent use by the system where the target file is > > from using the target file. > > Unison does not use flock directly because it doesn't need to, but you > should know that integrity and correctness are its highest priorities. > Unison uses a sort of two step commit transaction method that is > resilient to failures (as much as is possible without the underlying > OS providing actual transactions). This is done for each update, not > for a combination of updates (the "foo and bar" example given by > Greg). Even for the "foo and bar" example there is a workaround: see > the "atomic" preference. (I've never used "atomic" myself, so can't > comment on it.) > > Have you had actual problems with non-clean sync? > > > > The repeat mode can tolerate some failures, such as connection to the > server dropping. > > Is this something worth poking at to improve? > > You may have misunderstood me. I meant that it is resilient and fault > tolerant. If it isn't then you should report bugs. > > > > I think that right now ssh:/ as a root hardcodes "ssh", and there is > It is not hardcoded. See the "sshcmd" preference. > > I'll take a look. > > You don't need to use mosh either. The scenario you have in mind > should work just fine with plain ol' ssh. If it doesn't, you should > report bugs. > --000000000000183e7d0607d69ea2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hold on guys.=C2=A0 I still need to go through the new in= formation here and apply it.</div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Mon, Oct 16, 2023, 2:07 AM T=C3=B5ivo Leed= j=C3=A4rv <<a href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex">On Sun, 15 Oct 2023 at 20:19= , Josh Marshall<br> <<a href=3D"mailto:[email protected]" target=3D"_blank" r= el=3D"noreferrer">[email protected]</a>> wrote:<br> ><br> > I'll try your configuration suggestion for making a hand-rolled<br> > daemon, but I may also look into watchman as well.<br> <br> You don't need watchman. Unless you have problems with the built-in<br> watch mode, in which case you should report bugs.<br> <br> All you need to do is: unison -repeat watch<br> (or add repeat =3D watch in the profile file if you use profiles)<br> If you want it to be more like a daemon: nohup unison -repeat watch > /d= ev/null<br> In either case, you should see what is going on by looking at the log<br> file .unison/unison.log (can be overridden by the "logfile"<br> preference).<br> <br> > For atomic file actions, I was thinking of something like<br> > <a href=3D"https://urldefense.com/v3/__https://linux.die.net/man/1/flo= ck__;!!IBzWLUs!UxgyypTxKgBDlFZfkDT57Le9rH97d2NuA5SjdsvIXtRjYO07_HGdTvqPhkFy= eushX9X7Gk5Ybn5uzkirAxM4pOXlpEnm3TXF-fcXQE_p$" rel=3D"noreferrer noreferrer= " target=3D"_blank">https://linux.die.net/man/1/flock</a> to lock all files= to the acting<br> > process.=C2=A0 The reason for this being that if there is an interrupt= ion<br> > of some sort which prevents a clean change, then it could be safely<br> > re-attempted and prevent use by the system where the target file is<br> > from using the target file.<br> <br> Unison does not use flock directly because it doesn't need to, but you<= br> should know that integrity and correctness are its highest priorities.<br> Unison uses a sort of two step commit transaction method that is<br> resilient to failures (as much as is possible without the underlying<br> OS providing actual transactions). This is done for each update, not<br> for a combination of updates (the "foo and bar" example given by<= br> Greg). Even for the "foo and bar" example there is a workaround: = see<br> the "atomic" preference. (I've never used "atomic" = myself, so can't<br> comment on it.)<br> <br> Have you had actual problems with non-clean sync?<br> <br> > > The repeat mode can tolerate some failures, such as connection to= the server dropping.<br> > Is this something worth poking at to improve?<br> <br> You may have misunderstood me. I meant that it is resilient and fault<br> tolerant. If it isn't then you should report bugs.<br> <br> > > I think that right now ssh:/ as a root hardcodes "ssh",= and there is It is not hardcoded. See the "sshcmd" preference.<b= r> > I'll take a look.<br> <br> You don't need to use mosh either. The scenario you have in mind<br> should work just fine with plain ol' ssh. If it doesn't, you should= <br> report bugs.<br> </blockquote></div> --000000000000183e7d0607d69ea2-- --===============1953988924720898158== 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 --===============1953988924720898158==--