I have created a Amazon AMI that starts up boinc and processes work. This works fine. The problem is that when I try to launch another instance with the same AMI (to double processing work), the new instance gets the same hostid as the previous one, which causes problems with aborted jobs, etc.

I have tried: stopping boinc using /etc/init.d/boinc and then deleting client_state.xml and other files that contain hostid. When boinc is restarted, it comes back with the same hostid.

I would really like a way of resetting all work to zero and preventing the client from getting new tasks, then making an AMI image from that such that each launch of a new instance from that image will get a new hostid and start getting new tasks to process.

I am working with www.primegrid.com if that makes a difference.

If you setup BOINC and saved your ami. Then it will have the host CPID in it. Which is the problem you are running into.
Probably the best way would be to save your ami without BOINC configured and have a script attach the host to the project on first startup via boinccmd.

I think there is a 2nd place BOINC stores things on a linux host.. I'll have a look at my aws instance and see if I can recall what I'm thinking of.

Thanks.
How do I remove the configuration once it has been configured? Just delete the boinc user home directory (/var/lib/boinc)?
Or do a remove projects ("boinccmd --project www.primegrid.com detach")?

This could work, where I could create a first-time configure script that logs into an instance and attaches to a project that would persist over reboots. Since I plan on doing Spot Instances on Amazon, they might go away and come back based on spot pricing for instances.

Edit: I checked and the 2 machines have the same host_cpid, which is probably why they are getting the same hostid. The cpid is supposed to be based on a hash of IP address, among other things, and the 2 machines have different (internal and external) IP addresses, so not sure how they got the same cpid. Is it because it was assigned from the first AMI (when first configured) and never recalculated?

The cpid is supposed to be based on a hash of IP address, among other things, and the 2 machines have different (internal and external) IP addresses, so not sure how they got the same cpid. Is it because it was assigned from the first AMI (when first configured) and never recalculated?

The CPID is the hash of the MAC address of the first NIC found. If this is the same on both Instances that the CPID is the same.There is currently no way to enforce a "random" CPID in the client when you know that several machines have the same MAC.

Thanks, I think the problem was that I did not completely remove the hostid references, so the new instance started with the previous hostid. There is a file int the boinc/spot directory that contains the cpid/hostid that I needed to remove.

So, following HAL9000's advices, for future reference, here is what worked for me:

1. Turn off the autostart of boinc; stop boinc from running
2. Remove all xml files with reference to hostid and host_cpid - including client_state.xml, slots/?/init_data.xml. Used 'grep -r hostid' to find all references.
3. Create a new AMI from the AWS console from that instance.
4. Launch a new spot request of whatever size instance at a good price. Make sure to select 'do not delete on termination' and 'persistent request'. The persistent request allows the instance to be brought back if it gets terminated when the spot prices goes above your bid price and then goes back down. There are 2 ways to do a spot request, and it seems that selecting your AMI and then doing Actions->Spot request
let's you make a persistent request and makes it an instance request, rather than a fleet request.
5. ssh into the new instance and perform /etc/init.d/boinc start (or whatever method you set up to start boinc). You should make it autostart if you plan on having it restart with price fluctuations:
$sudo chkconfig --add boinc
$sudo chkconfig boinc on.
6. It is possible that making boinc autostart in step 2 before making the AMI would be a better solution so that you do not have to do step 5, but I wanted to keep control for now.

Thanks

Glad you found the other file. I got distracted and forgot to lookup where it was located.

I also configured BOINC for remote access with boinccmd when I made my image.
That way I don't have to remote into the system to do anything. I just spool up an instance and then tell BOINC to do what I need from home. Most of that kind of stuff I made scripts for. So I don't have to muck about typing out all the commands.