[galaxy-dev] October 2014 Galaxy Newsletter

[Dave Clements]

Hello all,

A lot is happening in in the Galaxy in October, and a lot of good stuff
happened in September too. Take a look at the October 2014 Galaxy Newsletter
 for the complete
story, but here are some highlights:

   -

   *Galaxy needs your input!
   
*
You
   may even get rewarded for your input ...
   -

   IRC channel to be logged
   
,
   starting this month
   -

   Slides from ECCB'14 and upcoming events
   
   -

   71 new papers
   ,
   including 6 featured papers
   -

   Who's Hiring?
    Lots
   of places, that's who
   -

   Two new public Galaxy Servers
   
   -

   New Deployment Catalog and Log Board entries
   
   -

   36 new ToolShed repos
   
   -

   And a smattering of other news
    too

Happy October!

Dave Clements and the Galaxy Team

-- 
http://galaxyproject.org/
http://getgalaxy.org/
http://usegalaxy.org/
https://wiki.galaxyproject.org/
___
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/

[galaxy-dev] Get Data - url upload (connection timed out)

[Elizabeth Chia]

Dear *

I have a local galaxy instance installed on a cluster.

I've been trying to upload data by URL but kept getting this error: *"unable
to fetch  [Errno socket error] [Errno 110] connection timed
out". *I've tried with and without file compression format and still gives
me that error.
Am I suppose to modify/edit any particular config file?

Can't seem to find a similar thread or answer to this but perhaps I may
have missed. Apologies if I have missed. Would appreciate if anyone can
please advise.

Thanks.

Best regards
liz
___
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/

[galaxy-dev] bowtie_indices.loc for 'bowtie_wrappers' tool

[Peter Briggs]

Dear all

Am I right in thinking that, although the current 'bowtie_wrappers' 
package from the toolshed creates the file


.../galaxy-dist/tool-data/bowtie_indices.loc

no data is ever actually loaded from this file (and so any entries added 
to it are ignored)?


Empirically, it appears only entries in the .loc file under


.../galaxy-dist/tool-data/toolshed.g2.bx.psu.edu/repos/devteam/bowtie_wrappers/9ca609a2a421/

are actually used to populate the relevant menu in the "bowtie for 
illumina" tool.


Is there a reason why the redundant file is still created?

Thanks, best wishes

Peter

Ps this is in galaxy-dist changeset 14355:007f6a80629a

--
Peter Briggs peter.bri...@manchester.ac.uk
Bioinformatics Core Facility University of Manchester
B.1083 Michael Smith Bldg Tel: (0161) 2751482
___
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/

Re: [galaxy-dev] Internal Server error when attemptng to use Admin Tab

[John Chilton]

Hello David,

We don't have a workaround yet - but we (Dan did most of the
investigating) understand the problem I think. You are using a MySQL
database I assume? (Ignore the rest of this e-mail if not). I think
MySQL has lower limits on the size of BLOBs that can be stored in the
database than postgres - and we think the tool shed is tried to
storing a really large blob of metadata in the database and it got
truncated and now Galaxy is failing because it cannot load that entry
as JSON.

The work around would be something like trying to find the truncated
column in the tool_repositories table - deleting it and references -
changing that column to a LONGBLOB and reinstalling that tool.

I have created a Trello card for this bug report.

https://trello.com/c/RbW6pOd2

It is said a lot but we strongly encourage not using MySQL.

It might be worth trying this patch
(https://bitbucket.org/galaxy/galaxy-central/pull-request/511/allow-model-objects-to-be-loaded-when-they/diff#comment-3288189)
from Dan as well. I am not sure what the tool shed would do if it
cannot find the metadata though.

-John

On Mon, Sep 29, 2014 at 11:41 AM, David Bernick  wrote:
> Good morning -
>
> I have acquired an Internal server error on our local galaxy install. It
> seems to be an unterminated string.  How do I resolve this?
> thanks in advance -
> David Bernick
> UCSC
>
> Here is the relevant portion of the log (I hope).
>
> Error - : Unterminated string starting at:
> line 1 column 65528 (char 65528)
> URL: http://campusrocks.cse.ucsc.edu:8080/admin/index
> File
> '/projects/galaxy/bin/galaxy-dist/lib/galaxy/web/framework/middleware/error.py',
> line 149 in __call__
>   app_iter = self.application(environ, sr_checker)
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/Paste-1.7.5.1-py2.6.egg/paste/recursive.py',
> line 84 in __call__
>   return self.application(environ, start_response)
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/Paste-1.7.5.1-py2.6.egg/paste/httpexceptions.py',
> line 633 in __call__
>   return self.application(environ, start_response)
> File '/projects/galaxy/bin/galaxy-dist/lib/galaxy/web/framework/base.py',
> line 132 in __call__
>   return self.handle_request( environ, start_response )
> File '/projects/galaxy/bin/galaxy-dist/lib/galaxy/web/framework/base.py',
> line 190 in handle_request
>   body = method( trans, **kwargs )
> File
> '/projects/galaxy/bin/galaxy-dist/lib/galaxy/web/framework/__init__.py',
> line 383 in decorator
>   return func( self, trans, *args, **kwargs )
> File
> '/projects/galaxy/bin/galaxy-dist/lib/galaxy/web/base/controllers/admin.py',
> line 34 in index
>   installing_repository_ids =
> suc.get_ids_of_tool_shed_repositories_being_installed( trans.app,
> as_string=True )
> File
> '/projects/galaxy/bin/galaxy-dist/lib/tool_shed/util/shed_util_common.py',
> line 277 in get_ids_of_tool_shed_repositories_being_installed
>   app.install_model.ToolShedRepository.status == loading_datatypes_status )
> ):
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/query.py',
> line 2348 in instances
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/mapper.py',
> line 2120 in _instance
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/mapper.py',
> line 1974 in populate_state
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/orm/strategies.py',
> line 150 in fetch_col
> File
> '/projects/galaxy/bin/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.6-linux-x86_64-ucs4.egg/sqlalchemy/types.py',
> line 658 in process
> File '/projects/galaxy/bin/galaxy-dist/lib/galaxy/model/custom_types.py',
> line 52 in process_result_value
>   return json_decoder.decode( str( _sniffnfix_pg9_hex(value) ) )
> File '/usr/lib64/python2.6/json/decoder.py', line 319 in decode
>   obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> File '/usr/lib64/python2.6/json/decoder.py', line 336 in raw_decode
>   obj, end = self._scanner.iterscan(s, **kw).next()
> File '/usr/lib64/python2.6/json/scanner.py', line 55 in iterscan
>   rval, next_pos = action(m, context)
> File '/usr/lib64/python2.6/json/decoder.py', line 183 in JSONObject
>   value, end = iterscan(s, idx=end, context=context).next()
> File '/usr/lib64/python2.6/json/scanner.py', line 55 in iterscan
>   rval, next_pos = action(m, context)
> File '/usr/lib64/python2.6/json/decoder.py', line 217 in JSONArray
>   value, end = iterscan(s, idx=end, context=context).next()
> File '/usr/lib64/python2.6/json/scanner.py', line 55 in iterscan
>   rval, next_pos = action(m, context)
> File '/usr/lib64/python2.6/json/decoder.py', line 183 in JSONObject
>   value, end = iterscan(s, idx=end, context=context).next()
> File '/usr/lib64/python2.6/json/scanner.py', line 55 in iterscan
>   rval, next_pos = action(m, context)
> File '/usr/lib64/python2.6/json/decoder.py', line 217 in

Re: [galaxy-dev] Get Data - url upload (connection timed out)

[John Chilton]

I doubt there is a config option somewhere that is going to fix this.

Can your compute nodes download external data outside of Galaxy? (One
could submit a test script to the cluster with a download and see if
it succeeds.) If you give me the URL and let me know what kind of
cluster you are running I could help you formulate that test.

If we can confirm that the cluster nodes cannot download external
files - it might be worth running `upload1` jobs with a local job
runner instead of on the cluster - frequently login servers and web
servers have more external access than compute nodes in cluster
environments. Let me know if you need help configuring that.

-John

On Wed, Oct 1, 2014 at 3:41 AM, Elizabeth Chia  wrote:
> Dear *
>
> I have a local galaxy instance installed on a cluster.
>
> I've been trying to upload data by URL but kept getting this error: "unable
> to fetch  [Errno socket error] [Errno 110] connection timed
> out". I've tried with and without file compression format and still gives me
> that error.
>
> Am I suppose to modify/edit any particular config file?
>
> Can't seem to find a similar thread or answer to this but perhaps I may have
> missed. Apologies if I have missed. Would appreciate if anyone can please
> advise.
>
> Thanks.
>
> Best regards
> liz
>
> ___
> 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/
___
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/

Re: [galaxy-dev] Login with a system user

[John Chilton]

I don't know how one would do this precisely but I believe it is
possible at the proxy level - i.e. setting up Apache to handle this
and authenticate with system resources. I believe Tim Booth's work on
integrating galaxy into biolinux uses system users for authentication
by default.

The following thread has more discussion on that:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2014-March/018770.html

More generic information on configuring an Apache Proxy can be found here:
https://wiki.galaxyproject.org/Admin/Config/ApacheProxy

Hope this helps.

-John

On Tue, Sep 30, 2014 at 9:22 AM, Daniel Ruiz Molina
 wrote:
> Hello,
>
> I have configured Galaxy, but I would be very interested in configure it
> with PAM or /etc/passwd (/etc/shadow) instead of creating a user in the web
> interface.
> How can I configure Galaxy for authenticating with system files?
>
> Thanks.
> ___
> 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/
___
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/

Re: [galaxy-dev] 'KeyError' in workflow extraction when using newer tool version

[John Chilton]

Sorry this has been sitting in my inbox for a while - because I wanted
to try to fix it before the next release but I don't think it is going
to happen.

Generically - it doesn't surprise me that Galaxy can handle certain
parameters changing between versions but not conditionals - they are
handled in a much more complex manner. I have updated this
(https://trello.com/c/INCluhxP) Trello card to reference this problem.

Sorry I don't have better news right now.

-John


On Tue, Sep 23, 2014 at 5:54 AM, Peter Briggs
 wrote:
> Dear all
>
> One of my users has encountered a problem with extracting a workflow from a 
> history in our local Galaxy installation (tag latest_2014.08.11, changeset 
> 14342:db520d154716).
>
> The history was created with a version of a local tool which has since been 
> updated, and the extraction page warns that the newer version of the tool 
> will be used for those datasets i.e.:
>
> Dataset was created with tool version "0.0.4", but workflow extraction will 
> use version "0.0.7".
>
> However when the extraction is run it fails immediately: the user sees the 
> "Internal Server Error" page, and in the log I see:
> =
> Error - : 'platform'
> URL: https://galaxy.ls.manchester.ac.uk/workflow/build_from_current_history
> File 
> '/home/galaxy/production/galaxy-dist/lib/galaxy/web/framework/middleware/error.py',
>  line 149 in __call__
>   app_iter = self.application(environ, sr_checker)
> File 
> '/home/galaxy/production/galaxy-dist/eggs/Paste-1.7.5.1-py2.6.egg/paste/recursive.py',
>  line 84 in __call__
>   return self.application(environ, start_response)
> File 
> '/home/galaxy/production/galaxy-dist/eggs/Paste-1.7.5.1-py2.6.egg/paste/httpexceptions.py',
>  line 633 in __call__
>   return self.application(environ, start_response)
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/web/framework/base.py', 
> line 132 in __call__
>   return self.handle_request( environ, start_response )
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/web/framework/base.py', 
> line 190 in handle_request
>   body = method( trans, **kwargs )
> File 
> '/home/galaxy/production/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/workflow.py',
>  line 1220 in build_from_current_history
>   workflow_name=workflow_name
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/workflow/extract.py', 
> line 30 in extract_workflow
>   steps = extract_steps( trans, history=history, job_ids=job_ids, 
> dataset_ids=dataset_ids, dataset_collection_ids=dataset_collection_ids )
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/workflow/extract.py', 
> line 104 in extract_steps
>   tool_inputs, associations = step_inputs( trans, job )
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/workflow/extract.py', 
> line 271 in step_inputs
>   associations = __cleanup_param_values( tool.inputs, param_values )
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/workflow/extract.py', 
> line 330 in __cleanup_param_values
>   cleanup( "", inputs, values )
> File '/home/galaxy/production/galaxy-dist/lib/galaxy/workflow/extract.py', 
> line 327 in cleanup
>   group_values = values[input.name]
> KeyError: 'platform'
> =
>
> 'platform' is a conditional parameter that was introduced into the tool 
> between the two versions. It looks like when tying to use the newer verison 
> of the new tool, that the new parameter is not getting picked up. Is this 
> expected behaviour?
>
> (Btw I've seen a similar issue i.e. the "KeyError: 'platform' exception when 
> I have the two versions of this tool installed from a local toolshed, and try 
> switching between to the newer one from the older one.)
>
> Any help or suggestions are greatly appreciated.
>
> Many thanks
>
> Peter
>
> --
> Peter Briggs peter.bri...@manchester.ac.uk
> Bioinformatics Core Facility University of Manchester
> B.1083 Michael Smith Bldg Tel: (0161) 2751482
>
>
> ___
> 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/
___
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/

Re: [galaxy-dev] Simple standard for API use of a global user/key that all loaded tools can draw upon?

[John Chilton]

I don't know about a standard way of doing - I am not sure about
Galaxy officially supporting this but you can add whatever properties
you want in universe_wsgi.ini (which will be renamed config/galaxy.ini
in coming release). These can be accessed within tool cheetah blocks
as $__app__.config.config_dict['name_of_property']. So we can define
some unofficial standards for what to populate there such as
galaxy_tool_api_url and galaxy_tool_api_key.

In terms of the keys - there are some other things to be aware of. It
is now possible to define a user-less master key in the config file.
This would be accessible to tools as $__app__.config.master_api_key.
It may be worth considering using that instead of grabbing a new key
(some operations require a user though - so this master api key isn't
a silver bullet). Also as of the last release there is a standard way
to access keys from within Galaxy for users that *MAY* work within
tool cheetah blocks.

I haven't tested it bu my guess would be you do something like:

#from galaxy.managers import api_keys#
command --opt1=foo --api_key="${api_keys.ApiKeyManager( $__app__
).get_or_create_api_key( $__user__ )}"

(But that is unofficial and I haven't tried it myself.)

Hope these random thoughts help somewhat.

-John

On Thu, Sep 25, 2014 at 3:18 PM, Dooley, Damion  wrote:
> Do any of you see the need to establish a way for tools to use a global 
> (current site) API url/key combination?  From a security perspective I'm 
> assuming this is basically ok since tools run under the galaxy user anyways 
> (and can directly read and write files to their heart's content).  I 
> understand that a particular user's API key could help limit what they have 
> access to.  My tool however wants to do some prepatory form display and 
> post-job work on behalf of the Galaxy system in addition to working with 
> user-centric data; I presume others have similar use-case needs.
>
> I think it would amount to having a standard GALAXY_TOOL_API_URL and 
> GALAXY_TOOL_API_KEY managed in universe_wsgi.ini (left blank if not desired 
> by sys admin).  The key would be generated by a galaxy admin using a real 
> admin user id.  These would be available as python or shell environment 
> variables when it came time to execute a tool's  interpreter="python"> etc. work.
>
> The wee other detail is that I'm using  
> in my tool xml because there is API information I have to retrieve to set up 
> the form with.  So the url and key need to be accessible in that execution 
> environment too?!!
>
> Am I missing the boat; alternately has this already been talked about?!
>
> Thanks for advice ...
>
> Damion
>
> Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre 
> for Disease Control
> 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
> ___
> 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/

___
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/

Re: [galaxy-dev] Login with a system user

[Will Holtz]

This should be possible with Apache as the proxy and the mod_auth_pam
Apache module. From a high level, the configuration should be similar to
using mod_authnz_ldap or mod_auth_kerb as documented here:
https://wiki.galaxyproject.org/Admin/Config/ExternalUserDatbases

-Will


On Wed, Oct 1, 2014 at 10:03 AM, John Chilton  wrote:

> I don't know how one would do this precisely but I believe it is
> possible at the proxy level - i.e. setting up Apache to handle this
> and authenticate with system resources. I believe Tim Booth's work on
> integrating galaxy into biolinux uses system users for authentication
> by default.
>
> The following thread has more discussion on that:
> http://lists.bx.psu.edu/pipermail/galaxy-dev/2014-March/018770.html
>
> More generic information on configuring an Apache Proxy can be found here:
> https://wiki.galaxyproject.org/Admin/Config/ApacheProxy
>
> Hope this helps.
>
> -John
>
> On Tue, Sep 30, 2014 at 9:22 AM, Daniel Ruiz Molina
>  wrote:
> > Hello,
> >
> > I have configured Galaxy, but I would be very interested in configure it
> > with PAM or /etc/passwd (/etc/shadow) instead of creating a user in the
> web
> > interface.
> > How can I configure Galaxy for authenticating with system files?
> >
> > Thanks.
> > ___
> > 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/
> ___
> 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/
>



-- 
The information contained in this e-mail message or any attachment(s) may
be confidential and/or privileged and is intended for use only by the
individual(s) to whom this message is addressed.  If you are not the
intended recipient, any dissemination, distribution, copying, or use is
strictly prohibited.  If you receive this e-mail message in error, please
e-mail the sender at who...@lygos.com and destroy this message and remove
the transmission from all computer directories (including e-mail servers).

Please consider the environment before printing this email.
___
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/

[galaxy-dev] Vagrant-Galaxy for development purposes

[Kandalaft, Iyad]

Hi Everyone

I wanted to share some code with the galaxy community and I am looking for 
opinions on the following approach.

Overview:
We want to create a standardized galaxy tool development environment to address 
specific problems we faced in the past while minimizing training and 
hand-holding efforts associated with galaxy development.

Problems encountered:
Getting start with Galaxy tool development is complicated as it requires an 
understanding of the whole system (not just Galaxy and the tool shed).
Devs accidentally use the latest galaxy release to develop their tools instead 
of the in-house production server release.
Dev's environment is tainted with system-wide installed software -> 
tool-dependencies can't be verified because the system installed binaries are 
on the path regardless.
Dev's environment is substantially different from production server environment 
-> tool dependencies work in dev but not in prod.
Several other issues that I can't quite remember

Solution and outcomes:
Use provisioning software such as vagrant to standardize the dev environment.

· Reduce time and training required on getting galaxy/toolshed 
installed and started

· Provides ability to easily blow away the dev environment and 
re-instantiate it

· Provides a clean dev environment every time that isn't tainted with 
system-wide installations of software

· Provides a more similar environment to the production server 
(assuming it runs the same OS)


I hope that this is useful for other galaxy tool devs.  I am open to 
collaboration to improve this initiative and I am looking for insight on some 
problems we are facing.

The repo is on github: https://github.com/AAFC-MBB/vagrant-galaxy  Forked from 
the Smithsonian/vagrant-galaxy repo

Regards,


Iyad Kandalaft

Bioinformatics Application Developer, Science and Technology Branch
Agriculture and Agri-Food Canada / Government of Canada
iyad.kandal...@agr.gc.ca / Tel: 613-759-1228 / TTY: 613-773-2600

Développeur de logiciels bioinformatique, Direction Général de Science et 
Technology
Agriculture et Agroalimentaire Canada / Gouvernement du Canada
iyad.kandal...@agr.gc.ca / Tél. : 613-759-1228 / ATS: 613-773-2600

___
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/

[galaxy-dev] Jobs stuck in "new" state - Data Library datasets to blame?

[Lance Parsons]

Recently, I updated our Galaxy instance to use two processes (one for 
web, the other as a job handler).  This has been working well, except in 
a few cases.  I've noticed that a number of jobs get stuck in the "new" 
status.


In a number of cases, I've resolved the issue by downloading and 
uploading one of the input files and rerunning the job using the newly 
uploaded file.  In at least one of these cases, the offending input file 
was one that was copied from a Data Library.


Can anyone point me to something to look for in the database, etc. that 
would cause a job to think a dataset was not ready for use as a job 
input?  I'd very much like to fix these datasets since having to 
re-upload data libraries would be very tedious.


Thanks in advance.

--
Lance Parsons - Scientific Programmer
134 Carl C. Icahn Laboratory
Lewis-Sigler Institute for Integrative Genomics
Princeton University

___
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/

Re: [galaxy-dev] Jobs stuck in "new" state - Data Library datasets to blame?

[Aaron Petkau]

Are you attempting to upload datasets to a Data Library, and then copy to a
history and run jobs on them right away?  I've run into issues before where
if I attempt to run a job on a dataset in a library before it is finished
being uploaded and processed, then the job gets stuck in a queued state and
never executes.

Aaron

On Wed, Oct 1, 2014 at 2:51 PM, Lance Parsons 
wrote:

> Recently, I updated our Galaxy instance to use two processes (one for web,
> the other as a job handler).  This has been working well, except in a few
> cases.  I've noticed that a number of jobs get stuck in the "new" status.
>
> In a number of cases, I've resolved the issue by downloading and uploading
> one of the input files and rerunning the job using the newly uploaded
> file.  In at least one of these cases, the offending input file was one
> that was copied from a Data Library.
>
> Can anyone point me to something to look for in the database, etc. that
> would cause a job to think a dataset was not ready for use as a job input?
> I'd very much like to fix these datasets since having to re-upload data
> libraries would be very tedious.
>
> Thanks in advance.
>
> --
> Lance Parsons - Scientific Programmer
> 134 Carl C. Icahn Laboratory
> Lewis-Sigler Institute for Integrative Genomics
> Princeton University
>
> ___
> 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/
>
___
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/