This turned out to be my own ignorance. After creating identical handlers in both universe_wsgi.ini and job_conf.xml, and restarting Galaxy in daemon mode, the jobs became resilient to Galaxy restarts. DOH!
Thanks Nate for pointing this out, as well as the limits collection. David On Mar 31, 2014, at 12:20 PM, Ido Tamir <ta...@imp.ac.at> wrote: > In my case it was uncompleted metadata in one of the input files. > (but maybe it was not "new" state but something else?) > > HTH, > ido > > On Mar 26, 2014, at 5: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. >> >> Wondering, >> 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: >> 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/
