Page 1 of 1
My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Sun May 04, 2025 1:53 pm
by 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?
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Sun May 04, 2025 2:45 pm
by 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
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Sun May 04, 2025 2:46 pm
by 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.
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Sun May 04, 2025 2:47 pm
by muziqaz
This is not nVidia exclusive. This is OS issue
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Sun May 04, 2025 5:12 pm
by Marcos FRM
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Sun May 04, 2025 10:32 pm
by 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 ...
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Mon May 05, 2025 2:10 pm
by 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.
Re: My client cannot detect the GPU after reboot, and I need to manually restart the client
Posted: Mon May 05, 2025 5:34 pm
by 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.