lsyncd 2.0 crash

[GoogleCodeExporter]

Imagine a setup of workstation A, lsyncd server B, and lsyncd target C.

What steps will reproduce the problem?
1.  On workstation A, `rsync -avz some-dir B:/path/lsyncd/watches/`
2.  rsync creates a bunch of hidden temporary files on B, which triggers 
inotify.
3.  Crazyness ensues, ending with:
xargs: illegal option -- 0
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr] 
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
Mon Jan 17 15:43:44 2011 Error: Critical exitcode.
xargs: illegal option -- 0
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr] 
[-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]

What is the expected output? What do you see instead?
Server should handle this gracefully.

What version of the product are you using? On what operating system?
2.0.1

Original issue reported on code.google.com by jus...@techadvise.com on 17 Jan 2011 at 9:56

[GoogleCodeExporter]

Hmm, can you run it with "--debug Exec" and post the logs, so it can be seen 
how it calls xargs? Xargs is used by rsynssh when deleteting files.

Either lsyncd screws up in creating its argument list, or the xargs on one of 
your servers is too old to accept "--delimiter 0".

As workaround I'd suggest adding the temporary files to an exclude pattern or 
use rsync with --temp-dir.

Original comment by axk...@gmail.com on 17 Jan 2011 at 10:01

[GoogleCodeExporter]

The minute you said "too old", I knew you had to be right.  I have two 
destinations that are running Solaris 10 :)

Sure enough, xargs on those boxes don't accept --delimiter.  It makes even more 
sense, because I have 4 targets, 2 Solaris 10, 2 RHEL5.  I only received two 
errors in the output above.

I found a compatible xargs available on Blastwave.  Can I configure the path to 
xargs per-sync?  The xargs I need to run on those two servers now lives at 
/opt/csw/bin/gxargs.

Original comment by jus...@techadvise.com on 17 Jan 2011 at 10:28

[GoogleCodeExporter]

You can just alter "lsyncd.lua". search for "xargs" and alter the call. You can 
either use gxargs, or you can alternative alter it to use "\n" as delimiter.

Original comment by axk...@gmail.com on 17 Jan 2011 at 11:45

[GoogleCodeExporter]

Original comment by axk...@gmail.com on 18 Jan 2011 at 2:12

• Changed state: Done

[GoogleCodeExporter]

Quick question - I need two of my destinations to use the gxargs, and two to 
use xargs.  I know I can use symlinks and paths to make this work, but I have a 
more general question.

What is xargs being used for in this case?  If I switched to default.rsync 
would the need for xargs disappear?

Original comment by jus...@techadvise.com on 18 Jan 2011 at 2:27

[GoogleCodeExporter]

It used to delete a list of files.

default.rsync does not need xargs as it uses rsync to delete the files. With 
current rsync this is quite an expensive operation since the filter lists rsync 
needs is quite complicated.

you can simple change the delimiter to "\n", right before the xargs.
In lin 3185 replace "zPaths" with "sPaths" and remove the "-0" in 3187. 
For any normal everday case you are not going to have "\n" in filenames anyway.

Original comment by axk...@gmail.com on 18 Jan 2011 at 2:36

[GoogleCodeExporter]

Thanks, that's what I've done.  Any chance you could add a compile-time or 
run-time option to engage 'old xargs' mode so I don't have to maintain a 
one-off patch?

Original comment by jus...@techadvise.com on 18 Jan 2011 at 10:55

[GoogleCodeExporter]

I just added code to the SVN that will allow the user to simply configure the 
xargs call for default.rsyncssh configurations:

This is the default setting:

xargs = {delimiter = '\000', binary = "xargs", xparams = {"-0", "rm -rf"}}

To change this to linefeed as seperator provide this with the sync{} call:

xargs = {delimiter = '\n', binary = "xargs", xparams = {"rm -rf"}}

Or use the binary to change that one

xargs = {delimiter = '\000', binary = "/usr/local/bin/gxargs", xparams = {"-0", 
"rm -rf"}}

Sorry I didnt get to this for 2.0.2, it will be in the next release.

Original comment by axk...@gmail.com on 25 Jan 2011 at 11:35

[GoogleCodeExporter]

No problem at all - thanks much for the feature!

Original comment by jus...@techadvise.com on 25 Jan 2011 at 3:25