Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extended wait command #130

Open
sgenie68 opened this issue Aug 12, 2011 · 8 comments
Open

Extended wait command #130

sgenie68 opened this issue Aug 12, 2011 · 8 comments

Comments

@sgenie68
Copy link

How hard is it to implement wait job command, which does this:

  1. if no job id given, waits for any job
  2. Can wait on for a certain status and for the given period of time - like wait job gricli_10 active 10 -- means waiting for at most 10 seconds until gricli_10 becomes active
@makkus
Copy link

makkus commented Aug 12, 2011

That should be easy enough to implement, but what do you mean with "waits for any job"? Do you mean it should wait until all the users jobs are finished? Does that makes sense, what would be the usecase? I think it could be a bit dangerous, since "wait" is typed in quickly. Since there's no way within gricli (yet?) to cancel a running task -- (ctrl-c) exits gricli alltogether -- if a user did that accidently it could be quite inconvenient.

I can see that there might be one for having a wait command where you can provide multiple jobs, though...

@vladimir-mencl-eresearch
Copy link
Member

+1 for a wait command (with job ID given)

Not sure how useful would be waiting for "all jobs" (as bash wait would do)

Might also be useful to have an all-in-one "submit"+"wait done"+"download-clean"

@yuriyh
Copy link
Member

yuriyh commented Aug 16, 2011

Might also be useful to have an all-in-one "submit"+"wait done"+"download-clean"

there will probably be something like ${last_job_id} so:
submit "something"
wait ${last_job_id} for 10m
downloadclean ${last_job_id}

@sgenie68
Copy link
Author

Can the wait be done on any job? Say, I submit a batch of 100s of jobs, and once I hit the point where I reach max cores, I wait for any job to finish - then submit another one...

@yuriyh
Copy link
Member

yuriyh commented Aug 16, 2011

this is not smartest idea. let the scheduler deal with queues, so submit all your jobs without regard to max number of cores.

@sgenie68
Copy link
Author

Fair enough - ok, another use case (magma) - I start the job and don't care what the id is - I need the job to change state to active?

@yuriyh
Copy link
Member

yuriyh commented Aug 16, 2011

that is what last_id will be for.

Excerpts from reply+i-1392703-d4724197408b2c93d5f04ff1e57e7a935d8b6f56's message of Tue Aug 16 13:56:35 +1200 2011:

Fair enough - ok, another use case (magma) - I start the job and don't care what the id is - I need the job to change state to active?

@sgenie68
Copy link
Author

Sorry, I thought you referred to a particular job id, rather than a specific mentioning of last - without digging for the id. Point taken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants