FAHClient.service reports failure to start but it is actually running

[praneetloke]

I am running the latest version of the client (v7.6.13 at the time of this writing) on Ubuntu. I didn't have any issues with v7.6.11. But it seems that the service incorrectly thinks it failed to start the client when it actually did start the client just fine. I think there is something wrong in the way /etc/init.d/FAHClient checks for the PID in the process. I modified start to simply call wait_for_log_change $pid instead of conditionally returning a non-zero exit code to get me past this.

EDIT: After I made my changes I did connect to the client remotely to verify that it is indeed running WUs.

[shorttack]

Please note that we tend to use GitHub for development issues that are reproducible. For troubleshooting, heading over to the Official Forum is the best option: https://foldingforum.org/index.php where there are lots of Donors who are happy to help out :)

Since this isn't an issue, I will close this for now.

[praneetloke]

Thanks for the response. The description of the repository is misleading. Perhaps worth updating it, as well as adding an issue template to direct people to the forums rather than post here. It wasn't clear to me.

[shorttack]

@PantherX As we were discussing the need ...

[praneetloke]

Posting here in case someone comes here with the same issue. I found that someone already posted on the forum about the same problem here. It seems that this may be a bug after all. I, too, had to make some modifications to prevent the fahclient.service from incorrectly reporting that the startup failed.

[shorttack]

This looks like a defect and issue is re-opened.

[ghost]

Same thing here when installed on a system with Debian Buster. Furthermore, the systemd-scripts seems to be broken as trying to start/stop always throws that error. However, starting and stopping via init.d works.

[IzzySoft]

This seems actually easy to fix. Problem is it backgrounds a process and checks for it too fast, before it got started – which makes the init script returning 1, which in turn makes the systemd unit assume failure, while a second later the process is running.

In /etc/init.d/FAHClient before line 125 which reads

if wait_for_log_change "$LOG_STATUS" $pid; then

simply inserting a line saying

sleep 1

fixed that for me on a Debian system (note you'll have to run systemctl daemon-reload afterwards so systemd rebuilds the unit). Still have to verify on my Linux Mint machines. Can others confirm that on their systems?

PS: Just found another confirmation in this comment, which used the same approach just with a smaller sleep 0.1. Maybe adding it inside wait_for_log_change before line 71 (while [ "$(log_status)" == "$1" ]; do) would be the better place even.

[alaunay]

Hello,

I have the same problem on 3 basic, simple Debian Buster installs. The proposed "fix" in https://github.com/FoldingAtHome/fah-issues/issues/1471#issuecomment-628932631 with adding a sleep 1 on line 124 does the trick.

[tephyr]

Neither of the fixes (adding sleep 1 to line 124, or modifying the wait_for_log_change while loop) works. /var/run/fahclient.pid is never written.