[Odysseus]

I asked the following on the BOINC Core Client message board and it was suggested I ask here (sorry if this is covered in a FAQ or something, but I couldn’t find it from the Resource page or from the searches I tried):

I’ve set up BOINC to run as a service on an iMac running “Tiger” (using the Make_BOINC_Service.sh script from the tools-for-Mac-admins page); it’s been crunching away quite happily for SETI@home and Einstein@home. I’m considering installing an optimized S@h app but, embarassingly enough, I recently realized I don’t know how to stop the client properly so it won’t get confused by the sudden appearance of an app_info file. I presume there are commands one can send it from the Terminal to stop & start the service; could someone please point me towards some info on this?

[reader50]

Open the Make_BOINC_Service.sh script in a text editor so you can read it. TextEdit will do it, or any number of other editors / word processors. Scripts are basically text files, so documentation is often embedded in the file. There are some instructions for removal in this script, namely:

Originally Posted by BOINC script

## Removal (to stop running BOINC as a daemon / service):
## (1) In the Finder, browse to the /Library/StartupItems folder.
## (2) Drag the boinc directory to the trash. (Finder will ask for
## your administrator user name and password).
## (3) Restart the computer.

If you don't want to interrupt your server with a reboot, try downloading the CLI version of BOINC from this page. The 5.4.9 "Unix command-line version" for Mac OS X will do nicely. I suspect that the GUI tools are just a wrapper for the command-line version of BOINC, so the command-line tool will hopefully work in this instance.

When you expand the file, you'll get a new BOINC folder on your desktop, with two files inside. "boinc" and "boinc_cmd". Move the "boinc_cmd" file to the same folder as your existing BOINC client. This is a command-line tool to send commands to a running BOINC instance.

Open a Terminal window and navigate to the folder with boinc_cmd in it. Then type this command to read BOINC's run mode:

./boinc_cmd --get_run_mode

Make note of what it returns, it should be "auto" or possibly "always". Then type the following command to suspend all BOINC projects:

./boinc_cmd --set_run_mode never

BOINC should shut down all the workers. When you've finished what you wanted to edit or install, use this command to start things up again.

./boinc_cmd --set_run_mode auto

If the mode it reported earlier was "always", then substitute "always" for "auto" in the above command.

If the boinc_cmd tool actually works on your install, then you might want to read the docs for additional things it can do for you.

[Odysseus]

If you don't want to interrupt your server with a reboot, try downloading the CLI version of BOINC from this page. The 5.4.9 "Unix command-line version" for Mac OS X will do nicely. I suspect that the GUI tools are just a wrapper for the command-line version of BOINC, so the command-line tool will hopefully work in this instance.
[…]
If the boinc_cmd tool actually works on your install, then you might want to read the docs for additional things it can do for you.

Thanks a lot for the suggestion; I’ll try it out. I had read those instructions in the script (IIRC they’re on the download page as well) but I don’t want to remove BOINC, just to stop and restart the core client. I can already control the apps from BOINC Manager, including the Activity menu, but quitting BM has no effect on the CC in this setup.

Just to clarify: are you saying it’s safe to drop an optimized S@h executable & app_info file into the project folder with BOINC running, as long as the existing apps are suspended? (FWIW I leave apps in memory.) Should the queue be run out first with “No new tasks”?

[reader50]

It's safe to drop an additional SETI@home worker into the folder, and the corresponding app_info.xml file. BOINC checks for the app_info.xml file only when it starts up SETI@home. I'd expect it to notice the new files when the current work unit finishes, or the next time it's started - such as if you suspended BOINC via the command-line tool.

If it does notice in mid-workunit, the current unit will be dumped (or restarted), and the queue possibly dumped as well. So I'd at least suggest waiting for the latest unit to finish, unless it only just started.

The script looks like it prevents BOINC from quitting when BM does, by changing the owner of BOINC to root. When you quit BM from a user account, it doesn't have the needed permissions to quit the boinc process. You could log in as root, and use BM from there. When you quit BM as root, I'd expect the boinc process to shut down.

Note: the instructions in the script are for removing the daemon auto-start-on-boot functionality. It shouldn't remove BOINC itself. I've never used that script, but it doesn't look like it moves the real BOINC directory into Startup Items. It just creates a startup item in that location, which the removal directions tell you to trash.

[Odysseus]

Originally Posted by reader50 

It's safe to drop an additional SETI@home worker into the folder, and the corresponding app_info.xml file. BOINC checks for the app_info.xml file only when it starts up SETI@home. I'd expect it to notice the new files when the current work unit finishes, or the next time it's started - such as if you suspended BOINC via the command-line tool.

That’s not quite how it worked out. Just to be safe, I let the S@h queue run out with the project set to NNT. After Updating to report the completed work, I suspended BOINC from the Activity menu, exited BOINC Manager, and installed the new executable & app_info. Then I reopened BOINC Manager, set it to run according to preferences again, and let S@h download some work. Good news: there were no errors or untoward events at all; the iMac received ten WUs and immediately began crunching a couple of them. Bad news: BOINC did not see the app_info file and continued using the stock app, ignoring the optimized version.

So I set the project to NNT again, intending to restart when the cache was empty. As it turned out, Apple had a couple of Software Updates for the system this morning—a firmware update and a security patch—so I had a good excuse to reboot anyway. Once the cached work had been completed and reported, I installed the system updates. After the mandatory reboot, BOINC did recognize the app_info file, and when I allowed new tasks it began to crunch them with the optimized app. So my problem is solved, and I didn’t even have to use a command-line! Thanks for your help.

The moral of the story appears to be that while it’s safe to drop in a new worker while BOINC is running but suspended, it won’t be able to do anything until BOINC is stopped and restarted.