My client cannot detect the GPU after reboot, and I need to manually restart the client

[fangfufu]

I have fah-client 8.4.9 installed on Debian Bookworms. I can confirm that fah-client had been added to the "render" group. I noticed that after rebooting my machine, fah-client doesn't automatically restart folding on my GPU. I have to restart fah-client service manually, then it would notice that the GPUs are there and restart folding. Is there a fix for this?

[muziqaz]

No fix. This has been observed already. Newer distro versions changed something in their service loading sequences that fah-client loads before any libraries are loaded or something. This is not an issue with older distros.
Developer is on a sabbatical, so not sure when we get to add a workaround for this. Until then, manually restarting fah-client after system reboot is the only solution. People with more knowledge can create a script which executes upon system restart to automatically restart fah-client. Or simply delay fah-client start for like 10-20s after system booted

[fangfufu]

Well, I do wonder if it would help if I put the nvidia modules in /etc/modules. But I can't be bothered to test. I am okay to restart the service after reboot - I don't restart my computer all that often.

[muziqaz]

This is not nVidia exclusive. This is OS issue

[Marcos FRM]

I had some ideas to try debugging this issue:

https://github.com/FoldingAtHome/fah-cl ... 2627040201 (last paragraph)

https://github.com/FoldingAtHome/fah-cl ... 2807120590

If you can test them, you're welcome to.

[toTOW]

You could try to delay service start to the end of the OS startup ... the only hard part will to find which service dependencies will allow this ...

[wesgeorge]

/lib/systemd/system/fah-client.service currently lists

Code: Select all

After=network.target nss-lookup.target
WantedBy=multi-user.target

I was looking at logs to try to figure out the race condition, saw this:

Code: Select all

-- Boot f99ecd5cd53542eabfb6e776bad81f18 --
May 05 09:01:17 deathstar systemd[1]: Started fah-client.service - Folding@home Client.
May 05 09:01:21 deathstar systemd[1]: Reached target graphical.target - Graphical Interface.

wes@deathstar:~$ sudo systemctl status graphical.target
● graphical.target - Graphical Interface
     Loaded: loaded (/lib/systemd/system/graphical.target; static)
     Active: active since Mon 2025-05-05 09:01:21 EDT; 35min ago

I thought perhaps I could add graphical.target to the After list, since this seems like a reliable indicator that the GPU drivers are fully loaded, but that just caused:

Code: Select all

May 05 09:47:06 deathstar systemd[1]: multi-user.target: Job fah-client.service/start deleted to break ordering cycle starting with multi-user.target/start
May 05 09:47:06 deathstar systemd[1]: Queued start job for default target graphical.target.

and

Code: Select all

wes@deathstar:~$ sudo systemctl status fah-client
○ fah-client.service - Folding@home Client
     Loaded: loaded (/lib/systemd/system/fah-client.service; enabled; preset: enabled)
     Active: inactive (dead)

But I'm not familiar enough with systemd dependencies to know if I've done that correctly.

[Marcos FRM]

The difference is that if we order after graphical.target, the practical effect is ordering the service after display-manager.service, implemented by GDM, SDDM, etc. Display managers usually do at least one additional thing: wait for the CanGraphical property of systemd-logind to become true. Consequently, I believe it's better to replicate this in the client code, as I suggested in the second link above. Ordering after graphical.target would be pointless in text-only installations because there's no display manager.