|
|
Upgrade
You might want to consider getting a more recent version of the S@H software. I'm running:
/Users/chris/setiathome-3.03.powerpc-apple-darwin1.2% setiathome -version SETI@home client. Platform: powerpc-apple-darwin1.2 Version: 3.03 [...sniiiiip] The version I installed last week came with a very helpful README file that seem to give a more straightforward approach here. A relevant section reads as follows:
If you want setiathome to be started automatically, you can
set up a cron job. Add the following line to your crontab:
0 * * * * cd ; ./setiathome -nice 19 > /dev/null 2> /dev/null
Where is the directory where the setiathome client is installed.
This cron job will attempt to start the client at the top of every hour.
If it is already running, the next invocation will do nothing.
If the client is not running, it will be started.
For more information on cron jobs see the crontab(1) manual page.
As per your advice, it might be a good idea to chance /dev/null to /dev/console, but otherwise, this seems like a better approach to me. It runs as a cron job, so the system will run it even when you're not logged in (or someone else is logged in, or whatever). No monkeying around with new terminals for it etc. The bit I'm not sure about is how you might want to adjust things for a multiprocessor setting. I have no experience with this, and perhaps things should indeed be done differently. All the same, I still feel that going through the cron system is a better strategy overall.
Upgrade (not)
I'm running the 3.03 version and aware of their cron suggestion.
Upgrade (not)
Ok, so adjust the cronjob to only launch if setiathome isn't running:
0 * * * * cd setidir; ((ps ax | grep seti | grep -v grep) || ./setiathome -nice 19) > /dev/console 2> /dev/console Check for the presense of the setiathome process, filter out the check itself, and if the check fails then launch seti again. There's probably about a million ways to do this ("timtowtdi"), but as a general rule I still think that ways that work through the cron system are going to be more suitable than ways that try to avoid or work around it. My actual line goes to /dev/console (now, but I may put it back to /dev/null if I decide I'd rather have it run quietly), and more importantly it also sends an email if anything goes wrong (which seems like a better alert mechanism than the console anyway, at least to me -- it can go to another machine, can be read later, etc). |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.06 seconds |
|