Folding Forum

Good day all.

I'm (mostly) a debian-based (buster 10.2 now) folding work unit donor of years standing, thousands of units returned for substantial total score. Client 7.5.1 runs as a system service ofc, so there need be no interactive login for folding work units to launch and progress once system boots -- providing internet feed is live when required. My search for resolution or alternate means in docs and forums makes my google fu appear inadequate.

The difficulty is administrative: in order to have backups/snapshots as useful as possible, of the file system hosting the folding work queue, client must stop between WUs for snapshot, empty of ephemera, making restoring from snapshot later not disruptive. So, ability to finish the active unit without downloading a new WU assignment is necessary, not just wish list. It's not sensible having to manually time network connection so as to allow upload of finished WU results while defeating download attempts, which are very quick for a single unit assignment.

Unfortunately, the web control page (localhost:7396) Stop button, followed by "Finish up, then stop", is effectively ignored by FAH client. It's been so for years, perhaps only on debian based installations. By contrast, Stop Now behaves as expected. This bug remains unresolved or untracked even, as far as I can tell, and this would be not much trouble if only there were simple direct alternate means to bring about the same effect.

Access to protocol docs for telnet connection to client eludes me. Purposely I haven't pursued ugly hacks to make fah-control package install on buster, they're plainly not worth the grief. Though whatever that interface is doing to communicate to the client, informing it to disable download of next WU when progress reaches near-finished, that's something one should in principle be able to do directly from the terminal, with only ordinary system utilities? Not even needing a telnet session at port 36330? a certain signal sent to the client via kill?

Advice / perspective appreciated. Thanks for the timely attention-

FAHControl communicates with FAHClient using the equivalent of the telnet interface, which means that there is SOMETHING that allows the FINISH command to function. Setting the FINISH state will do what you want (and it's easy to set using FAHControl). Somebody will have to figure out how to do that if you don't run FAHControl.

Once FINISH is set, the current WU will proceed to 100% and then upload the results but will not download a new WU. Unfortunately it will (probably) delete the work files, so you'll have to figure out how to capture them if that's what you need.

You're right. This feature request has not made it into FAH lists of tracked issues. Open a ticket at https://github.com/FoldingAtHome/fah-issues.
Unfortunately enhancements like this take a lower priority that genuine bugs, so you you'll need to to carefully justify why this is a critical need.

Thanks for the response. Nothing unfortunate in wiping completed WU files, that was the point of stopping between units, to make a snapshot free of queue ephemera that'd clog the works if restored. Sorting out telnet protocol & FINISH without documentation or working command line help was not so hard as expected. Alt means available. Trouble resolved.

liminal wrote:Sorting out telnet protocol & FINISH without documentation or working command line help was not so hard as expected. Alt means available. Trouble resolved.

Care to share your result in case someone else would like to do it?

parkut wrote:Care to share your result in case someone else would like to do it?

Pardon the delay, but it's embarrassingly trivial: voila: exit brings you back from the telnet to your shell. Incidentally, someone finally built an update of the fahcontrol package that works on debian buster, so I don't have to rely on this any more.

wait, debian buster? I had trouble installing fahcontrol b/c of python 2 dependencies. How did you overcome?

Knish wrote:wait, debian buster? I had trouble installing fahcontrol b/c of python 2 dependencies. How did you overcome?

The reference is to a build of FAHControl that was recoded to use Python 3. Several people worked on forks of the code and converted the Python 2 code to be compatible with Python 3. I have not looked to see if there is an accepted fork on the GitHub site, but eventually a version that removes the dependency should be released with a later version of the client.

In the meantime some have downloaded and used these versions of FAHControl.

FYI, you're using a rather old version of FAHClient, V7.5.1 while the latest version V7.6.21 works fine as the bug in Web Control was fixed in V7.6.14: viewtopic.php?f=108&t=36307 If possible, you could consider doing an upgrade?