Service unit target

[qouoq]

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 to multi-user.target with a drop-in file.
I'm running Xorg with startx, no display manager, on Arch with the default graphical.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 that daemon-reload won't apply WantedBy 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 after display-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:

• most services use 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 into multi-user.target would then not get the service, but also in this situation, the default fan control is likely to be enough;
• for a user who needs amdfan to take control even later, either they'd need to define a custom systemd target that runs last (along these lines: https://superuser.com/a/1543365/308970, but after graphical.target rather than after multi-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).

[mcgillij]

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.