fahclient_7.6.9 systemd service

[chadek]

trafficstars

On mint 19.3, the init script chipped with fahclient_7.6.9_amd64.deb isn't well integrated with systemd: systemd think fahclient fail to start while it isn't.

To be able to manage fahclient with systemd I wrote a systemd service file based on observation of the init script behaviour and on this thread : https://gist.github.com/lopezpdvn/81397197ffead57c2e98. I also added some parameters to increase security and ensure fahclient have lowest priority possible.

While I was writing this I figured out that sending a SIGUSR1 to fahclient actually stop the service instead of reloading it as expected (according to the reload function inside the init.d/FAHClient script).

I'm not sure if it is really usefull as the pid can be accessed through $MAINPID variable but I assume that fahclient should need it as it run a lot of parallel jobs.

It's a shame source aren't open, I could have dig a bit more on why SIGUSR1 signals kill fahclient instead of reloading and spending less time try to finding it. Anyway it would also be interesting to take a look at it and more specifically to security as it aim to run on a lot of machine. I would be sad to discover that I'm actually computing hashes instead of folding proteins :)

[Unit]
Description=Folding@Home V7 Client
Documentation=https://folding.stanford.edu/home/the-software/
After=syslog.target network.target remote-fs.target

[Service]
Type=simple
User=fahclient
RuntimeDirectory=fahclient
RuntimeDirectoryMode=0755
PIDFile=/run/fahclient/fahclient.pid
WorkingDirectory=/var/lib/fahclient
#--run-as is optional as we already set the user to use inside this service
# --chdir /var/lib/fahclient/ is optional as we already set the workingdir inside this service
ExecStart=/usr/bin/FAHClient /etc/fahclient/config.xml --chdir /var/lib/fahclient/ --pid-file=/run/fahclient/fahclient.pid --run-as fahclient
#Actually not working, sending sigusr1 will stop fahclient instead off reloading config
#ExecReload=/bin/kill -SIGUSR1 $MAINPID 
ExecStop= /bin/kill $MAINPID
KillMode=process
NoNewPrivileges=True
CPUSchedulingPriority=1
ProtectSystem=strict
ProtectKernelTunables=yes
ReadWritePaths=/var/lib/fahclient/ /etc/fahclient/
MemoryDenyWriteExecute=yes

[Install]
WantedBy=multi-user.target

Love the idea of this project, hope it will be fully open oneday: close source to make harder to write exploit is never a good bet.

[ajacocks]

This is definitely worthwhile. I'm doing something similar, in the RPMs that I'm re-rolling:

Description=Folding@Home V7 Client
Documentation=https://folding.stanford.edu/home/the-software/

[Service]
Type=simple
Environment=FAH_CONFIG=/etc/fahclient/config.xml
Environment=FAH_PID_FILE=/var/run/fahclient.pid
Environment=FAH_USER=fahclient
PIDFile=/var/run/fahclient.pid
WorkingDirectory=/var/lib/fahclient
ExecStart=/usr/bin/FAHClient $FAH_CONFIG --run-as $FAH_USER --pid-file=${FAH_PID_FILE} --daemon -v
ExecReload=/bin/kill -SIGUSR1 $MAINPID
ExecStop=/bin/kill $MAINPID
KillMode=process
TimeoutStopSec=60

[Install]
WantedBy=multi-user.target```

[chadek]

Do you know why fahclient stop instead of reloading on a SIGUSR1 ?

[BrainStone]

Since it often "failed" to start with the shipped script, or more precisely failed to properly detect the start of service, I looked into it.

I think the easiest way to fix this is by adding a tiny sleep before starting to check. So this command fixed my start script for me that the detection of the service works reliably:

sed -i '/wait_for_log_change/a \
    sleep 0.1\n' /etc/init.d/FAHClient

All this does is add the command sleep 0.1 (followed by an empty new line) to the wait_for_log_change method in the /etc/init.d/FAHClient script as the first instruction. It's possible that the process that's being detected here is not quite ready immediately after starting when this method is called.

[ScriptInfra]

Is anyone aware of any movement on this issue? I've experienced issues with the /etc/init.d/FAHClient that ships with the rpm not interfacing correctly with the /usr/bin/FAHClient executable. Shipping a functional systemd configuration with the rpm would be a workaround for this issue. Additional information is posted on the forum: https://foldingforum.org/viewtopic.php?f=108&t=36444