Issue when restarting FAH on Linux

[CaptainHalon]

I have two Linux boxes folding: one setup to autostart on boot, the other setup for manual start. In retrospect I wish I had installed them both for manual start, but I don't want to go down any rabbit holes trying to change that It's not a big deal, but I have an issue with the autostart box that I don't have with the manual start box.

On the manual box, if I kill the FAHClient process and restart it, the work picks back up where it left off. But if I do the same on the autostart box, it essentially discards all the work progress and starts over with new work units. I don't understand why. I reference the exact same config file when restarting the FAHClient process.

This is not something I do often so it's not terribly important. Just more of a curiosity.

[bruce]

Post the segment of the restart showing the work being discarded. Be sure to include the beginning of the log, too.

[CaptainHalon]

This has not been a good day for smooth operations on that box. So short story, long:

After Ubuntu wanted to install updates, I could no longer connect via RDP. I tried to remedy this by a few things including complete removal of xrdp with the --purge option and reinstallation. That didn't work so I reinstalled 20.10 (which I was initially running as an upgraded 20.04). After several failed attempts on the fresh installation to get rdp to connect, I resigned myself to install 20.04. Once I did this, rdp worked again. So that was one rather frustrating problem solved, even though the exact cause of the problem remains a mystery.

After verifying that RDP worked, I proceeded to install FAH again. I tried initially through the Ubuntu software store. Unfortunately, it gave me no option to manually start the client (I was given this option when I installed fah on my other folding box, which runs mint). Moreover, it would not recognize my config.xml file in either ~/.FAHClient or in /etc/fahclient, both of which I've seen fah use in linux before. At this point, I decided to remove that particular installation and I used the debian fah files that I used previously to install everything on mint. Again, no option for manual installation. So I disabled the service and copied over my scripts from my mint box. At this point, I noticed the client would read the config file I placed in /etc/fahclient, but it wouldn't save anything to it. I tried changing owner and group from root to my user account, but this did not help either. I had to manually edit any changes I wanted in the xml file. I noticed in the logs, it kept trying to copy said xml file to some other directory I had not heard of, but was giving an error that permission was denied.

To top it off, when I log out of the box locally while fah is running and then reconnect via rdp, all my fah processes are dead and I have to restart them. I don't have this issue with my mint box for some reason, which at this point had my wondering to myself why I didn't just install mint on this box as well.

So in conclusion, after two complete OS reinstallations, I have things semi-working again, but I'm afraid the log files you requested no longer exist I can file the problem in my initial question as one other mystery I didn't solve. I can also conclude that I suck at linux, and if it didn't give much better ppd than Windows 10, I'd probably just switch back.

...but the box is folding again after being down for multiple hours, so that's a plus

[bruce]

I consider this a bug in RDP. when you connect using RDP, Microsoft replaces the screen driver with an alternate driver which blocks the GPU from folding. Using an alternate method of connecting seems to work.

[CaptainHalon]

I used to use Teamviewer a long time ago for managing linux boxes, but I got used to RDP when I was running windows only. I'll stick with it if it doesn't give me any more trouble. Seems to work OK right now.

I did figure out the cause of my initial problem, though, with discarding the work. It actually wasn't discarded as I just found out. When I was running fah manually, I was running /usr/bin/FAHClient as my standard user account. When it runs as a system service, it's running /etc/init.d/FAHClient as root. I had no idea the binary was in two different locations, but I'm guessing it's the fact that running it as two different users causes it to pull separate work units, even though it's using the same GPU's.

[bruce]

Yes, it was running as two different users in two different local directories and competing for CUDA or OpenCL resources on designated GPUs.

The Linux installation process is supposed to create a new user 'fahclient' with semi-restricted permissions and run the daemon as that user rather than run as root. The 'cwd' command is supposed to precede the invocation of the FAHClient executable so all the working files are contained and can be uninstalled properly when the time comes.

Getting the installer to work on individual Linux versions often creates exceptions to the above policy.