Hello Carrie,
I put an artificial sleep into upload.py and tried to replicate this
with the local, DRMAA, and SLURM job runners but could not. I was
working out of galaxy-central instead of galaxy-dist s it is possible
it has been fixed since the last dist update - the history panel has
seen a lot of development. Can you let us know if the problem persists
after the next upgrade (I think it will be out in a couple weeks)?
-John
On Thu, Apr 3, 2014 at 2:15 PM, Ganote, Carrie L cgan...@iu.edu wrote:
Hi List,
I've noticed that the mechanisms for catching job termination signals don't
seem to apply to uploading jobs. I was having trouble with *any* jobs being
terminated until I pulled Nate's changeset 1298d3f from Galaxy central, but
it still doesn't work for uploads. It will remove them from the history, but
if I restart Galaxy, they are put back into the history (whether or not
there is anything actually happening). If the upload.py script is actively
running and I delete the job, the history item comes back up during the next
watch cycle. I've been experimenting with staging files as part of a job and
I notice that if I set the job state to upload during the staging, the job
never gets marked as deleted or deleted_new if I try to remove it from the
history with the X button - so the logic I have to stop the upload is never
run.
Thanks for any insight,
Carrie Ganote
___
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/
