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 this:
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'
Hi Ry4an, 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/PRODUCTION/database/files/019/dataset_19823.dat galaxy.jobs INFO 2011-02-23 16:24:04,559 JobWrapper state 4019 Cut1 running Ry4an 128.101.189.29 - - [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 Ry4an galaxy.jobs INFO 2011-02-23 16:24:07,880 JobWrapper done 4019 Cut1 error Ry4an
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 ;) https://bitbucket.org/galaxy/galaxy-central/issue/325/allow-tool-authors-to-... --nate
Thanks,
-- 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: