Re: [Monotone-devel] automate sync remote process startup

[Stephen Leake]

Stephen Leake <address@hidden> writes:

> I thought 'automate sync' was ready, so I tested it at work. There the
> computer I use as a central server has a login message, which interferes
> with ssh: startup.
>
> So I need to fix netsync.c build_stream_to_server to route startup
> messages to the stdio output stream, rather than directly to stdout. 
>
> But I don't see where the echo is happening. Running under the Cygwin
> debugger gives intermittent results; sometimes the message shows up,
> sometimes it doesn't. When it does show, it is after the call to
> build_stream_to_server, before anything else happens.
>
> Which seems to indicate that nextxx_pipe.cc
> Netxx::PipeStream::PipeStream (cmd, args) is connecting the spawned
> process stdio directly to the main process stdio, which doesn't make
> much sense.
>
> Or perhaps the spawned process is outputing the message before it
> finishes connecting to the desired pipes? That would be very weird.
>
> I'll try debugging under Debian tomorrow.

I've figured out the problem, and I'm working on a solution.

In netxx_pipe.cc, pipe_and_fork creates a child process with stdin and
stdout directed to pipes that the parent process can read. stderr is
_not_ redirected; the child and parent share the same stderr stream.

So child process error messages to stderr appear on the parent (mtn)
process stderr stream. 

The login message is on the stderr stream.

This is all fine, except when running under Emacs. When Emacs spawns a
child process, the child process has stdout and stderr directed to the
_same_ stream (for some horrible historical reason - it would be
interesting to dig up that discussion!).

I can work around that by having Emacs spawn 'sh -c mtn' instead of
'mtn', and using shell redirection to direct mtn's stderr to a file.
Which is what DVC normally does, but the mtn automate sessions didn't
use the normal DVC utils for this.

So this is an Emacs DVC problem, not a mtn problem.

Which means that the nvm.netsync.automate branch is ready, except the
--dryrun stuff is not tested or documented; I'll work on that.

-- 
-- Stephe