PP-1105: qsub: standard input notice

Developers
1

Hello,

I would like to add a notice printed by qsub. This notice will be printed to stdout in case the qsub reads input from stdin.

It is rare, but it happens sometimes that our users who request an interactive job forget the -I parameter and not realizing that no job number is shown, they wait for the job to be started but qsub is waiting for the input.

In Torque, there was a message for this and I would like to add a similar one to PBS Pro. Please, review this design doc.

Thank you for your feedback,
Vasek

2

Seems reasonable, but we’ll have to ensure it doesn’t cause any regressions. Standard Travis/Appveyor testing should suffice.

Thanks,

Mike

3

I like the suggestion. Since this is changes to an interactive usage, it has low potential to break scripts.

Is printing to stdout good? If we do stdout, some scripts (probably very few, but some using expect) etc. could read that output as qsub’s output? How about printing to stderr instead?

4

Hi @subhasisb,
This looks like something that should go to the standard output to me as we are providing some information to the user.

5

Using stdout, I ran the smoketest without any error:

run: 49, succeeded: 49, failed: 0, errors: 0, skipped: 0, timedout: 0

In my opinion, the stdout seems to be more suitable, and since this is only one extra line, the scripts can easily deal with it with minimum effort.

6

Thanks for running the tests! I agree that stdout seems the more appropriate place. Any output to stderr could cause one to think the job had problems.

7

Well there could be two schools of thought here:

  1. Everything to stderr is an error message, or
  2. stderr could also contain warnings.

I was seeing this message as a warning to the user rather than “output” - to me, output from qsub would be more like the job_id itself.

And, one should not interpret stderr output without combining the exit status information along with it.

Also I checked that our smoke test suite does not have any test cases that submit a job on the qsub standard input - because PTL does not yet support that functionality (without expect). It seems to me that a tool using qsub to parse output would only expect a job-id in stdout, or exit-status non-zero and errors on stderr.

(https://stackoverflow.com/questions/1430956/should-i-output-warnings-to-stderr-or-stdout)

8

@subhasisb Thank you and sorry for raising the PR too early. I would still slightly prefer the stdout since I doubt this is a warning. The purpose is simply to inform the user, but I see your point in not breaking anything and I think stderr is also acceptable.

I am not sure how to conclude… :slight_smile:

9

@vchlum absolutely no issues with the PR raised, it is quite well timed. Actually, several tools do emit “informational” messages to stderr. I guess the point really is not about error or warning, rather what you consider as “output” of the program.

Now that all said, I do recognize that the practical number of real world scripts that might be currently parsing qsub output, especially in stdin mode is probably very close to zero. Thus, maybe, there is no real impact, and it is only theoretical. So, if you feel strongly about using stdout, I am fine with that.

Thanks, as always, for the very useful contributions. :slight_smile: