yeah, i tried that already.
specifcially, mine was:
/*
String cmd[] = new String[5];
cmd[0] = "/usr/local/bin/rsync";
cmd[1] = "--daemon";
cmd[2] = "--config=/Users/dlippolt/.azerup/rsyncd.conf";
cmd[3] = "--address=127.0.0.1";
cmd[4] = "--port=2873";
*/
as an aside, i dont have my head fully wrapped around the real
differences between the various Process constructors, unless for some
reason the space character isn't an appropriate. tokenizer/separator.
other than that, Process(String) and Process(String[]) seem redundant.
thanks for the feedback.
<drew>
Damon Clinkscales wrote:
>just wondering if you had tried it like this...
>
>try {
> // Execute a command with an argument that contains a space
> String[] commands = new String[] {
> "/Users/dlippolt/.azerup/rsync",
> "--daemon",
> "--config=/Users/dlippolt/.azerup/rsyncd.conf",
> "--port=2874"
> };
> Process child = Runtime.getRuntime().exec(commands);
> } catch (IOException e) {
> System.err.println (e);
> }
>
>-damon
>
>--- Drew Lippolt <lists-rsync@azera.net> wrote:
>
>
>
>>rsync and ajug lists,
>>
>>been pulling my hair out on this one.
>>
>>i have some java code which uses the Process object to spawn an rsync
>>
>>connection in --daemon mode.
>>
>>the exact same command executes properly when run from outside java
>>(i.e
>>.on the command line) on osx. it also executes correctly from within
>>
>>java on linux using a similar jdk (sun 1.4.1 vs sun 1.4.2 for osx)
>>
>>here is example code:
>>
>>/*****************************/
>>
>>import java.net.*;
>>import java.io.*;
>>
>>public class TestClass {
>>
>> public static void main(String[] args) {
>>
>> String cmd = "/Users/dlippolt/.azerup/rsync --daemon
>>--config=/Users/dlippolt/.azerup/rsyncd.conf --port=2874";
>>
>> System.out.println(cmd);
>>
>> try {
>> Process proc = Runtime.getRuntime().exec(cmd);
>> System.out.println("DEBUG: Rsync Processvalue: " +
>>proc.waitFor());
>>
>> } catch (Throwable t) {
>>
>> t.printStackTrace();
>>
>> }
>>
>>
>> }
>>
>>}
>>
>>/*****************************/
>>
>>java note: it didn't make any difference if i connected to the std
>>in/out/err using BufferedReaders so i left that code out for brevity.
>>
>>java note: when the BufferedReaders were connected to stdout/err,
>>nothing was sent to either from rsync, just as when run in --daemon
>>mode
>>from the command line.
>>
>>here is the output of above code on the command line:
>>
>>
>>$ java TestClass
>>/Users/dlippolt/.azerup/rsync --daemon
>>--config=/Users/dlippolt/.azerup/rsyncd.conf --port=2874
>>DEBUG: Rsync Processvalue: 12
>>
>>
>>
>>on osx, i was getting (code 12) errors on startup, which was odd,
>>since
>>thats an io protocol error (associated with things like trying to
>>rsync
>>a file bigger than the filesystem will allow). the rsync process
>>wouldn't actually ever come online, though it would write 2 lines of
>>errors into the rsyncd.log file referenced in
>>/Users/dlippolt/.azerup/rsyncd.conf... thereby proving that rsync was
>>
>>initializing to the point that it was finding/reading/parsing the
>>command line argument --config correctly.
>>
>>here are the errors i was getting on rsync 2.6.3:
>>
>>2004/11/18 21:46:03 [12110] rsync: writefd_unbuffered failed to write
>>12
>>bytes: phase "unknown" [receiver]: Bad file descriptor (9)
>>2004/11/18 21:46:03 [12110] rsync error: error in rsync protocol data
>>
>>stream (code 12) at io.c(909)
>>
>>here are the errors i was getting on rsync 2.5.7:
>>
>>2004/11/18 23:17:29 [20392] rsync: writefd_unbuffered failed to write
>>12
>>bytes: phase "unknown": Bad file descriptor
>>2004/11/18 23:17:29 [20392] rsync error: error in rsync protocol data
>>
>>stream (code 12) at io.c(515)
>>
>>based on this i think i can rule out an rsync version difference.
>>
>>i couldn't figure out why i was getting a protocol error until i
came
>>to
>>this part of the rsync manpage:
>>
>>If standard input is a socket then rsync will assume that it is
>> being run via inetd, otherwise it will detach from
>>the
>>current
>> terminal and become a background daemon. The daemon
>>will read
>> the config file (rsyncd.conf) on each connect made by
>>a
>>client
>> and respond to requests accordingly. See the
>>rsyncd.conf(5) man
>> page for more details.
>>
>>so i theorize (after much hair pulling) that when run from java,
>>stdin
>>is being read as a socket from rsync's perspective, and assumes its
>>running in inet mode. now the errors make more sense since it
>>assumes
>>that an rsync client is connecting to it right now instead of merely
>>running in daemon mode.
>>
>>so the questions:
>>
>>does the rsync list have any thoughts on how to run rsync in daemon
>>mode
>>out of java without resorting to things like jni.
>>
>>can i force daemon mode, even if the rsync process thinks it should
>>be
>>running out of inet?
>>
>>problem notes:
>>
>>** setting/removing the following options had no effect:
>>
>>--no-detach
>>--tempdir
>>--blocking-io
>>--no-blocking-io
>>-v
>>
>>** i'm not including my rsyncd.conf since i know its correct (it
runs
>>
>>fine on linux, and from command line on both linux/osx.... and the
>>logfile is being identified)
>>
>>** putting the rsync command into a separate shell script and calling
>>
>>the shell script from java had no effect.
>>
>>** some random thoughts from others i've spoken to about this:
>>
>>-- in an attempt to explain why it works under linux but not osx,
>>possibly since in linux stdin is a pipe by default
>>
>>-- the osx jvm is rather new, possibly buggy
>>
>>
>>
>>
>>
>>
>>
>>
>>
