Ry4an Brase wrote:
> I'm working on getting more of our jobs offloaded to other machines, and
> I'm getting job failures I'm not able to debug. When running a simple
> tool like 'cut', submitted over qsub, I'm getting STDERR output like
> WARNING:galaxy.datatypes.registry:Error loading datatype "binseq.zip",
> problem: 'module' object has no attribute 'Binseq'
> WARNING:galaxy.datatypes.registry:Error loading datatype "fastqc",
> problem: 'module' object has no attribute 'fastqc'
> WARNING:galaxy.datatypes.registry:Error loading datatype "ssaha2_index",
> problem: 'module' object has no attribute 'SSAHA2Index'
It looks like your datatypes_conf.xml is out of date. Have a look at
the differences from datatypes_conf.xml.sample.
> and nothing on STDOUT. I'm doing the "Unified Method" as described here
> https://bitbucket.org/galaxy/galaxy-central/wiki/Config/Cluster with
> paths to datafiles and executables the same on the web runner and torque
> worker systems. I can successfully qsub trivial jobs ("ls") from the
> web runner machine and see them executed remotely. The web runner's
> galaxy log doesn't show anything out of the norm:
> galaxy.jobs INFO 2011-02-23 16:23:55,400 JobWrapper prepare 4019 Cut1 Ry4an
> perl /website/galaxy.msi.umn.edu/PRODUCTION/tools/filters/cutWrapper.pl
> /galaxy/PRODUCTION/database/files/019/dataset_19366.dat "c1,c2" T
> galaxy.jobs INFO 2011-02-23 16:24:04,559 JobWrapper state 4019 Cut1 running
> 188.8.131.52 - - [23/Feb/2011:16:24:06 -0500] "POST
> /root/history_item_updates HTTP/1.1" 200 -
> "https://galaxy.msi.umn.edu/history" "Mozilla/5.0 (X11; U; Linux x86_64;
> en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.84 Safari/534.13"
> galaxy.jobs INFO 2011-02-23 16:24:07,771 JobWrapper finish 4019 Cut1 error
> galaxy.jobs INFO 2011-02-23 16:24:07,880 JobWrapper done 4019 Cut1 error
> I didn't see it in the Cluster config but I added the <galaxyroot>/lib
> to the $PYTHONPATH just in case, but no luck.
> Is it possible it's just the output on STDERR causing the job to fail,
> and if so how do I shut that up when I'm running through qsub (so
> redirect to /dev/null isn't quite right)?
Yes, anything output to STDERR will be considered a failure. There is a
ticket in Bitbucket for this (actually, you commented on it 8 months ago ;)
> Ry4an Brase 612-626-6575
> Software Developer Application Development
> University of Minnesota Supercomputing Institute http://www.msi.umn.edu
> To manage your subscriptions to this and other Galaxy lists, please use the
> interface at:
To manage your subscriptions to this and other Galaxy lists, please use the