/etc/init.d/FAHClient not creating PID file on start

[Andrew]

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!

[Whompithian]

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.

[Andrew]

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!

[Hopfgeist]

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.

[Andrew]

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

Thanks!

[Andrew]

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.

[Hopfgeist]

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.

[berny156]

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.

[davidhcefx]

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

[toTOW]

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) ...

[gunnarre]

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.

[gordonbb]

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 execute

Code: Select all

killall FAHClient

so when I upgraded from 18.04 LTS to 22.04 I did a little digging and found this post.