That is essentially what I do, but my wrapper is somewhat
more sophisticated, opening pipes to ssh processes instead
of files. I have no problem managing several thousand jobs
per hour for months on end. The canonical ssh invocation
for this sort of thing is:
ssh -x -n -obatchmode=yes -oconnectimeout=2 $usr@$host $cmd 2>@stdout
I used Tcl for the wrapper because I could leverage it's
event loop for asynchronous error handling by parsing
the return values from the command incrementally.
Note that top-posting makes things harder to read, but
since you started it (John) I can blame you ;^)
John Robinson wrote:
> On about a microsecond's thought, but how about if you create a shell
> script wrapper that takes the target app name and its args as its
> arguments, and then does an exec of it after directing stdout and stderr
> to files.
>
> This simple shellscript gets at the idea:
>
> exec $* 2>$1.stderr >$1.stdout
> ---
> YoungHui Amend wrote:
> >
> > There's alot of code (developed by many people) that are executed for
> > each application call. So, printing to a log file (fprinf) is not an
> > option (unfortunately). Is there something I can do with lamboot or
> > mpirun to redirect the stdout/stderr?
|
