This is pretty common in the case of workflows. When a workflow step fails,
the next job in the workflow will be set to the "paused" state and all jobs
downstream of the paused job will remain in the "new" state until
corrective action is taken. The current query for finding jobs-ready-to-run
(if tracking jobs in the database, which is automatically enabled for
multiprocess Galaxy configurations) ignores 'new' state jobs whose inputs
are not ready, so these jobs sitting around should not cause any harm.
On Wed, Mar 26, 2014 at 12:25 PM, David Hoover <hoove...@helix.nih.gov>wrote:
> I have many jobs stuck in the 'new' state on our local Galaxy instance.
> The jobs can't be stopped using the Admin->Manage jobs tool. First, does
> anyone know why a job would get stuck in the 'new' state for weeks? I have
> cleaned things up by manually setting their states to 'error' in the MySQL
> database. Is there a better way of dealing with 'new' jobs?
> BTW, our Galaxy instance was updated about two weeks ago.
> David Hoover
> Helix Systems Staff
> 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:
> To search Galaxy mailing lists use the unified search at:
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:
To search Galaxy mailing lists use the unified search at: