How to dump a WU on a notfred VM?

[harlam357]

Ok, I've got a unit here that isn't going to make it's deadline p5101. I've tried moving it to another machine, but that didn't work. :sigh: So then I tried deleting the unit work folder and queue.dat manually then rebooting, it just restored itself. :double sigh: Tried logging into the available shell and killed Fah processes... hoping to make it error out. :triple sigh:.

How in the heck do I get rid of this thing? Arrrggghhh... very frustrating. :mad:

I only run these couple notfred's instances to continually test with HFM... if I didn't have that need, I'd move these couple instances back to my home-baked Ubuntu images in a minute.

[Adak]

What happens if you move your system date up past the deadline, will NotFred's see that and grab another WU to fold?

What I've done is make another directory, unzip folding zip file, into it, and close down VMPlayer with VMPlayer >> Troubleshoot >> Power off and exit.

Then, when you restart VMPLayer, after a pause to let it close everything down, don't select the P5101 image to load. Choose the new directory instead.

[pik4chu]

whenever I need to reset a WU I have to delete the work folder, queue.dat AND the unitinfo file. Sounds strange but I have had to do that a couple of times on my Vista box because Ive rebooted it and forgot to stop the services first, thus requiring me to blow everything away and start again.

[harlam357]

What happens if you move your system date up past the deadline, will NotFred's see that and grab another WU to fold?

What I've done is make another directory, unzip folding zip file, into it, and close down VMPlayer with VMPlayer >> Troubleshoot >> Power off and exit.

Then, when you restart VMPLayer, after a pause to let it close everything down, don't select the P5101 image to load. Choose the new directory instead.

Well.... that's exactly what I didn't want to go through. Although with the time I spent on it earlier today, I could have already done that. Notfred's is great... as long as nothing goes wrong or you don't need to manipulate the client once it's running. To be fair, that VM had been running for quite a while without issue... but when stuff like this comes up it just gets to be a pain. I could have swapped that unit out with another one of my Ubuntu VMs in just a couple minutes.

whenever I need to reset a WU I have to delete the work folder, queue.dat AND the unitinfo file. Sounds strange but I have had to do that a couple of times on my Vista box because Ive rebooted it and forgot to stop the services first, thus requiring me to blow everything away and start again.

Tried that. :( Actually, I've found that unitinfo.txt is nothing more than an information file. It has no bearing on the WU itself in my experience. Now when deleting a unit, that doesn't mean one won't get the same one again. To change that one needs to delete their machineindependant.dat file. The machine will then retrieve a new User ID (not your Folding ID / User Name) and will be happily assigned different work. Machineindependant.dat is how Stanford keeps up with specific client instances.

I'm up for any other suggestions... although in the short term looks like I'm just going to have to replace the VM. Maybe I'll go to the TR Forums and ask notfred himself. They might benefit from an HFM posting as well. ;)