On Mon, Feb 28, 2011 at 3:24 PM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTi=vXRKLQLs9QJ1Byj25NTAhmKQjXYXcCMGyMK3M@mail.gmail.com, Magnus Manske magnusmanske@googlemail.com wrote:
Wow, what a mess. Why does cronsub/qsub try to divine hidden vodoo meaning from my scripts (which predate qsub availability) anyway?
Because it means you can include directives in your script indicating how it should run:
#! /bin/ksh #$ -o $HOME/mytool.out #$ -l h_rt=3:0:0 #$ -t 1-10 #$ -tc 3 # rest of script...
This is easier than having a separate script just to start that one.
And more complicated than passing these parameters to qsub directly.
Is there at least a qsub option to turn it off?
Yes.
Thankfully, Marcin was actually helpful in answering this. Your attempt to distract from the actual issues at hand by "literal interpretation" has been duly noted.
In my "day job", I work with a large compute farm (lfs, ~10K cores), so I'm more than happy to work with, and migrate existing cronjobs to, this system, but it would help if it weren't a deliberate minefield...
I didn't write SGE. I considered several existing batch scheduling systems and SGE seemed to be the best/most useful. Of course that doesn't mean every user will like every feature it has.
I understand that, and I didn't say lfs was better (it has plenty of its own quirks), or that SGE was a bad choice - it seems to run well enough, all things considered. It's just that things like "SGE might interpret comments in your scripts as commands and die" or "you can't run qsub from within qsub" are types of behaviour that are unusual to say the least, and the toolserver users are left to the mercy of these issues (I'd call them bugs) without warning or documentation. (Yes, there is a wiki pages that says it can interpret special comments in your script. That's somewhat different from "it will reinterpret your Perl script and fall over").
Magnus