Folding Forum

Hi folks,

I recently updated to the latest v7.6.21 of Folding@Home, running on CentOS 8.x. Post-upgrade, running './FAHClient status' and './FAHClient stop' do not function. After some investigation, it appears the PID file defined in the logic is not being created on startup of FAH (--pid-file=/var/run/fahclient.pid), which I believe to be causing the 'status' and 'stop' flags to ultimately fail, since it is not seeing the PID. Running the command './FAHClient start' does in fact work; however, if I need to cycle or stop the process for any reason, it must be killed at the OS level.

A few things I have tried:

1. Providing ample privs on /var/run/
2. Removed the rpm and reinstalled F@H
3. Rebooted the system

I was hoping someone has run into this issue before, or would be able to provide any input on the issue.

Thanks!

viewtopic.php?f=108&t=36200#p344141

That post contains my advice for installing and running FAHClient on RPM-based distros. Essentially, explicitly creating a systemd unit to override the behavior of the init.d script solves numerous client issues.

Appreciate the feedback, Whompithian! At first glance, I think this may ultimately resolve my issue, if I move to systemd for the service based off your link.

My understanding is that /usr/bin/FAHClient is not open source, so I have had some challenges debugging it. Before your post, I made some minor logic changes to /etc/init.d/FAHClient in order to work around the fact that the PID file is not being created when /usr/bin/FAHClient is run. It seems like the /etc/init.d/FAHClient logic does not necessarily align with the code in /usr/bin/FAHClient if it is not properly able to manage the executable. Perhaps updates were made to /usr/bin/FAHClient without taking into consideration the implications on the /etc/init.d/FAHClient logic; however, it is challenging to track down root cause without knowing the code behind /usr/bin/FAHClient.

Thanks again!

I also noticed that the pid file feature stopped working after 7.6.13, but I could use process name matching instead which is currently good enough. It seems to be a regression error, though, since I can't think of any reason why removing that (documented) feature would be intentional.

Just my thoughts,
HG.

Hopfgeist, could you expand on the 'name matching' work flow for my understanding? I'm curious what you mean by this.

Thanks!

Hopfgeist - That's funny, I was looking in my F@H install directory, and had the v7.6.13 rpm sitting there, so it would seen as if something has changed since that version.

Andrew wrote:Hopfgeist, could you expand on the 'name matching' work flow for my understanding? I'm curious what you mean by this.

Thanks!

I use monit to monitor my FAH Client, restart it if crashes or at system boot, etc. I used to use the pid file for that, which is preferable, because it is guaranteed unique, but now I just have monit look at the process names to find the correct task. That may fail if another task is also called "FAHClient", but that is so rare that I don't worry about it.

The monit website looks very flashy, but the monitoring tool itself is free and open source and there are packages for most unix/Linux systems.

Process name matching is also the only way to watch for an actual calculation core (FahCore_a7, or FahCore_a8), because that has never created a pid file.

Many unix-like operating systems have "pgrep" and "pkill" command-line tools to find (and signal or kill) a process by its name, instead of the process id, which can be used in shell-scripts.

I hope that clears it up, but just ask if you any more questions.

My workflow is very specific to my system, but I can share my monit setup (for NetBSD) if you like.

Cheers,
HG.

I confirm that FAHClient 7.6.21 for Linux stopped creating a PID file. Before, it was created by the binary rather than the init script. I can't detect any change in behaviour when using any of the options 'pid' or 'pidfile'.

It looks like a regression to me.

I think adding a line to the /etc/init.d/FAHClient script might work. But I still hope they could fix it. (Plus make it open source )

Also be careful : on Ubuntu distribution, older FAHClient used to run under a dedicated account, but the latest one (7.6.21) is now running as root ... it broke all the stop features (init.d, service, systemctl) ...

I'm running FAHclient version 7.6.21 on Ubuntu with the custom systemd startup script, and using that it still runs as the user "fahclient". GPU folding also works by using that startup-script rather than the included init.d script.

davidhcefx wrote: ↑Sat Sep 18, 2021 4:31 pm I think adding a line to the /etc/init.d/FAHClient script might work. But I still hope they could fix it. (Plus make it open source )

Code: Select all

@@ -121,6 +121,7 @@ start() {
     fi
 
     pid=$!
+    echo $pid > $PID
     if wait_for_log_change "$LOG_STATUS" $pid; then
         echo "OK"
     else

Thank-you - that does indeed work on Ubuntu 22.04 LTS Desktop. I was getting tired of having to executeso when I upgraded from 18.04 LTS to 22.04 I did a little digging and found this post.