Folding@Home Client Restart Script

Soldato
Joined
16 Dec 2005
Posts
14,443
Location
Manchester
What?
Introducing a new over-the-top way of restarting your Folding@Home clients. Restart-Fah.

This is a simple [bloody 6 hours simple! :p] Windows PowerShell script for restarting any Folding@Home client you set. What's more, the script also supports changing your machineid setting if set the appropriate -IncrementId option. The script fully supports [probably] the client.cfg format [despite appearences it is a binary file, not plain text]. Meaning your client wont throw a wobbly over the edited settings file and reset it to defaults.

Why?
Just lately I have been having a bit of a headache with my Folding@Home clients. First it was my GPU clients, then my SMP clients started giving me grief with Stanford's current lack of Work Units. Restarting the client is not always enough to get work. Changing the machineid for that client has been shown to work on occassion. It takes no effort on your part with Restart-Fah, so why not at least try? :D

As stated this a Windows PowerShell script [sorry penguin people!1]. It was written in PowerShell V2.0 [Preinstalled on Windows 7] but it should work in PowerShell V1.0 [Vista]. V2.0 is available for all versions of Windows from XP onwards via the Windows Management Framework .

I opted for PowerShell as it an environment I am very interested in for managing Windows Domains. Everything from Domain Controllers to lowly workstations can be managed easily, remotely and in bulk! As a means of getting to grips with it, I thought I would solve some issues I was having with my own machines - namely folding clients!

This script is a smaller part of a bigger project I am working on - FaHCMS. FahCMS - or Folding@Home Client Monitoring Script [catchy, I know!] - will monitor all clients on your machine and restart them when they stall or are accidently shutdown. I don't want to say too much about FaHCMS at this point as I am still experimenting [already accidently lost a WU :o]. Suffice to say if it comes to fruition, you can [read: maybe] leave your Windows-based Folding@Home clients alone safe in the knowledge FaHCMS is taking care of it. Watch this space!

How?
The Restart-Fah script itself is relatively quite simple, if not a little rough around the edges! You run the script, with or without the -IncrementId option, and it goes away and restarts your Folding@Home client.

You can grab the script here, if you haven't already! :eek: Restart-Fah
Enough waffle, time for the cheese. Or something...

NB: You will need to open the script in something like notepad and edit lines 2 and 3 to suit your client. Details in the Known Issues section below.

From within a PowerShell Console window [Run > powershell.exe] altering any paths as necessary.

Code:
c:\scripts\restart-fah.ps1
And that's it! The script will run, and after a little over 10 seconds your client will have restarted. Want to change your machineid? No problem...

Code:
c:\scripts\restart-fah -IncrementId
Done. :)

The 10 second delay is entirely artificial. The processes usually end within a
second or two, but the delay just ensures they aren't lingering before trying to restart the client.

At this point it only supports one client, but there is no reason why you can't have several copies of the script set with a different F@H client directory. It does not matter where you run the script from, as the code ensures the client's working directory is correct. Also, you cannot run the script directly by double-clicking the file in Windows Explorer. This is a deliberate feature of PowerShell.

Administrative rights are not required to run restart-fah. This has been tested on Windows 7 and SBS 2008. Feedback on Vista and XP would be great if anyone has the inclination to try! :)

Other running methods
What's that, you don't want to have to open the PowerShell console to run the script? Not a problem. You can either create a shortcut that points to powershell.exe "C:\scripts\restart-fah". If you wish to use the -IncrementId option, use powershell.exe "C:\scripts\restart-fah -IncrementId" instead.

Alternatively, you could run it from a CMD prompt [or put the command in a Batch script!]:

Code:
powershell.exe "C:\scripts\restart-fah"
powershell.exe "C:\scripts\restart-fah -IncrementId"
Creating a shortcut or a batch script will allow you to run the script by double-clicking something!

Known Issues
This script is only version 0.6 and as such is entirely capable of going horribly wrong! Nah it wont. Honest, guv!

1: It doesn't do anything clever to work out where your client is located. So you will have to open the script file in Notepad or similar and edit lines 2 and 3 [marked by comments].

Line 2 asks for the full path to the client directory [with no trailing backslash].

Line 3 asks for the name of your client.exe. In my case it is fah6.exe.

2: If you have more than one client on your machine, running the script with the -IncrementId option is entirely NOT recommended. Restart-Fah does not keep track of all machineid's in use so a conflict is highly likely.

3: The script is a little bit too trusting and assumes all processes in the client_directory path are folding processes that must be stopped. Needless to say horrible things may happen if you choose a directory such as System32 and ran the script! ;). This is the first thing I plan to remedy, so fear not those of a nervous disposition. UPDATE: I have corrected this massive potential disaster. The script will only kill the client.exe and fahcore* processes. So even if you [accidentally/deliberately] set the wrong directory, it won’t end all life as we know it.

4: There is almost no error capture or correction in the script, so if anything goes wrong it will bomb out in a spectacular manner. Actually it won’t, at worse you get some nasty red writing. Something I will work on if the script gains any ground here. :) UPDATE: I added some error capture for the client path settings. The script should stop with an error if any of the paths cannot be resolved.

5: For those interested in how the script works, my code is a tad messy and might not be entirely efficient. It is very much a work in progress, so bear that in mind. All suggestions for improvement are welcome.

6: You tell me! :p

Troubleshooting
There isn't really a lot to go wrong with this script, but I will update this as and when issues arise. I will however get the ball rolling with an issue almost everyone will run into.

So you try to run Restart-Fah, either in the PowerShell console or via a batch script and you get the following error:



File C:\Scripts\restart-fah.ps1 cannot be loaded because the execution of scrip
ts is disabled on this system. Please see "get-help about_signing" for more det
ails.
At line:1 char:27
+ C:\Scripts\restart-fah.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : RuntimeException


Uh oh! :p

This is due to the default policy of PowerShell not allowing any scripts to run. This can be changed very simply via a PoSH console. Run a new PowerShell window as and Administrator, and at the prompt type

Code:
Set-ExecutionPolicy -ExecutionPolicy "RemoteSigned"
You will be met with a confirmation. Choose Y and hit Enter. All done! This setting allows all locally created scripts to run, but not those you have downloaded. So you may wish to copy the contents of Restart-Fah to a file you have created locally, otherwise powershell wont run it [as it is not signed]. You could also use "Unrestricted" instead of RemoteSigned, this will allow any script to run. The choice is yours. As always you do these things entirely at your own risk! :eek::p

Another issue you may run into is running the script from within PowerShell when the file path contains spaces.

Code:
#this will generate an error due to the spaces
C:\my folder with spaces\scripts\restart-fah.ps1
#this will just echo the path back to the console
"C:\my folder with spaces\scripts\restart-fah.ps1
#Use this method!
& "C:\my folder with spaces\scripts\restart-fah.ps1
I would also like to point out that PowerShell is entirely case-insensitive.

Code:
#these will all work
Restart-Fah.ps1
RESTART-FAH.PS1
restart-fah -incrementid
#and so on
1. I created a bash script for Linux a few years ago that periodically checked the CPU load and restarted the SMP client if it was idle. I created it when my SMP client at the time would sometimes hang/stall between WUs. You can find the script here. I used this script for a long time without any issue.

I do not know if it is still fully functional, but if anyone is interested I can always tweak it if necessary. The rar contains the script and some documentation, including how to set up a cronjob for the script.
 
Last edited:
I am going to use this space to maintain a list of requested changes or additions. I will start us off! [Items in GREEN have been implemented into the script.]

  1. Put an option in to allow clients to be started with flags [such as -smp x].
    • Although you can add all the flags you need via the client config I think it may be of use.
  2. Rudimentary support for multiple clients when changing machineid
    • If you had say two clients, the script could use only odd numbers for one client, and even for the other thus avoiding any machineid conflict.
  3. Add support for restarting clients over the network [Requested by dekez]
    • If I can make it work, it will likely be an extra option such as "-computerName <computer>"


Anything in the above list wont necessarily make it into the script. If it is a small/simple change then it will more than likely make it in.
 
Last edited:
Let me know how it goes :D

It is completely safe to use. I abused my SMP client last night for about 5 hours straight! No loss of WUs. :)
 
I hope you have spread your backups around! Doesn't matter how many you have if one disaster can take em all out. :eek::p

I hope the script is a handy tool for people. Have almost finished the first version of it's big brother script that will monitor clients and automatically restart!
 
Have others had a go at this script yet? I am curious about any bugs/issues if there are any [other than those listed above of course].

Also would like to know if people would be interested in the monitoring script I am working on? I will make it either way since I have so many clients to look after, but if there is a demand I might devote a bit more time to it than I have last few days :D
 
Powershell was designed to be used across networks - for example you can run one command for many computers, like:

Code:
get-wmi win32_operatingsystem -computerName Raven, Windward | select __server, buildnumber, servicepackmajorversion

And that will come back with all the info from each of the listed computers. I should be able to leaverage that in my own script. I will need to take a deeper look into remotely starting processes - the last time I tried, the process would start on the remote machine, but no window came up and HFM.NET didn't report that particular client as running.

So, I will add that as a requested feature, as not running out to the shed each time would be nice for you :P
 
Powershell is supported by everything from XP upwards! :D

Make it ideal to write scripts in. Even if it does take a minute or two to set it up on each machine.
 
Boo, I appear to have hit a brick wall with running the script remotely. While powershell supports almost all commands across remote computers, it would seem there is a hole when it comes to starting applications or even scripts remotely.

More accurately, scripts can run, but certain parts do not work. Namely Start-Process. On a local machine Start-Process notepad.exe for example will ping open notepad. Try that same command on a remote machine and while the process may start, nothing happens. The only fraction of a glimmer of an explanation I have found is the process is simply in a "waiting" state. I am trying to work out if I can kick it up the arse, but I am not hopeful!

I even tried using psexec and the same thing occurred. Starting to wonder if I am doing something wrong :p

UPDATE: OK, good news and bad news.

I will start with the bad - the reason why nothing showed up was due to security. Any application started remotely is invisible. Why this would prevent something like a folding client from actually running I do not know. However, and here is the good news, it can be started - if I invoke the cmd.exe application.

Although process have invisible windows when started remotely, they can still run, or should. Batch files appear to be quite happy to run and I successfully managed to run a batch file remotely which kick starts the client. It is not the most eloquent solution, as it requires yet another script!

I will work on it and see if I can refine it some more. Perhaps run CMD.exe with some arguments to launch the clients, rather than run a batch file.
 
Last edited:
I plan to monitor the unitinfo file for the progress of the F@H client. If there is no change to the progress after n amount of time, it knows the client has hung/stopped. If I can monitor remotely, I can also restart remotely! :)

As I have said an extra small batch file is not exactly eloquent, but tbh I can have the script automatically generate the batch file - it's only two lines...

Code:
cd <path to fah directory?
fah6.exe

I would prefer to be able to run something like: "cmd.exe /c cd etc..." but so far that hasn't worked. Still, no bother :)
 
The script was designed with console folding clients in mind. So each script would kill the processes in the configured folder and then restart the client from the same folder.

I could modify the script [or show you how to modify it] in order to make it use your .exe to start the client. The only issue I can see is will that .exe try to start all of your GPU clients, even if you are only restarting one of them?
 
In order to avoid killing everything, the script only kills processes that are running in the configured client folder. So if you used GPU1 for the script, it would only kill processes running from C:\FaH\GPU1. Everything else would be safe.

Copying the starting exe to each folder would work just fine, all you would have to do is change the below line to point to your startup .exe instead of the gpu.exe or whatever it is called.

Code:
$client_name = "fah6.exe" #change client.exe name as appropriate, quotes are required
However, I am not sure why you would need the startup exe at all if you are going to start individual clients using the script. Could you not simply have it point to the client.exe already in the folder?
 
My current theory is the fact I run my GPU clients on SBS 2008. I suspect there is something not playing nice between CUDA, the OS and the client. Stanford are about as much use as a condom machine in the Vatican when it comes to finding the source of these kinds of errors.

There is the case for a hardware problem, but both cards show the same symptoms and they ran fine under Windows XP and 7. They also ran just fine under SBS 2008 for weeks before they started acting up with certain WUs.

You could try to use the FAH_GPU_IDLE environment variable to slow down the GPU a little and see if that helps. This worked for me for a while [which keeps a possible hardware issue niggling]. I would start at 20 and slowly decrease it as low as possible.

You can set the environment variable by going to System Properties and Advanced.
 
Have you monitored what Work Units they are crunching? My errors were with specific WUs. Perhaps you bagged some you can crunch? :)
 
Back
Top Bottom