Rodney: I changed the BOINC client to support "run 1 task and exit". To do this, use the following options or config flags:
fetch_minimal_work: tells the client to fetch only 1 job per device exit_when_idle: tells the client to exit when jobs are done. (Note that this runs 1 task per device; e.g. on a 4-CPU machine it will run 4 jobs. You can change this using the "ncpus" option). This change will be in the 6.12 client release, which we should release soon for testing. If you need it sooner, you can build your own client from SVN trunk. -- David Rodney Walker wrote: > Hi, > I read about Condor and they run boinc from a sched deamon on the worker > node. It is killed by a signal when real Condor jobs arrive, so this is > not an example of a batch jobs based boinc. > I tried several things, including > ... --exit_when_idle --exit_after_finish > > $ cat cc_config.xml > <cc_config> > <log_flags> > </log_flags> > <options> > <report_results_immediately>1</report_results_immediately> > </options> > </cc_config> > > and it seems not possible to run a single task, upload result and exit. > I can only see bad workarounds, such as monitoring the log to see when a > task is finished and uploaded and then kill boinc ungracefully. > > Apparently I have the right list to request this functionality though. I > would be happy with a configurable task limit, i.e. 1. More generally, > it would be good to request only tasks shorter than some time limit. > > Cheers, > Rod. > > > > > Rom Walton wrote: >> Grid platforms such as Condor-G use a mechanism known as backfill to >> integrate BOINC. >> >> Does WLCG use Condor as its grid infrastructure? >> >> ----- Rom >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Rod Walker >> Sent: Thursday, May 27, 2010 4:36 PM >> To: Paul D. Buck >> Cc: BOINC Developers Mailing List >> Subject: Re: [boinc_dev] Run 1 task and then exit >> >> Hi, >> Maybe I am using boinc in a way it was not intended for. I am >> investigating running boinc on willing remote clusters around the >> Grid(WLCG). Resource owners get very upset about leaving daemon-like >> processes, such as boinc, on their WNs after the batch job has left. >> Therefore boinc must cleanup and vacate the WN before the batch job >> ends. It is a filler, so should vacate as soon as the smallest unit of >> work is done, in order that higher priority jobs can start. >> >> I'll try without the abort then. >> >> Cheers, >> Rod. >> >> Paul D. Buck wrote: >> >>> Did you try it with only --exit_when_idle --exit_after_finish? >>> >>> Abort will likely terminate uploads. And, your upload will likely not >>> >> happen until the next time you run ... because the upload happens after >> the end of the running task completion ... and if there is only one >> task, BOINC will be idle and will exit ... >> >> >>> Since BOINC is intended to run at all times, why are you trying to get >>> >> it to exit? >> >>> Would it not be suitable for your purposes to control the execution of >>> >> single tasks on the machine with the server side? >> >>> On May 27, 2010, at 12:56 PM, Rod Walker wrote: >>> >>> >>> >>>> Hi, >>>> The client I started interactively with >>>> --exit_when_idle >>>> is still running, having processed several tasks. >>>> >>>> A client started from a batch job with >>>> --abort_jobs_on_exit --exit_when_idle --exit_after_finish >>>> did finish after one task, but did not upload the result. >>>> >>>> Do you know of anyone running boinc in batch jobs? >>>> >>>> Cheers, >>>> Rod. >>>> >>>> >>>> >>>> David Anderson wrote: >>>> >>>> >>>>> I think the --exit_when_idle option will do what you want. >>>>> >>>>> The documentation is lacking in this area. >>>>> I'll fix this soon. >>>>> >>>>> -- David >>>>> >>>>> Rodney Walker wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> In order to run Boinc in a batch job, I`d like to run 1 task and >>>>>> >> then >> >>>>>> exit. The only promising command line argument is >>>>>> --exit_after_finish >>>>>> but this is in the debugging section - is the upload of the result >>>>>> >> done >> >>>>>> in this case? >>>>>> >>>>>> A really useful option would be a soft and hard limit on the time >>>>>> >> the >> >>>>>> task should take. This would allow one to fill a cluster with boinc >>>>>> >> jobs >> >>>>>> when it is idle, but free up the slots quickly when the high >>>>>> >> priority >> >>>>>> jobs arrive. >>>>>> >>>>>> Cheers, >>>>>> Rod. >>>>>> >>>>>> Ps. Apologies if this is the wrong list, but I did not find >>>>>> >> anything >> >>>>>> more appropriate. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> boinc_dev mailing list >>>>> [email protected] >>>>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>>> To unsubscribe, visit the above URL and >>>>> (near bottom of page) enter your email address. >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> boinc_dev mailing list >>>> [email protected] >>>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>> To unsubscribe, visit the above URL and >>>> (near bottom of page) enter your email address. >>>> >>>> >>> >>> >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
