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).