Thank you for your answer and for trying to help. This is greatly
I didn't really made any progress in tracking down this error, and
hopefully this weird behaviour will not happen anymore with the November
But here are my answers to your questions, in case it would ring a bell:
Has this behaviour been reported with any other workflow?
It has been reported with 2 different workflows as of now. These 2
workflows doesn't have anything in common, except that they are huge (one
of them has 37 steps, producing a total of about 110 datasets).
Are you running Galaxy as a single process or multiple processes? If
multiple processes, how many web, handler and manager processes do you
have and are they all on the same machine?
We are running Galaxy in multiple processes with 5 web servers, 3 job
handlers and no manager (I believe the manager was rendered obsolete in
one of the latest Galaxy distributions). All these processes are run on
the same machine.
Have you made any modifications to Galaxy that could result in this
What is the value of track_jobs_in_database in your universe_wsgi.ini
We never touched this part of the configuration file and the line still
reads: "#track_jobs_in_database = None".
After reading your answer, I've decided to modify this line to:
"track_jobs_in_database = True"
Unfortunately, running one of the faulty workflows several times (5x), I
noticed that one of them was still showing this strange behaviour where
some jobs were executed before their inputs were ready.
Do you think this issue could be related to the fact that we are using
Galaxy with the multiple processes configuration? We implemented this
configuration some time ago because some of our users were complaining
about the slow responsiveness of the web interface.
Would you recommend using Galaxy without the multiple processes
configuration? (Lets say if updating to November 4th distribution doesn't
fix this issue)
I guess you are probably using the multiple processes configuration as
well on Galaxy main?
Thanks again for your help!
Posted by John Chilton on Nov 09, 2013; 2:50pm
Have you made any progress tracking down this error? This appears very
serious, but to tell you the truth I have no clue what could cause it. The
distribution you are using is pretty old at this point I feel like if it
was a bug the exhibited under relatively standard parameter combinations
someone else would have reported it by now.
Can you tell me some things: has this been reported with any other
workflows? Is there anything special about this workflow? Can you rebuild
the workflow and see if the error occurs again?
Additional questions if the problem is not restricted to the workflow:
are you running Galaxy as a single process or multiple processes? If
multiple processes, how many web, handler, and manager processes do you
have? Are they all on the same machine? Have you made any modifications to
Galaxy that could result in this behavior? What is the value of
track_jobs_in_database in your universe_wsgi.ini configuration file?
On Thu, Nov 7, 2013 at 10:34 AM, Jean-Francois Payotte <[hidden email]>
Dear Galaxy mailing-list,
Once again I come seeking for your help. I hope someone already had this
issue or will have an idea on where to look to solve it. :)
One of our users reported having workflows failing because some steps were
executed before all their inputs where ready.
You can find a screenshot attached, where we can see that step (42) "Sort
on data 39" has been executed while step (39) is still waiting to run
This behaviour has been reproduced with at least two different Galaxy
tools (one custom, and the sort tool which comes standard with Galaxy).
This behaviour seems to be a little bit random, as running two times a
workflow where this issue occurs, only one time did some steps were
executed in the wrong order.
I could be wrong, but I don't think this issue is grid-related as, from my
understanding, Galaxy is not using SGE job dependencies functionality.
I believe all jobs stays in some internal queues (within Galaxy) until all
input files are ready, and only then the job is submitted to the cluster.
Any help or any hint on what to look at to solve this issue would be
We have updated our Galaxy instance to August 12th distribution on October
1st, and I believe we never experienced this issue before the update.
Many thanks for your help,
Hi All --
I'm a novice when it comes to all things programming, but I recently
installed my own instance of Galaxy because I'm working with very large
datasets. Everything seems to be running OK, but when I attempt to run
Cuffdiff (w/ ref. annotation and bias correction from UCSC genome) on
output from Tophat2, I get the following error: "*Error: sort order of
reads in BAMs must be the same*." I'm perplexed, because I downloaded this
output from Tophat2 that I ran on the public server, before putting it
through Cuffdiff on my local instance. When I tried running the same files
(prior to download) in Cuffdiff on the public server, they ran just fine.
So, why do the files run properly when I run them publicly, but not
locally? Am I missing some metadata? Is my install not complete? Does the
ordering of bam files change when you download them? I've had a hard time
finding solutions, so any tips are greatly appreciated.
Dear Galaxy Devs and Users,
I'm pleased to announce the Galaxy Docker Image project!
The Galaxy Docker Image is an easy distributable full-fledged Galaxy
installation, that can be used for testing, teaching and presenting new
tools and features.
One of the main goals is to make the access to entire tool suites as
easy as possible. Usually, this includes the setup of a public available
webservice that needs to be maintained, or that the Tool-user needs to
either setup a Galaxy Server by its own or to have Admin access to a
local Galaxy server. With docker, tool developers can create their own
Image with all dependencies and the user only needs to run it within
docker. Ideally suited to make your reviewers happy :)
Currently, I have three test images to play with. The first one,
bgruening/galaxy-stable is the main Image that will do all the heavy
lifting of setting up PostgreSQL, Apache and Galaxy.
bgruening/deepTools and bgruening/chemicaltoolbox are proof of concepts
how easy it is to create an own Image build on top of the main Galaxy Image.
How to use it:
docker run -d -p 8080:80 bgruening/galaxy-deeptools
docker run -d -p 8080:80 -p 8000:8000 bgruening/galaxy-chemicaltoolbox
For a more detailed description please read:
I would be very much interested in any kind of feedback.
Especially, in two technical questions:
I'm not sure if a "trusted build" from the docker index is the best way
to go. Trusted Builds in docker are super convenient. It is a
post-commit hook from github. Every time something is pushed, the image
will be rebuild. The problem is that I can't tag my images with "trusted
builds" and unless I have missed something, that forces me to create new
repositories every time a new Galaxy release is out.
A better way would be, one repository with different tags:
galaxy-stable, galaxy-feb-2014 and so on. Every Galaxy release will be
just a diff between the old and the new. But this is not possible with
One other trick I used is to remove the mercurial history, that saves
180MB. I'm not sure if this is wise, because it probably kills a few use
cases. Currently, the aim of this project is a little bit different from
being a developer environment. So I decided to remove it. Please ping me
if this was a bad decision :)
Thanks for reading!
I think one of the aspects where Galaxy is a bit soft is the ability to do
distributed tasks. The current system of split/replicate/merge tasks based
on file type is a bit limited and hard for tool developers to expand upon.
Distributed computing is a non-trival thing to implement and I think it
would be a better use of our time to use an already existing framework. And
it would also mean one less API for tool writers to have to develop for.
I was wondering if anybody has looked at Mesos (
http://mesos.apache.org/). You can see an overview of the Mesos
The important thing about Mesos is that it provides an API for C/C++,
Java/Scala and Python to write distributed frameworks. There are already
implementations of frameworks for common parallel programming systems such
- Hadoop (https://github.com/mesos/hadoop)
- MPI (
- Spark (http://spark-project.org)
And you can find example Python framework at
Integration with Galaxy would have three parts:
1) Add a system config variable to Galaxy called 'MESOS_URL' that is then
passed to tool wrappers and allows them to contact the local mesos
infrastructure (assuming the system has been configured) or pass a null if
the system isn't available.
2) Write a tool runner that works as a mesos framework to executes single
cpu jobs on the distributed system.
3) For instances where mesos is not available at a system wide level (say
they only have access to an SGE based cluster), but the user wants to run
distributed jobs, write a wrapper that can create a mesos cluster using the
existing queueing system. For example, right now I run a Mesos system under
the SGE queue system.
I'm curious to see what other people think.
I know a few people have talked about using docker to package and
distribute Galaxy tools. The most recent version now runs on all major
linux distributions, so it's a bit more inclusive now (but there probably
won't ever be a windows or mac version). One strategy would be for tool
configs to define an option Docker archive name and possibly an alternate
command line to execute if the docker archive is being used.
How far has that work gotten, and what are people thinking about it?
I am going to forward your email to the galaxy-dev list so that the
development community can offer comments/suggestions.
On 8/30/11 2:27 AM, Petr Novak wrote:
> Hi everybody,
> I am developing the application on Galaxy server. One of the requirement
> is to create user specific list of options. Is it possible to access
> somehow $__user_email__ in <options> tag or in <conditional> ?. I did
> not found documentation how to used cheetah in galaxy tool xml files but
> from files provided with galaxy, cheetah is used only in <command> and
> <config> tag. Is that rigth? If it can be used in any part of xml
> definition file it would make much easier to generate xml dynamicaly
> based on the $__user_email__
> Does anybody have an idea how to manage this problem?
> Petr Novak
> The Galaxy User list should be used for the discussion of
> Galaxy analysis and other features on the public server
> at usegalaxy.org. Please keep all replies on the list by
> using "reply all" in your mail client. For discussion of
> local Galaxy instances and the Galaxy source code, please
> use the Galaxy Development list:
> To manage your subscriptions to this and other Galaxy lists,
> please use the interface at:
Is there any way to provide a protected resource link to the external
My tool is supposed to call a Web service via SSL which should access to
the Galaxy resources.
In ideal it would be something like
The Web service then downloads the resource and do the computation.
Since user is already provided the login to galaxy, I do not want to ask
the password again on a tool page.
I'm trying to write a new tool working with tabular data (specifically
a Reciprocal Best Hits (RBH) tool using BLAST style tabular output).
I want the user to be able to choose a column number (from one of the
input files), but I have a default column in mind. However, Galaxy
doesn't seem to obey the default column number:
<param name="a_vs_b" type="data" format="tabular" label="Hits
from querying A against B" description="Tabular file, e.g. BLAST
<param name="b_vs_a" type="data" format="tabular" label="Hits
from querying B against A" description="Tabular file, e.g. BLAST
<param name="id1" type="data_column" data_ref="a_vs_b"
multiple="False" numerical="False" value="1" label="Column containing
query ID" help="This is column 1 in standard BLAST tabular output" />
<param name="id2" type="data_column" data_ref="a_vs_b"
multiple="False" numerical="False" value="2" label="Column containing
match ID" help="This is column 2 in standard BLAST tabular output"/>
<param name="score" type="data_column" data_ref="a_vs_b"
multiple="False" numerical="False" value="12" label="Column containing
containing score to rank on" help="The bitscore is column 12 in
standard BLAST tabular output"/>
I've tried giving the default column value numerically (as shown), and
also using value="c2" etc. Regardless, Galaxy just defaults to the
Is this a bug, or am I doing something wrong?
I submitted a workflow that in turn submits a drm job to sun grid engine.
The queue had an error (probably due to a problem with automount).
Traceback (most recent call last):
File "/inside/depot4/galaxy/lib/galaxy/jobs/runners/__init__.py", line 60, in run_next
File "/inside/depot4/galaxy/lib/galaxy/jobs/runners/drmaa.py", line 169, in queue_job
external_job_id = self.ds.runJob(jt)
File "/inside/depot4/galaxy/eggs/drmaa-0.4b3-py2.7.egg/drmaa/__init__.py", line 331, in runJob
_h.c(_w.drmaa_run_job, jid, _ct.sizeof(jid), jobTemplate)
File "/inside/depot4/galaxy/eggs/drmaa-0.4b3-py2.7.egg/drmaa/helpers.py", line 213, in c
return f(*(args + (error_buffer, sizeof(error_buffer))))
File "/inside/depot4/galaxy/eggs/drmaa-0.4b3-py2.7.egg/drmaa/errors.py", line 90, in error_check
raise _ERRORS[code-1]("code %s: %s" % (code, error_buffer.value))
DeniedByDrmException: code 17: error: no suitable queues
When the sysadmin cleared the error, the job started running normally after being in an error state for 10 minutes.
The cool thing is that galaxy kept running without a problem.
galaxy.jobs.runners.drmaa DEBUG 2013-06-27 14:51:22,968 (10481/4767487) state change: job is running
galaxy.jobs.runners.drmaa DEBUG 2013-06-27 15:00:23,628 (10481/4767487) state change: job is queued and active
galaxy.jobs.runners.drmaa DEBUG 2013-06-27 15:00:27,751 (10481/4767487) state change: job is running
However in the history panel, the job shows as queued but not running, even if I refresh the history panel.
Is this normal or should the status change to running?
I'm using this version of straight galaxy:
user: Dannon Baker <dannonbaker(a)me.com>
date: Sat Jun 15 09:08:09 2013 -0400
summary: Fix reports import issue reported by Lance, https://trello.com/card/bug-in-reports-webapp-imports/506338ce32ae458f6d1...
UC Santa Cruz