Hi, thanks for the advice! Here is some testing:

# Output when things are ok: skagedal@clematis:~/fafafa$ qcronsub ./do_fafafa.sh Your job 1753569 ("Fafafa") has been submitted # Output when things are not ok: skagedal@clematis:~/fafafa$ qcronsub ./do_fififi.sh Unable to read script file because of error: error opening ./do_fififi.sh: No such file or directory # Piping to -dev/null: skagedal@clematis:~/fafafa$ qcronsub ./do_fafafa.sh > /dev/null # Good, nice and quiet. skagedal@clematis:~/fafafa$ echo $? 0 # And returned zero for success! skagedal@clematis:~/fafafa$ qcronsub ./do_fafafi.sh > /dev/null # Hmm, also quiet - qcronsub outputs all messages, even on error, on stdout skagedal@clematis:~/fafafa$ echo $? 14 # But returns correctly. What about qsub? skagedal@clematis:~/fafafa$ qsub ./do_fafafa.sh > /dev/null skagedal@clematis:~/fafafa$ qsub ./do_fififi.sh > /dev/null Unable to read script file because of error: error opening ./do_fififi.sh: No such file or directory skagedal@clematis:~/fafafa$ echo $? 14 # Works as expected! # How about the -o option? Let's try qcronsub. skagedal@clematis:~/fafafa$ qcronsub ./do_fafafa.sh -o myfile.txt Your job 1753616 ("Fafafa") has been submitted # Nope. qsub then? skagedal@clematis:~/fafafa$ qsub ./do_fafafa.sh -o myfile.txt Your job 1753617 ("Fafafa") has been submitted # Nope, that options seems to do something else.

So, in summary, I believe changing "qcronsub fafafa.sh" (which I currently have in my cronie) to "qsub fafafa.sh > /dev/null" will give me the behavior I want. However, without the added qcronsub uniqueness functionality, which is ok for my purposes. (as Platonides said, I'd get a mail from cronie anyway when qcronsub failed - but a less descriptive e-mail...)

Merlissimo, I would suggest changing qcronsub so that it outputs on stderr when return code is not 0. Thanks!

Regards, Simon

On Wed, Mar 7, 2012 at 10:02 PM, Sumurai8 (DD) sumurai8@gmail.com wrote:

Hi,

I think setting the -o (output) parameter to /dev/null while omitting the -e (errors) and the -j (merging errors & output) parameter should only log errors. See https://wiki.toolserver.org/view/Job_scheduling#arguments_to_qsub/qcronsub

Sumurai8

2012/3/7 Simon Kågedal Reimer skagedal@gmail.com

...

Hi!

Does anyone have a solution for making qsub/qcronsub not say "Your job ... has been submitted" to standard output?

Been getting a lot of e-mails from cronie lately...

I *do* of course want it to say something when things are not working as expected, so I don't want all output silenced.

Regards, Simon Kågedal Reimer (skagedal)

---

Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette

---

Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Is it now usual behaviour that qcronsub adds all command-line options to following calls too?

qcronsub [some options] script.py [other options]

used to call

script.py [other options]

but now it calls

script.py [some options] script.py [other options]

is this a bug or a feature? ;))

Thanks anyway and Greetings DrTrigon

On 12.03.2012 00:00, Merlissimo wrote:

Hi, i have changed qcronsub, so that the long output about successful submit and output about rejection because job already queued is now suppressed. All other output (e.g. warning) is still shown. Using "-verbose" enables all output as it was before my change. If you are using "-terse" (maybe used by some script experts) the job number is still returned.

On 08.03.2012 23:13, Platonides wrote:

...

BTW, why is qcronsub at /sge62/bin/sol-amd64/qcronsub ? Wouldn't /opt/local/bin/qcronsub (like cronsub) be more appropiate?

I do not have access to other folders and using this path is easier for me to update scripts for different platforms.

On 08.03.2012 09:32, Simon Kågedal Reimer wrote:

...

Ah, sorry, that didn't work - can't run qsub directly from cronie since we need to set some environment variables etc.

You can add needed environment variables by adding -v option to qsub/qcronsub e.g.: qcronsub -v MYARG1="myvalue",MYARG2="myvalue" script.sh There are also other possibilities like adding variables to job context (-ac). More information detailed information are available on the qsub manpage (man qsub).

Merlissimo

_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I did not open an JIRA bug because it vanished again... so; SOLVED.

But if someone is interessted in details:

http://toolserver.org/~drtrigon/DrTrigonBot/mainbot.log.2012-03-11 http://toolserver.org/~drtrigon/DrTrigonBot/mainbot.log.2012-03-12 http://toolserver.org/~drtrigon/DrTrigonBot/mainbot.log.2012-03-13

look at the 2nd line in the log, at 11th everything was ok at 12th the strange behaviour appeared and at 13th everything went back to normal. (as you can see some lines below, the script code did not change its version...)

Greetings DrTrigon

On 12.03.2012 17:47, DaB. wrote:

Hello, At Monday 12 March 2012 17:46:22 DaB. wrote:

...

Is it now usual behaviour that qcronsub adds all command-line options to following calls too?

no, it is not. But I can not reproduce that here, can you please tell us more details? (in a jira-bug if possible).

Sincerly, DaB.

_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette