On Wed, May 1, 2013 at 12:09 PM, Mike Dyall-Smith <mike.dyallsm...@gmail.com> wrote: > Hi Peter, > > OK, I've worked out why the terminal did not start up galaxy. I have done > that, performed a blastp search, and it failed with the usual error, but now > I have the terminal output for that failure. > Firstly the error report from galaxy: > > ---------------------------------------------------------------------- > An error occurred running this job: blastp: 2.2.26+ > Package: blast 2.2.26, build Aug 15 2012 17:48:54 > BLAST Database error: No alias or index file found for protein database > [/media/sf_mikeds_bioinf/haldb/HAL_collection] in search path > [/var/lib/galaxy-server/database/job_working_directory/ > ---------------------------------------------------------------------- > > > Now, the log output in the terminal window for that galaxy session: (DEBUG > flags are at the end) > ---------------------------------------------------------------------------- > ... > galaxy.jobs.handler INFO 2013-05-01 20:50:46,580 (24) Job dispatched > galaxy.jobs.runners.local DEBUG 2013-05-01 20:50:46,772 executing: blastp > -version &> /usr/lib/galaxy-server/database/tmp/GALAXY_VERSION_STRING_24; > python /usr/lib/galaxy-server/tools/ncbi_blast_plus/hide_stderr.py blastp > -query "/usr/lib/galaxy-server/database/files/000/dataset_23.dat" -db > "/media/sf_mikeds_bioinf/haldb/HAL_collection" -task blastp -evalue 0.001 > -out /usr/lib/galaxy-server/database/files/000/dataset_24.dat -outfmt 6 > -num_threads 8 > 127.0.0.1 - - [01/May/2013:20:50:49 +1100] "POST /root/history_item_updates > HTTP/1.1" 200 - "http://127.0.0.1:8080/history"; "Mozilla/5.0 (X11; Ubuntu; > Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0" > galaxy.jobs.runners.local DEBUG 2013-05-01 20:50:49,568 execution finished: > blastp -version &> > /usr/lib/galaxy-server/database/tmp/GALAXY_VERSION_STRING_24; python > /usr/lib/galaxy-server/tools/ncbi_blast_plus/hide_stderr.py blastp -query > "/usr/lib/galaxy-server/database/files/000/dataset_23.dat" -db > "/media/sf_mikeds_bioinf/haldb/HAL_collection" -task blastp -evalue 0.001 > -out /usr/lib/galaxy-server/database/files/000/dataset_24.dat -outfmt 6 > -num_threads 8 > galaxy.jobs.runners.local DEBUG 2013-05-01 20:50:49,658 executing external > set_meta script for job 24: /usr/lib/galaxy-server/set_metadata.sh > ./database/files > /usr/lib/galaxy-server/database/job_working_directory/000/24 . > /usr/lib/galaxy-server/universe_wsgi.ini > /usr/lib/galaxy-server/database/tmp/tmpckvivx > /usr/lib/galaxy-server/database/job_working_directory/000/24/galaxy.json > /usr/lib/galaxy-server/database/job_working_directory/000/24/metadata_in_HistoryDatasetAssociation_24_Z7Rv70,/usr/lib/galaxy-server/database/job_working_directory/000/24/metadata_kwds_HistoryDatasetAssociation_24_NGaXc0,/usr/lib/galaxy-server/database/job_working_directory/000/24/metadata_out_HistoryDatasetAssociation_24_0FT0mx,/usr/lib/galaxy-server/database/job_working_directory/000/24/metadata_results_HistoryDatasetAssociation_24_U1RFk9,,/usr/lib/galaxy-server/database/job_working_directory/000/24/metadata_override_HistoryDatasetAssociation_24_PI3NHu > galaxy.jobs.runners.local DEBUG 2013-05-01 20:50:50,616 execution of > external set_meta for job 24 finished > galaxy.jobs DEBUG 2013-05-01 20:50:50,635 The tool did not define exit code > or stdio handling; checking stderr for success > galaxy.jobs DEBUG 2013-05-01 20:50:50,686 setting dataset state to ERROR > galaxy.jobs DEBUG 2013-05-01 20:50:50,817 job 24 ended > ...
Great. From that we can see the command Galaxy ran, python /usr/lib/galaxy-server/tools/ncbi_blast_plus/hide_stderr.py blastp -query "/usr/lib/galaxy-server/database/files/000/dataset_23.dat" -db "/media/sf_mikeds_bioinf/haldb/HAL_collection" -task blastp -evalue 0.001 -out /usr/lib/galaxy-server/database/files/000/dataset_24.dat -outfmt 6 -num_threads 8 There are two (related) clues that this is not the latest BLAST wrapper, this warning: "The tool did not define exit code" and the fact that it is using the hide_stderr.py script to hide stderr from Galaxy. Since then Galaxy has allowed wrappers more flexibility to deal with stderr - which I tool advantage of in September 2012 with v0.0.13 of the BLAST+ wrappers. What does Galaxy say the version of the BLASTP wrapper is? I now suspect that the Galaxy you have from BioLinux is very old, and may still be using the BLAST+ wrappers as then bundled with Galaxy itself. Back in about August 2012, the BLAST+ wrappers were moved to the Tool Shed. Or, perhaps it is just using an old copy of the BLAST+ wrappers? Still, the BLAST+ wrappers from back then should work. I would suggest running this at the terminal (using a different file as the output) and seeing if this works: blastp -query "/usr/lib/galaxy-server/database/files/000/dataset_23.dat" -db "/media/sf_mikeds_bioinf/haldb/HAL_collection" -task blastp -evalue 0.001 -out test_blast.tabular -outfmt 6 -num_threads 8 If you've worked out which Linux user Galaxy is run under, try that here using: sudo -u the_galaxy_user blastp ... Also could do do this so I can check the database definition is sensible? ls -l /media/sf_mikeds_bioinf/haldb/HAL_collection* Thanks, Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
