Force FAHControl to abandon current unit?

[r_avital]

Hi all,

I've been happily contributing since 2008, mostly on Linux systems, in a screen session using fah6, which has worked quite well.

Recently installed V7 client, with the attendant FAHControl, FAHClient and FAHViewer, all working very nicely so far.

Today, a Linux box crashed, and I restored it from a clonezllla image from 24 hours ago, which already had the above client, control and viewer modules installed. The problem is, it is now processing a work-unit that was already processed and uploaded, so it's wasting its time.

Is there a way to force it to abandon the current work-unit and start working on a new one? The ETA on the current one is about 22 hours, so it's not too big a deal, but I'd like to know if I can stop it and start a new one.

Thanks!

[bruce]

The official answer is to use the --dump N command string at startup time. This presumes that you're enough of a linux guru to understand how to (re-)start FAHClient with a command-line parameter string (and which is probably a challenge for the novice).
https://fah-web.stanford.edu/projects/F ... ncesV6ToV7

They didn't intend to make it too easy to do.

There are other cheap-and-dirty methods that many people use such as destroying the data that's needed to process the WU.

[N0OA]

I suspect the simplest is to delete the slot from the advanced / configure screen of the fahcontrol interface and then simply add the slot back in. That should dump the data and down load a new one very easily.

N0OA

[Jesse_V]

I suspect the simplest is to delete the slot from the advanced / configure screen of the fahcontrol interface and then simply add the slot back in. That should dump the data and down load a new one very easily.

N0OA

+1 on that.

If you've got any custom slot settings, you wouldn't want to lose them while doing this, so be sure to write them down and reenter them of course.

[7im]

Delete a slot, add a slot, reconfigure all my settings... Ya that sounds so much easier than a one liner in a command prompt.

[r_avital]

Thanks so much, folks,

Attempted this:

sudo service FAHClient stop
(client stopped OK)

sudo service FAHClient --dump all
sudo service FAHClient start

No errors, so I thought I must have done it right, but FAHClient showed it picked up the same WU right where it left off.

So I went with the second advice, in FAHClontrol, configure>slots, deleted the slot, saved, recreated it, saved, and now FAHControl shows a different procject ID with progress-bar at 0% and a different ETA.

Thanks again!

[7im]

The notes in the chart linked above say the WU is not immediately dumped after using the dump command. There is a short delay while the work server is contacted.

[Joe_H]

Delete a slot, add a slot, reconfigure all my settings... Ya that sounds so much easier than a one liner in a command prompt.

The hard part in using the dump command from the command line is not entering a "one liner", but getting all of the paths correct. I went through this trying to dump a WU from a service setup on OS X, the default paths for FAHClient run from the command line are not the same as when set up as a service. Having looked at the Linux logs, the same applies for those OS's. The command either needs to be run from the right directory, or the paths have to be specified correctly on the command line. I found it much easier to recreate a folding slot in FAHControl.

Now, if the folding was done from the command from the start, then the relative paths are all the same when trying to use --dump from the command line. Then it is an easy one liner, no stopping and starting of the service, etc.

[7im]

Just curious, how long did it take for your client to dump the work unit? Or was it immediate?

[Joe_H]

No more than 5 to 10 seconds total plus upload time. It took nearly 2 hours to figure out the correct absolute paths and relative paths to use in the command line since the executable and data directories are different.