If you are using SGE 6.2u5 compatible releases (SGE 6.2u5pX, GE 2011.11, GE2011.11p1, and GE2011.11u1), I can send you a patched qsub binary for x86 or x64 Linux. However, I'm not ready to release the source yet as the code needs cleanup...
(OT: I still haven't have time to buy the Nikon D5100 DSLR, and today is the last day on sale... but I need to update the OGS project website to include the Hadoop integration & docs - if anyone is waiting for the docs please be patient and I will upload them ASAP.) Rayson On Thu, May 31, 2012 at 1:19 PM, P. Golik <[email protected]> wrote: > Yeah, that would be great, since this would allow me to handle stdout and > stderr separately. > Thank you for the hint with "-terse", I must have missed it while reading > the man pages! > > Looking forward to the next releases. Thank you for keeping up SGE, Rayson! > > On Thu, May 31, 2012 at 6:58 PM, Rayson Ho <[email protected]> wrote: >> >> As qsub runs the JSV script as a seperate command, I believe the >> messages you get in stdout is from the JSV child process. >> >> Since we already have the "-terse" parameter for qsub, do you think >> you will use it instead of doing the | cut -d " " -f3 parsing?? >> >> So if you are planning to use -terse, then we can also use this flag >> to tell qsub that the stdout of the JSV should go to stderr when the >> -terse flag is specified by the user. I haven't read the code yet >> (real busy these days...), but it should be a small fix that we can >> put in OGS/Grid Engine. >> >> Rayson >> >> >> >> On Thu, May 31, 2012 at 12:30 PM, P. Golik <[email protected]> wrote: >> > Sorry, let me try again. Normally, I would get the job id by calling >> > something like >> > >> > $ id=$(echo echo 1 | qsub -l h_vmem=1g | cut -d " " -f3) && >> > echo "id=$id" >> > id=7222196 >> > >> > Now I add a JSV script that would print a warning or an error to the >> > terminal >> > >> > $ id=$(echo echo 1 | qsub -l h_vmem=1g -jsv >> > $SGE_ROOT/util/resources/jsv/jsv.sh | cut -d " " -f3) && echo "id=$id" >> > Unable to run job: Job is rejected. It might be submitted later.. >> > Exiting. >> > id=hard >> > >> > The word ("hard") is the third word from JSV's error message "h_vmem as >> > hard >> > resource requirement has been deleted" that was printed to stdout. >> > Anyway, if the job can be submitted, the warnings sent with >> > jsv_log_warning() pollute the output on stdout. >> > >> > What I would like to have, is the following: >> > >> > $ id=$(echo echo 1 | qsub -l h_vmem=1g -jsv >> > $SGE_ROOT/util/resources/jsv/jsv.sh | cut -d " " -f3) && echo "id=$id" >> > WARNING: something went wrong, but JSV fixed it (this is written to >> > stderr) >> > id=7222196 >> > >> > But instead I get >> > id=went >> > >> > Is there a way to send a warning to user's stderr from jsv.sh? >> > >> > I hope that was clearer. >> > >> > On Thu, May 31, 2012 at 5:50 PM, Rayson Ho <[email protected]> >> > wrote: >> >> >> >> Can you give us the instructions to reproduce the problem?? (Simple, >> >> step by step instructions would be ideal.) >> >> >> >> I got a JSV-related issue reported to me this morning, and if I can >> >> easily reproduce the problem you've encountered, then I can look at >> >> both of the JSV problems when I have time. >> >> >> >> Rayson >> >> >> >> >> >> >> >> On Thu, May 31, 2012 at 11:28 AM, P. Golik <[email protected]> wrote: >> >> > Hi! >> >> > >> >> > I'm running a global JSV shell script for controlling user defined >> >> > parameters. >> >> > >> >> > By default, JSV prints the output of jsv_log_{warning,info,...} to >> >> > stdout. >> >> > Unfortunately, we have to use some wrapper script that parses the >> >> > output >> >> > of >> >> > qsub in order to get the job id. On the other hand, stderr seems to >> >> > be >> >> > used >> >> > by JSV for communication. >> >> > Is there an alternative way to print some warning to user's terminal >> >> > without >> >> > breaking the communication with JSV and without modifying stdout? >> >> > >> >> > Thanks! >> >> > >> >> > _______________________________________________ >> >> > users mailing list >> >> > [email protected] >> >> > https://gridengine.org/mailman/listinfo/users >> >> > >> > >> > > > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
