Open qouoq opened 11 months ago
You got it, it depends on how early the amdgpu
module is loaded by the kernel (which is what makes the /proc /sys entries that are used).
There are directions on the archwiki on how to get it loaded earlier etc.
I can look into having it load with udev, but like anything else I'd like to keep it as generic as possible since there doesn't seem to be any config that would hit every use-case as people have different systemd configs, kernel module load times etc.
The systemd.service
file is just there for people that want to use it, I can remove it and specify that users can add their own startup processes where they see fit, but I suspect that would probably cause more issues.
Feel free to submit a PR with an alternate startup and we can review it and test it.
I just understood that the amdfan service was not starting at boot on my computer because it's
WantedBy=final.target
. It works as expected if I adjust the target tomulti-user.target
with a drop-in file. I'm running Xorg with startx, no display manager, on Arch with the defaultgraphical.target
.I see there's a similar discussion in pull request #22. As mentioned there,
final.target
seems to be invoked at shutdown only (see also https://github.com/systemd/systemd/blob/main/units/final.target). I don't see how the service can work for some with that target? (Possibly because the service was not reenabled, so there's a lingering symlink in some other target? It's a slightly confusing behavior in systemd thatdaemon-reload
won't applyWantedBy
changes, nor will rebooting, one needs to reenable the unit to clean up and re-create the symlinks.)Possibly for the use-case adressed by that pull request,
graphical.target
would work, since it runs afterdisplay-manager.service
? (https://github.com/systemd/systemd/blob/main/units/graphical.target)-- edit: giving more thoughts about the targets, while I'm far from being well-versed in the topic, I feel the following makes sense:
multi-user.target
. However, it's certainly possible that some GPU-related programs would "steal" the control of the fan from amdfan later on in the boot process;graphical.target
seems a natural choice for this service, attempting to run as late as possible in the boot process. A user booting intomulti-user.target
would then not get the service, but also in this situation, the default fan control is likely to be enough;graphical.target
rather than aftermulti-user.target
), or somehow defer amdfan startup by means other than systemd.Just some thoughts really, finding the best time to take control of the fan is undoubtedly a complicated exercise..
-- edit 2: Just talked about this on #archlinux IRC, it might not be related to other services taking control over the fan, but rather on relevant /proc entries not being populated yet. To which a possible solution would be to trigger amdfan startup by udev, rather than using a systemd service (see https://unix.stackexchange.com/questions/730342/how-to-run-udev-rule-before-a-certain-module-loads for a starting point).