Hi Björn, Does stopping other, non-split jobs work correctly for you?
--nate On Wed, Feb 26, 2014 at 7:30 AM, Björn Grüning <bjoern.gruen...@gmail.com>wrote: > Hi Nate, > > I'm running > > changeset: 12641:cab3db6e1d59 > > and I can see the same behaviour. The blast job is not listed under jobs > in the admin section and I can't kill it, also not via deleting the dataset. > > Anything I can do to track that down? > In my case it's a large blast job with splitting enabled. > > Cheers, > Bjoern > > > > Hi all, >> >> There was a regression introduced in the most recent stable release that >> was preventing jobs from being stopped, fixed here: >> >> >> https://bitbucket.org/galaxy/galaxy-central/commits/ >> 1298d3f6aca59825d0eb3d32afd5686c4b1b9294?at=stable >> >> You can pull from the stable branch of galaxy-central to get that >> changeset. If that doesn't resolve the problem, it sounds like it may be >> due to the crashing handlers, so we would need to figure out the cause of >> those crashes. >> >> --nate >> >> >> On Sat, Feb 22, 2014 at 12:24 PM, Björn Grüning >> <bjoern.gruen...@gmail.com>wrote: >> >> Hi, >>> >>> I have one running at the moment, that job is also not listed in the jobs >>> monitor under the admin-panel. >>> >>> Cheers, >>> Bjoern >>> >>> >>> On Tue, Feb 18, 2014 at 2:20 PM, Federico Zambelli >>> >>>> <federico.zambe...@unimi.it> wrote: >>>> >>>> Hi, >>>>> >>>>> something strange happens with Cufflinks in our Galaxy server. When a >>>>> user >>>>> deletes a running Cufflinks job in fact the associated Cufflinks >>>>> process(es) >>>>> are not terminated. Apart from unneccessary CPU usage, this prevents >>>>> other >>>>> jobs from starting if the max jobs limit has been already reached by >>>>> the >>>>> user. >>>>> >>>>> This happens only with Cufflinks, Cuffcompare for comparison behaves >>>>> just >>>>> fine. >>>>> >>>>> Best, >>>>> F. >>>>> >>>>> What cluster system are you using? Can you try a few other long >>>> running tools for comparison? >>>> >>>> I've been meaning to double check if this still happens, but I had seen >>>> this for BLAST+ jobs under SGE (noticeable again when large zombie >>>> jobs are blocking the queue). >>>> >>>> Peter >>>> ___________________________________________________________ >>>> 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/ >>> >>> >> >
___________________________________________________________ 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/
