On Mon, Feb 28, 2011 at 2:28 PM, Marcin Cieslak saper@saper.info wrote:
Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Feb 28, 2011 at 11:37 AM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTiknfjfxQdVgZcJ63Hz90V_xpmKQvu145YJ+Payv@mail.gmail.com, Magnus Manske magnusmanske@googlemail.com wrote:
OK, so I gave up on starting my perl script using cronsub, which seems to work only if I give the perl script a parameter (WTF?), and instead altered it to be run manually, generating a shell script that could then start via cronsub.
This should not be the case. Please provide the exact script and command line you used and the error message.
cronsub update_dupes /home/magnus/update_dupes.pl
qsub: Unknown option
qsub: Unknown option
qsub: Unknown option
This is because you have in your script
#$cmd = "./cron_sql.sh" unless -e $cmd ;
and this is recognized by qsub(1) as the embedded qsub option.
If you change it to:
# $cmd =
it works again.
Thanks!
Wow, what a mess. Why does cronsub/qsub try to divine hidden vodoo meaning from my scripts (which predate qsub availability) anyway? If that is desired for some cases, why is that activated by default? Is there at least a qsub option to turn it off? Will that option work with cronsub?
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...
Cheers, Magnus