Opened 10 years ago

Last modified 9 years ago

#751 new defect

IZ3201: qrsh ignores -o and -e

Reported by: bovine Owned by:
Priority: normal Milestone:
Component: sge Version: 6.2u3
Severity: Keywords: execution


[Imported from gridengine issuezilla]

        Issue #:      3201             Platform:     All      Reporter: bovine (bovine)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.2u3       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    pollinger (pollinger)
      QA Contact:     pollinger
       * Summary:     qrsh ignores -o and -e
   Status whiteboard:

     Issue 3201 blocks:
   Votes for issue 3201:

   Opened: Tue Dec 1 15:23:00 -0700 2009 

When the -o or -e options are passed to qrsh, they are ignored and stdout/stderr are not redirected to the specified log files.

[bovine@head ~]$ qrsh -o mylog.txt -e myerr.txt hostname

The man page says that -o and -e are valid for qrsh, and does not indicate that they would be ignored:

       -e [[hostname]:]path,...
              Available for qsub, qsh, qrsh, qlogin and qalter only.
              By default the file name for interactive jobs is /dev/null. ...

       -o [[hostname]:]path,...
              Available for qsub, qsh, qrsh, qlogin and qalter only.

As a matter of feature parity, LSF allows "bsub -Ip -o logfile cmd" (which works) and
SGE's logical equivalent is "qrsh -pty y -o logfile cmd" (which doesn't).

   ------- Additional comments from reuti Tue Dec 1 15:55:49 -0700 2009 -------
Maybe it's a matter of documentation:

The stdout/-err can always be redirect within the shell. What is LSF doing: writing the output to the screen and a file like the `tee` command?

   ------- Additional comments from bovine Tue Dec 1 16:17:03 -0700 2009 -------
On LSF, the stdout/stderr get captured completely to the specified file and are not visible on the console at all.

As a workaround, redirecting within the shell is indeed possible, but requires additional user training.  Additionally, submitted commands
that are already complex (such as involving multiple quoting styles, parentheses, semicolons, and logical operator expressions) will need to
be made even more complicated with potentially another layer of parentheses and then the > and 2> operators.

Ideally, if the effort was made in bug 1997 to enable -o and -e for qrsh, then they would actually be made functional.

   ------- Additional comments from reuti Tue Dec 1 16:46:31 -0700 2009 -------
I fear the problem is where the stdout and -err are written: in SGE on the node. But the interactive output is send by the terminal
connection, which can be -builtin-, rsh, ssh or tight ssh. Hence it would be necessary to capture it before it is encrypted. Maybe it can be
added to the -builtin- method.

   ------- Additional comments from bovine Tue Dec 1 17:16:18 -0700 2009 -------
Right, it needs to be captured by execd on the execution node, similar to how qsub redirection is probably done.

   ------- Additional comments from pollinger Wed Dec 2 11:52:06 -0700 2009 -------
Capturing on the execution node won't work for ssh, telnet, rlogin and rsh. For these capturing is possible only on the client side.
With the builtin mechanism, capturing on the execution node is possible. To avoid inconsistencies between the external and the builtin
mechanism, would it be a solution to capture the output always on the client side?

If I look only at the builtin mechanism and assume the output gets captured on the execution node, I would expect the "-o" switch to work
like a "tee". It's an interactive job, so I need the output in my terminal window, but I also want to have everything logged to a file. The
user could add ">& /dev/null" to the command line, or qrsh/qlogin could provide a "-quiet" flag to suppresses all output.

   ------- Additional comments from bovine Wed Dec 2 12:20:30 -0700 2009 -------
Capturing on client-side would probably be acceptable for most people, though you should take care to ensure that environment variable
substitutions (JOB_ID, etc) occur properly.

Just because it's an interactive job that doesn't mean you need to look at the output.  Running as an interactive job allows Ctrl-C (SIGINT)
to be captured by program running on the execution node.  Also you may not want to be looking at BOTH stdout and stderr.

Implementing the -o/-e as a tee would not be useful to me, and is not what I and other LSF users would expect.  In terms of feature parity,
LSF has already established the de facto standard that -o/-e on interactive jobs should fully redirect and not "tee".

If people actually want tee functionality, then they can explicitly use tee as a part of the command line, rather than -o/-e.

   ------- Additional comments from reuti Wed Dec 2 14:34:49 -0700 2009 -------
I'm not sure, whether capturing on the client side is a good way. When you submit:

qrsh -o /tmp

which /tmp - on the exechost or the submit host? Also the $HOME aliasing for -o/-e can get a different paths, not to mentions SGE's option
to include a hostname therein: -o node01:/tmp1,node02:/tmp2


Where is this written to by LSF?
Does LSF uses different startup methods or only an equivalent to SGE's -builtin-?


Nevertheless, maybe you can use this to get two tee's for now:

Change History (0)

Note: See TracTickets for help on using tickets.