FAH core process privilege under systemd

[liminal]

On debian bullseye and bookworm systems both, I've installed the 7.6.21 fahclient as a systemd service, so it can automatically launch at boot time. So far so good- have racked up loads of points on this config.

I've dug through system journal seeing no messages offering clues as to why the explicit "--run-as fahclient" option on invocation has no effect. The core and its parent process always run as root. This is not so much an issue per se, but it strikes me as warped that all those processor core clocks dedicated to folding should run at unnecessary root privilege for no reason obvious to me.

Code: Select all

/usr/bin/FAHClient --child /etc/fahclient/config.xml --run-as fahclient --pid-file=/var/run/fahclient.pid --daemon

Thoughts on where I should be looking for sense making or remedy?

cheers-

[calxalot]

Maybe this helps

viewtopic.php?p=359791#p359791

[toTOW]

I've dug through system journal seeing no messages offering clues as to why the explicit "--run-as fahclient" option on invocation has no effect. The core and its parent process always run as root.

It's a bug introduced in v7.6.21 ...

[liminal]

Thanks for the info . From what I can gather, v8.1 is maybe more hospitable or efficient.

[Joe_H]

I've dug through system journal seeing no messages offering clues as to why the explicit "--run-as fahclient" option on invocation has no effect. The core and its parent process always run as root.

It's a bug introduced in v7.6.21 ...

... or at least somewhere between 7.6.13 and 7.6.21. Complicated by the installer script was originally using init.d, linux distributions started using systemd.

[liminal]

Maybe this reply ought to be a new topic. Suggest a subject line?

I'm considering installing beta 8.1.x client to see if it's more agreeable. It sounds nearly stable enough to end beta test, maybe at least for nonGPU. Something I should know beforehand though: are there critical incompatibilities between the v7 and v8 client, in how they keep the WU queue, or other clash in how they use system resources, config.xml options, /var/lib/fahclient or some such? If I finish a WU on v7, remove fahclient package, install v8 with the same fahclient user home (some residue in home?), will the next WU proceed without a train wreck?

Will the end of the concept of work engine slots be a difficulty? Was it the same developer doing requirements / architecting on both versions? I'm supposing they likely hadn't given much thought to this version upgrade, to consider whether it's something worth easing if possible.

Thanks in advance. o/

[Joe_H]

The V8 client keeps queue and other information in .db files differently than v7. So any WUs in the v7 queue should be finished before installing v8.

At installation time, and at each startup of the background process, the config.xml file from v7 is read. But the working configuration is stored in a client.db file. Many options and such things as username, team ID, and passkey are read from the existing config.xml file, but not all v7 options are applicable to v8. But adding an option to the config.xml file is currently the only way to set some of the advanced/expert options to be used by the v8 client.

Some bugs exist around assigning resources to WUs, CPU or GPU only systems can just work. On large CPU thread count systems such as servers the utilization may not be optimal, pseudo-slots can be created if needed.

As for development, the same developer has worked on both v7 and v8. Over 11 years ago the first public Beta, v.7.1.52 was released. It was done as a closed source app, converting it to open source was done starting about 2 years before COVID. That got as far as some components being open source, you can find them on GitHub. But except for some bug fixes and adding the COVID preference that is about as far as development on v7 went. During COVID the developer was given directions to focus on server code improvements and deployment. v8 is based on being open source from the beginning. That is one of the requirements set by the F@h leadership who are paying him. Another requirement is support for possible future use of both CPU and GPU resources while processing a single WU. That is an option in both the OpenMM and GROMACS code that Core_22 and Core_A8 are based on. Whether that makes it into production depends on how things go in testing, but v7 does not have support for that.

As for easing into this as a version upgrade, as mentioned v8 can inherit some information from the v7 install. But it is a Beta. I haven't seen any showstoppers recently, but some of the early versions had problems. The v8.0.x client didn't even make it out of internal testing, but needed fixes identified by that did make it into v8.1.x releases. Some of the advanced users are not ready to move to it as support for external monitoring solutions such as HFM.net and 3rd party apps is not yet available. Problems or feature requests can be posted on the GitHub for the client.