boinccmd with --quit switch returns before boinc.exe actually exits. This behavior leads to damaged client_state files if some external script rely upon disabling boinc via "boinccmd --quit" before editing client_state.
What is recommended way to stop BOINC from batch file? (non-service install)

---

:LOOP_START
ping <some address for a second or 2>
if exists c:\myflags\boinc_flag goto LOOP_START
boinccmd --quit

I think this would work better ;-) :

boinccmd --quit
:LOOP_START
ping <some address for a second or 2>
if exists c:\myflags\boinc_flag goto LOOP_START

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

Thanks for ideas!
Will try to implement one of them.
Though I still don't understand why such behavior for boinccmd was chosen. It makes --quit switch almost useless. It could return only when boinc.exe truly dies....

---

Boinccmd could do a lot of things it does not do now. You are welcome to request whatever new features you like on a new Trac ticket.

Already requested some... :/
http://boinc.berkeley.edu/trac/ticket/843
With GPU introduction it become even more actual, but... So better will go with other advices.

BTW, what if boinc.exe will be killed directly via kill for exmple?
Running science projects should exit OK with "no heartbeat" message, right ?
What will be if some of them will still running when boinc.exe will be started again? Should I await some errors in this case ?

---

Though I still don't understand why such behavior for boinccmd was chosen. It makes --quit switch almost useless. It could return only when boinc.exe truly dies....

To put the boinccmd application in perspective, it simply sends messages to the running boinc process. Mostly to get or set configuration values. I don't think it was ever really intended as an interactive application.

To simply kill the boinc process is risky as it could have open file/network handles that could potentially become corrupt if not closed nicely and cleanly by boinc. Science applications that use the wrapper may not receive checkpoint/save state instructions which could result in wasted processing when they rewind to last good checkpoint.

The approach of sending boinc the quit signal and then checking that it has quit is probably going to remain the best option. Alternatively, as I understand it, boinc locks the client_state.xml file (open with exclusive access?) when it is running, so you could conceivably check the state of the file before trying to edit it.

I have to admit that I'm mildly curious as to why you would want to edit the client_state.xml file in the first place. Most are content just to read it...

---

ralic's law of forums: Irrespective of any prior research done, you will find the solution to your question shortly after posting it to a public Internet forum, resulting in readers concluding that you have done no research on the matter whatsoever.

I have to admit that I'm mildly curious as to why you would want to edit the client_state.xml file in the first place. Most are content just to read it...

It's a workround for a badly-behaved application (CUDA version of the SETI_enhanced app), which causes sluggish graphics performance on the host computer for some tasks. The desire is to re-allocate these tasks for processing with a traditional CPU application.

For proper file integrity, client_state.xml is only ever read, and a parallel file is created with the desired changes (<version_num> and <plan_class>). On successful completion of the script, the files can be swapped with copy/rename. I've never found the script's access to client_state.xml to be blocked by the file locking you decribe, even while BOINC is fully active.

It's a workround for a badly-behaved application (CUDA version of the SETI_enhanced app), which causes sluggish graphics performance on the host computer for some tasks.

Thanks for the explanation. Consider my mild curiosity appeased. :)

I've never found the script's access to client_state.xml to be blocked by the file locking you decribe, even while BOINC is fully active.

You're correct. I just attempted to write to the client_state.xml file with boinc active and the write was indeed successful. The changes did not persist though, as they were replaced when the running state was written out to disk at the next file update. It's possible that the behaviour I described existed in an earlier revision or that it never actually existed. Chalk it up to old age setting in. :) In any event, please discard my earlier reference to the locking as it is now irrelevant.

---

ralic's law of forums: Irrespective of any prior research done, you will find the solution to your question shortly after posting it to a public Internet forum, resulting in readers concluding that you have done no research on the matter whatsoever.

The changes did not persist though, as they were replaced when the running state was written out to disk at the next file update.

And that's precisely why we need to stop - and indeed restart - BOINC under script control.