January 2015 - galaxy-dev - lists.galaxyproject.org

Re: [galaxy-dev] data collections - workflow - bug?
by John Chilton 30 Mar '15

30 Mar '15

Sorry again about this mixup (bringing conversation back on channel). Does this happen everytime you run a workflow with collections? Do you know how many job handlers Galaxy is configured with? -John On Mon, Jan 26, 2015 at 11:24 AM, John Chilton <jmchilton(a)gmail.com> wrote: > Ugh.... misread sqlalchemy as sqlite. I will work on this. > > -John > > On Mon, Jan 26, 2015 at 11:16 AM, Torsten Houwaart > <houwaart(a)informatik.uni-freiburg.de> wrote: >> Hi John, >> >> i ran this on the Galaxy server in Freiburg: galaxy.uni-freiburg.de >> Björn (who sits immediately opposite of my desk :) ) told me it's a Postres >> database and that shouldn't be the problem. >> >> Best, >> Torsten >> >> >> On 26.01.2015 16:48, John Chilton wrote: >>> >>> Hey, >>> >>> Really intensive database operations including datasest collections >>> but other things too like multi-running tools or workflows over many >>> individual datasets for instance - can very easily overwhelm the >>> default sqlite database. This is frustrating and shouldn't happen - >>> but it does unfortunately. I would recommend using a postgres database >>> when testing out dataset collections. The good news is that it is >>> easier than ever to get a fully fledged production-quality server >>> thanks to Bjoern's docker server >>> (https://github.com/bgruening/docker-galaxy-stable) - it comes bundled >>> with Postgres and Slurm so it should be able to handle the collection >>> operations. If you need to run Galaxy on a non-containerized server >>> (for instance because that is where the software is) more information >>> on setting up Galaxy can be found here >>> https://wiki.galaxyproject.org/Admin/Config/Performance/ProductionServer. >>> >>> Here is a Trello card to track progress on the database optimization >>> efforts if you are interested https://trello.com/c/UPLsMKQI. >>> >>> Very sorry. >>> >>> -John >>> >>> >>> >>> -John >>> >>> On Mon, Jan 26, 2015 at 9:35 AM, Torsten Houwaart >>> <houwaart(a)informatik.uni-freiburg.de> wrote: >>>> >>>> Hello Galaxy Devs, >>>> >>>> I was using data collections (for the first time) for a new workflow of >>>> ours >>>> and I ran into this problem. There was no complaint by the >>>> workflow-editor >>>> and I could start the workflow but then <see below> happened. >>>> If you need more information about the workflow or otherwise let me know. >>>> >>>> Best, >>>> Torsten H. >>>> >>>> >>>> job traceback: >>>> Traceback (most recent call last): >>>> File >>>> "/usr/local/galaxy/galaxy-dist/lib/galaxy/jobs/runners/__init__.py", >>>> line 565, in finish_job >>>> job_state.job_wrapper.finish( stdout, stderr, exit_code ) >>>> File "/usr/local/galaxy/galaxy-dist/lib/galaxy/jobs/__init__.py", line >>>> 1250, in finish >>>> self.sa_session.flush() >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/scoping.py", >>>> line 114, in do >>>> return getattr(self.registry(), name)(*args, **kwargs) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/session.py", >>>> line 1718, in flush >>>> self._flush(objects) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/session.py", >>>> line 1789, in _flush >>>> flush_context.execute() >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/unitofwork.py", >>>> line 331, in execute >>>> rec.execute(self) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/unitofwork.py", >>>> line 475, in execute >>>> uow >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/persistence.py", >>>> line 59, in save_obj >>>> mapper, table, update) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/orm/persistence.py", >>>> line 485, in _emit_update_statements >>>> execute(statement, params) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/engine/base.py", >>>> line 1449, in execute >>>> params) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/engine/base.py", >>>> line 1584, in _execute_clauseelement >>>> compiled_sql, distilled_params >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/engine/base.py", >>>> line 1698, in _execute_context >>>> context) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/engine/base.py", >>>> line 1691, in _execute_context >>>> context) >>>> File >>>> >>>> "/usr/local/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs2.egg/sqlalchemy/engine/default.py", >>>> line 331, in do_execute >>>> cursor.execute(statement, parameters) >>>> DBAPIError: (TransactionRollbackError) deadlock detected >>>> DETAIL: Process 3144 waits for ShareLock on transaction 2517124; blocked >>>> by >>>> process 3143. >>>> Process 3143 waits for ShareLock on transaction 2517123; blocked by >>>> process >>>> 3144. >>>> HINT: See server log for query details. >>>> 'UPDATE workflow_invocation SET update_time=%(update_time)s WHERE >>>> workflow_invocation.id = %(workflow_invocation_id)s' {'update_time': >>>> datetime.datetime(2015, 1, 26, 14, 20, 4, 155440), >>>> 'workflow_invocation_id': >>>> 5454} >>>> >>>> >>>> ___________________________________________________________ >>>> 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: >>>> https://lists.galaxyproject.org/ >>>> >>>> To search Galaxy mailing lists use the unified search at: >>>> http://galaxyproject.org/search/mailinglists/ >> >>

2 2

problems installing tool dependency
by Sajdak, Doris 27 Feb '15

27 Feb '15

Hi all, I am trying to install the Genome Diversity tools from the Miller Lab that are in the Galaxy toolshed. I've been able to get all dependencies installed except Quicktree. Whenever I try to install it, I get the error: Error downloading from URL ftp://ftp.sanger.ac.uk/pub4/resources/software/quicktree/quicktree.tar.gz: <urlopen error ftp error: 550 pub4: No such file or directory> This is the tool_dependencies.xml file for installing quicktree: <?xml version="1.0"?> <tool_dependency> <package name="quicktree" version="1.1"> <install version="1.0"> <actions>  <action type="download_by_url" target_filename="quicktree_1.1.tar.gz">ftp://ftp.sanger.ac.uk/pub4/resources/software/quicktree/quicktree.tar.gz</action>  <action type="shell_command">make quicktree</action>  <action type="shell_command">cp -R bin $INSTALL_DIR</action>  <action type="set_environment"> <environment_variable name="PATH" action="prepend_to">$INSTALL_DIR/bin</environment_variable> </action> </actions> </install> </package> </tool_dependency> I know this is not their file I'm downloading but the thing is, if I copy and paste the URL, I can download it with no problem. I'm not sure why it's reporting that it can't be found but the xml looks right to me. I've tried contacting the Miller Lab about this but haven't heard from anyone so I'm hoping someone here can tell me how to move past this problem. Is there a way to install this tool manually and have the main Genome Diversity tools recognize it on the Galaxy server? Also, I noticed when looking at the Tool Dependency Definitions at https://toolshed.g2.bx.psu.edu/ there are errors going back many versions for this tool (see Test runs - Installation errors - Tool dependencies). Thank you for any help you can provide. Dori ********************************** Dori Sajdak Senior Systems Administrator State University of NY at Buffalo Center for Computational Research 701 Ellicott St Buffalo, NY 14203 Phone: (716) 881-8934 Fax: (716) 849-6656 Web: http://ccr.buffalo.edu **********************************

3 7

LD_LIBRARY_PATH not exporting to galaxy
by Nikhil Joshi 18 Feb '15

18 Feb '15

Hi all, So we have forked the stable branch of galaxy and are making our own modifications. We are running galaxy on Ubuntu 14.04.1 LTS and we're using modules to load the underlying software, i.e. set environment variables. This works just fine for PATH, JAVA_JAR_PATH, PYTHONPATH, etc., however, LD_LIBRARY_PATH is not being passed to the tools. When a tool (such as cuffdiff) tries to access LD_LIBRARY_PATH, it is empty. We've checked to make sure that loading the cufflinks module correctly updates the LD_LIBRARY_PATH, however, when it is used in galaxy, all the other environment variables are set properly, but not LD_LIBRARY_PATH. Does anyone have any ideas on why this would happen and how to fix it? - Nik. -- Nikhil Joshi Bioinformatics Analyst/Programmer UC Davis Bioinformatics Core http://bioinformatics.ucdavis.edu/ najoshi -at- ucdavis -dot- edu 530.752.2698 (w)

4 10

tool shed updates broken on my local server
by Anne Pajon 06 Feb '15

06 Feb '15

Hi there, I am currently trying to migrate our Galaxy production server onto new hardware and I am facing many challenges. Recently I've been unable to update tools from the tool shed. During the migration I've moved across the files, the data, the tools and their dependencies as well as the database. But I am getting this error while trying to update any tools that are marked 'Updates are available in the Tool Shed for this revision' from the GUI: Admin > Manage installed tool shed repositories > fasta_formatter menu Get updates: Internal Server Error Galaxy was unable to successfully complete your request An error occurred. This may be an intermittent problem due to load or other unpredictable factors, reloading the page may address the problem. The error has been logged to our team. Here is the log from paster.log: 10.20.13.16 - - [29/Jan/2015:16:43:45 +0100] "GET /admin_toolshed/update_to_changeset_revision?tool_shed_url=https://toolshed.g2.bx.psu.edu/&name=fasta_formatter&owner=devteam&changeset_revision=8f0ae92440b8&latest_changeset_revision=1dbb5181c327&latest_ctx_rev=1 HTTP/1.1" 500 - "http://bioinf-gal001:8080/admin_toolshed/browse_repositories?async=false&so…" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:35.0) Gecko/20100101 Firefox/35.0" Error - <type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'get' URL: http://bioinf-gal001:8080/admin_toolshed/update_to_changeset_revision?tool_… File '/mnt/nfs/data/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/error.py', line 149 in __call__ app_iter = self.application(environ, sr_checker) File '/mnt/nfs/data/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/recursive.py', line 84 in __call__ return self.application(environ, start_response) File '/mnt/nfs/data/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/httpexceptions.py', line 633 in __call__ return self.application(environ, start_response) File '/mnt/nfs/data/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 132 in __call__ return self.handle_request( environ, start_response ) File '/mnt/nfs/data/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 190 in handle_request body = method( trans, **kwargs ) File '/mnt/nfs/data/galaxy/galaxy-dist/lib/galaxy/web/framework/decorators.py', line 87 in decorator return func( self, trans, *args, **kwargs ) File '/mnt/nfs/data/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/admin_toolshed.py', line 1953 in update_to_changeset_revision persist=True ) File '/mnt/nfs/data/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/metadata/installed_repository_metadata_manager.py', line 31 in __init__ metadata_dict=metadata_dict, user=None ) File '/mnt/nfs/data/galaxy/galaxy-dist/lib/tool_shed/metadata/metadata_generator.py', line 60 in __init__ self.metadata_dict = { 'shed_config_filename' : self.shed_config_dict.get( 'config_filename', None ) } AttributeError: 'NoneType' object has no attribute 'get' CGI Variables ------------- CONTENT_LENGTH: '0' HTTP_ACCEPT: 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' HTTP_ACCEPT_ENCODING: 'gzip, deflate' HTTP_ACCEPT_LANGUAGE: 'en-US,en;q=0.5' HTTP_CONNECTION: 'keep-alive' HTTP_COOKIE: 'galaxysession=c6ca0ddb55be603a44ec9cad39b01202307c62c9a25600e232d5d3d597344cb74ba4cd8a7123f6e9' HTTP_HOST: 'bioinf-gal001:8080' HTTP_REFERER: 'http://bioinf-gal001:8080/admin_toolshed/browse_repositories?async=false&so…' HTTP_USER_AGENT: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:35.0) Gecko/20100101 Firefox/35.0' PATH_INFO: '/admin_toolshed/update_to_changeset_revision' QUERY_STRING: 'tool_shed_url=https://toolshed.g2.bx.psu.edu/&name=fasta_formatter&owner=de…' REMOTE_ADDR: '10.20.13.16' REQUEST_METHOD: 'GET' SERVER_NAME: '0.0.0.0' SERVER_PORT: '8080' SERVER_PROTOCOL: 'HTTP/1.1' WSGI Variables -------------- application: <paste.recursive.RecursiveMiddleware object at 0x7f34f7a50590> is_api_request: False paste.cookies: (<SimpleCookie: galaxysession='c6ca0ddb55be603a44ec9cad39b01202307c62c9a25600e232d5d3d597344cb74ba4cd8a7123f6e9'>, 'galaxysession=c6ca0ddb55be603a44ec9cad39b01202307c62c9a25600e232d5d3d597344cb74ba4cd8a7123f6e9') paste.expected_exceptions: [<class 'paste.httpexceptions.HTTPException'>] paste.httpexceptions: <paste.httpexceptions.HTTPExceptionHandler object at 0x7f34f7a50550> paste.httpserver.thread_pool: <paste.httpserver.ThreadPool object at 0x7f34f76ef1d0> paste.parsed_querystring: ([('tool_shed_url', 'https://toolshed.g2.bx.psu.edu/'), ('name', 'fasta_formatter'), ('owner', 'devteam'), ('changeset_revision', '8f0ae92440b8'), ('latest_changeset_revision', '1dbb5181c327'), ('latest_ctx_rev', '1')], 'tool_shed_url=https://toolshed.g2.bx.psu.edu/&name=fasta_formatter&owner=de…') paste.recursive.forward: <paste.recursive.Forwarder from /> paste.recursive.include: <paste.recursive.Includer from /> paste.recursive.include_app_iter: <paste.recursive.IncluderAppIter from /> paste.recursive.script_name: '' paste.throw_errors: True request_id: 'fdaf9004a7d511e49d63005056a77528' webob._parsed_query_vars: (MultiDict([('tool_shed_url', 'https://toolshed.g2.bx.psu.edu/'), ('name', 'fasta_formatter'), ('owner', 'devteam'), ('changeset_revision', '8f0ae92440b8'), ('latest_changeset_revision', '1dbb5181c327'), ('latest_ctx_rev', '1')]), 'tool_shed_url=https://toolshed.g2.bx.psu.edu/&name=fasta_formatter&owner=de…') wsgi process: 'Multithreaded' ------------------------------------------------------------ Anything obvious that I've missed? Many thanks in advance for your help. Kind regards, Anne. -- Dr Anne Pajon - Bioinformatics Core Cancer Research UK - Cambridge Institute Li Ka Shing Centre, Robinson Way, Cambridge CB2 0RE anne.pajon(a)cruk.cam.ac.uk | +44 (0)1223 769 631

2 4

Starting uWSGI
by Nicholas Kline 04 Feb '15

04 Feb '15

Hello, I am trying to setup a local production Galaxy server for our department. Our Galaxy server environment is as follows: - Ubuntu 14.04 64-bit - 94 GB Memory - Intel Xeon - Python virtual environment - Nginx - PostgreSQL - ProFTPd Today I tried starting the Galaxy server for the first time. I think the first step in that process is starting uWSGI, correct? To do so, I executed these commands: cd ~/galaxy-dist/ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste config/galaxy.ini However, it appears something failed. This information is returned: The program 'uwsgi' can be found in the following packages: * uwsgi-core * uwsgi-plugin-alarm-curl * uwsgi-plugin-alarm-xmpp * uwsgi-plugin-curl-cron * uwsgi-plugin-emperor-pg * uwsgi-plugin-erlang * uwsgi-plugin-geoip * uwsgi-plugin-graylog2 * uwsgi-plugin-jvm-openjdk-6 * uwsgi-plugin-jvm-openjdk-7 * uwsgi-plugin-ldap * uwsgi-plugin-lua5.1 * uwsgi-plugin-lua5.2 * uwsgi-plugin-php * uwsgi-plugin-psgi * uwsgi-plugin-python * uwsgi-plugin-python3 * uwsgi-plugin-rack-ruby1.9.1 * uwsgi-plugin-router-access * uwsgi-plugin-sqlite3 * uwsgi-plugin-v8 * uwsgi-plugin-xslt Ask your administrator to install one of them According to the galaxy documentation at https://wiki.galaxyproject.org/Admin/Config/Performance/Scaling , "uWSGI support is built in to nginx, so no extra modules or recompiling should be required". Also, should '--ini-paste config/galaxy.ini' really be configured like this instead: --ini-paste universe_wsgi.ini ? Thank you

2 6

Tool Tests failing with "Exception: History in error state."
by Peter Cock 04 Feb '15

04 Feb '15

Retitling thread, On Thu, Nov 6, 2014 at 11:08 AM, Peter Cock <p.j.a.cock(a)googlemail.com> wrote: > Thanks Dave, > > The good news is yes, the tests are running again on the > Test Tool Shed (although not the main Tool Shed yet), and > many of my tools now have successful test results from > last night. > > e.g. My new basic mummer tool which now has a full set > of dependency packages thanks to Bjoern: > https://testtoolshed.g2.bx.psu.edu/view/peterjc/mummer > > The bad news is there are many unexpected failures with: > "Exception: History in error state." > > I'm sure you'll learn more once you look over the logs, > > Thank you, > > Peter Right now the mummer example given above is passing, but I am still getting this error on some of my tools, e.g. https://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go tested 2015-01-25 11:21:12 https://testtoolshed.g2.bx.psu.edu/view/peterjc/get_orfs_or_cdss tested 2015-01-25 10:52:03 (Many of my other tools are also currently listed with different unexpected failures, some of which include the "Exception: History in error state." traceback.) Interestingly, I've just got what appears to be the same exception from a TravisCI test run (following a trivial change to README files): https://travis-ci.org/peterjc/galaxy_blast/builds/48893916 e.g. (one of many similar failing tests in this log) ====================================================================== ERROR: test_tool_000000 (functional.test_toolbox.TestForTool_blastxml_to_top_descr) BLAST top hit descriptions ( blastxml_to_top_descr ) > Test-1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/peterjc/galaxy_blast/galaxy-central-master/test/functional/test_toolbox.py", line 268, in test_tool self.do_it( td ) File "/home/travis/build/peterjc/galaxy_blast/galaxy-central-master/test/functional/test_toolbox.py", line 37, in do_it stage_data_in_history( galaxy_interactor, testdef.test_data(), test_history, shed_tool_id ) File "/home/travis/build/peterjc/galaxy_blast/galaxy-central-master/test/base/interactor.py", line 42, in stage_data_in_history upload_wait() File "/home/travis/build/peterjc/galaxy_blast/galaxy-central-master/test/base/interactor.py", line 279, in wait while not self.__history_ready( history_id ): File "/home/travis/build/peterjc/galaxy_blast/galaxy-central-master/test/base/interactor.py", line 297, in __history_ready return self._state_ready( state, error_msg="History in error state." ) File "/home/travis/build/peterjc/galaxy_blast/galaxy-central-master/test/base/interactor.py", line 356, in _state_ready raise Exception( error_msg ) Exception: History in error state. I do not recall seeing this problem locally when using my development instllation of galaxy-central. The TravisCI failure suggests this could be a stochastic resource contention (I can re-run the TravisCI build and see if this works second time round?), which is more prone to fail under the Tool Shed framework? Peter

3 6

concatenate_datasets docker image can't create output
by Jeltje van Baren 02 Feb '15

02 Feb '15

Hi, I'm following instructions at https://github.com/apetkau/galaxy-hackathon-2014. When I try to run the concatenate-datasets on two input files, two odd things happen. First, TWO nearly identical commands are generated in the History panel, only differing in their output filename. In paster.log, only the second one shows up. Second, the program fails, with this info in the History: An error occurred with this dataset: Galaxy slots passed through contain as 1 /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10/container.sh: line 2: can't create /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/files/000/dataset_14.dat This happens for both commands in the History panel, only the output filename in the other error is dataset_15.dat Oddly, the dataset_14.dat and dataset_15.dat are both created during this command, they just end up empty. Paster.log: galaxy.jobs.runners DEBUG 2015-01-23 11:08:35,973 (10) command is: docker inspect busybox:ubuntu-14.04 > /dev/null 2>&1 [ $? -ne 0 ] && docker pull busybox:ubuntu-14.04 > /dev/null 2>&1 docker run -e "GALAXY_SLOTS=$GALAXY_SLOTS" -v /inside/home/jeltje/exp/varscan2/programs/galaxy-dist:/inside/home/jeltje/exp/varscan2/programs/galaxy-dist:ro -v /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/tools/docker:/inside/home/jeltje/exp/varscan2/programs/galaxy-dist/tools/docker:ro -v /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10:/inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10:rw -v /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/files:/inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/files:rw -w /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10 --net none busybox:ubuntu-14.04 /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10/container.sh; return_code=$?; if [ -f /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10/working_file ] ; then cp /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10/working_file /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/files/000/dataset_15.dat ; fi; sh -c "exit $return_code" galaxy.jobs.runners.local DEBUG 2015-01-23 11:08:36,040 (10) executing job script: /inside/home/jeltje/exp/varscan2/programs/galaxy-dist/database/job_working_directory/000/10/galaxy_10.sh galaxy.jobs DEBUG 2015-01-23 11:08:36,091 (10) Persisting job destination (destination id: docker_local) What could be happening here, and how do I fix it? Thanks, -Jeltje

2 8

Galaxy installation inside a secure environment
by Abdulrahman Azab 02 Feb '15

02 Feb '15

??Hi Galaxy people, At the University of Oslo, we have an infrastructure for storage and computation on sensitive data, called TSD (presented in the attached image). from inside, the infrastructure is logically divided into projects. Each project has a set of shared VMs (among its users) which are running over a file-system (HNAS). The shared project VMS has access to a computational SLURM cluster which is installed on another file-system (Colossus). There are directories in colossus which are mounted on HNAS for each project in order to allow each project users to push files into colossus and run jobs on the cluster. Users of a particular project can access the project main VMs through user VMs (one for each user). Each project VMs (both shared and user VMs) are in a separate subnet. All of this is inside the TSD. Now to access the TSD from outside, there is a complex authentication mechanism where a user can access his/her own VM. And to transfer data from/to the TSD is another complex story. The important thing is that there is NO internet access in or out.? There are two issues here: 1 - What we need to do is to install one Galaxy VM inside each project area, so that it is accessible by all project users. But we cannot use mercurial to access your distribution server. We can though install a bitbucket server inside the TSD and have the code-base there, so that It can be accessed by all project VMs, but I'm not sure what is the procedure here. 2- We are very concerned about the issue of regularly updating Galaxy instances in projects to the recent release. In many cases it causes many problems, e.g. tool versioning conflicts. So we have the idea of installing each of our tools together with all of its dependencies in a separate docker container, and run those as images on each Galaxy project VM. Is this possible and tested? Should this permanently solve the upgrading problem, or do you suggested another alternative? Thank you, Yours sincerely, Abdulrahman Azab Head engineer, ELIXIR.NO / The Genomic HyperBrowser team Department of Informatics, University of Oslo, Boks 1072 Blindern, NO-0316 OSLO, Norway Email: azab(a)ifi.uio.no, Cell-phone: +47 46797339 ---- Senior Lecturer in Computer Engineering Faculty of Engineering, University of Mansoura, 35516-Mansoura, Egypt Email: abdulrahman.azab(a)mans.edu.eg</owa/abdulrahman.azab(a)mans.edu.eg>

2 1

Pulsar on a remote (SGE) cluster
by Joseph Brent Greer 30 Jan '15

30 Jan '15

Hi all, We have Pulsar working in a synchronous fashion using RESTful services on our local network. Now, we're trying to use Pulsar on a remote (SGE) cluster and we will not have the ability to mount a shared file system. What is the best way to use Galaxy to queue jobs? If Pulsar is the answer, how do we defer to the cluster's queue and have Pulsar wait on it? How should Pulsar notify Galaxy when multiple jobs are done running? We've looked through the documentation and listservs and haven't found anything directly related. Any help or suggestions would be great. Thanks, Joe Greer Proteomics Center of Excellence Northwestern University

2 1

condor jobs
by Shrum, Donald C 30 Jan '15

30 Jan '15

Hi all, I've configured one of our tools to submit jobs to our condor cluster. I can see the job is routed to the condor runner: ==> handler4.log <== galaxy.jobs.handler DEBUG 2015-01-30 09:14:58,092 (508) Dispatching to condor runner galaxy.jobs DEBUG 2015-01-30 09:14:58,204 (508) Persisting job destination (destination id: condor) I can see that indeed the job is submitted to the condor cluster: [root@galaxy galaxy-dist]# condor_q -- Submitter: galaxy.local : <10.177.61.90:55265> : galaxy.local ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 21.0 galaxy 1/30 09:15 0+00:00:02 R 0 0.0 galaxy_509.sh The job begins to run: ==> handler4.log <== galaxy.jobs.runners.condor DEBUG 2015-01-30 09:15:03,827 (508/20) job is now running galaxy.jobs.runners.condor DEBUG 2015-01-30 09:15:05,183 (508/20) job has completed Galaxy is almost immediately removing the job working directory: Here is a snippet of the errors: ==> handler4.log <== galaxy.jobs.runners DEBUG 2015-01-30 09:15:06,372 (508/20) Unable to cleanup /panfs/storage.local/opt/galaxy-dist/database/pbs/galaxy_508.ec: [Errno 2] No such file or directory: '/panfs/storage.local/opt/galaxy-dist/database/pbs/galaxy_508.ec' galaxy.jobs DEBUG 2015-01-30 09:15:06,816 setting dataset state to ERROR galaxy.datatypes.metadata DEBUG 2015-01-30 09:15:06,996 Failed to cleanup MetadataTempFile temp files from /panfs/storage.local/galaxy-data/job_working_directory/000/508/metadata_out_HistoryDatasetAssociation_717_zrzVqh: No JSON object could be decoded Is it possible galaxy is attempting to query condor and see if the job is running, not finding anything and deciding that the job is not running and bailing out? I've reconstructed the process step by step using the logs but I have not been able to see exactly where the condor_submit command is shown so I can try to submit the same job manually. Does anyone have a suggestion for debugging this? Thanks, Don Florida State University Research Computing Center

2 1