Deal with inconsistent PWM file locations

[adrfantini]

In my system, the fan to be monitored can be located at: /sys/devices/platform/it87.2624/hwmon/hwmon0/pwm2 or /sys/devices/platform/it87.2624/hwmon/hwmon1/pwm2

This is pretty random, the kernel decides seemingly without any order. How can I be sure that hddfancontrol finds the right fan?

[desbma]

To be sure I understand correctly: you sometimes randomly have a /sys/devices/platform/it87.2624/hwmon/hwmon1/pwm2 file and no /sys/devices/platform/it87.2624/hwmon/hwmon0/pwm2 ?

Or do you have 2 fans and their sysfs order can change after a reboot?

[adrfantini]

Sorry I did not explain the problem clearly. I only have one fan in the system (a small passively cooled NAS), but that is sometimes read as hwmon1 and sometimes as hwmon0. Another fan header is present but not pupulated, and is always pwm1, inside the same hwmon? folders. The it87 module is manually loaded from modprobe.d.

I am not 100% sure that the hwmon number changes from boot to boot, even though some of my early problems with this system seemed to suggest that. I might try to replicate it tonight.

For sure however the naming changes if I boot different kernels, which is quite annoying.

[desbma]

I don't know why the naming changes, you'd have to look at the sysfs kernel code, or to ask a kernel hacker. I am interested if you find the answer though :)

To work around that you can try to run a script like that at boot (as root):

#!/bin/sh
ln -sv /sys/devices/platform/it87.2624/hwmon/hwmon*/ /tmp/hddfancontrol_fan_hwmon

That will create a link at a fixed location to the changing sysfs directory.

And then pass /tmp/hddfancontrol_fan_hwmon/pwm2 as PWM path to hddfancontrol.

[adrfantini]

Yeah, I'd need to make sure the link is done before hddfancontrol starts tho. I'll try to see what is the root cause of this sysfs issue...

[adrfantini]

I created a small systemd service to run the ln before hddfancontrol starts. Still, that's just a workaround... not one that I can see how to fix tho.

[desbma]

I'm closing this then, since the cause is unrelated to hddfancontrol.

[adrfantini]

After the update to the latest version (1.2.9-1 on AUR) my linking method seems to not work. I think it is because of the hardening in the .service file. No fan is controlled, but no error output is created. If I start the program manually, or restart the service, everything works fine and the fan is controlled.

[desbma]

Try to add an exception for the directory to allow writes to, like this:

mkdir -p /etc/systemd/systemd/hddfancontrol.service.d
echo '[Service]
ReadWritePaths=/PATH/TO/THE/LINK/DIRECTORY' > /etc/systemd/systemd/hddfancontrol.service.d/link-write-workaround.conf

And then:

systemctl daemon-reload
systemctl restart hddfancontrol

EDIT: Also don't create the link in /tmp because of the PrivateTmp=true option. Or else, create it with a ExecStartPre=... command inside the service, like this (in this case you can omit ReadWritePaths=/tmp):

[Service]
ExecStartPre=/bin/bash -c 'ln -sv /sys/devices/platform/it87.2624/hwmon/hwmon*/ /tmp/hddfancontrol_fan_hwmon'

[adrfantini]

I initially had it in /tmp, but moved it to /run seeing the PrivateTmp option. I tried setting up After and Before in the services but to no avail.

The /etc/systemd/systemd/hddfancontrol.service.d/link-write-workaround.conf trick did the job. Out of curiosity, why would the ExecStartPre work, where ExecStart fails?

[desbma]

Files in /etc/systemd/systemd/hddfancontrol.service.d allow overriding and/or adding/removing options for the service hddfancontrol.service. If you add ExecStartPre=xxx in there, it is executed inside the mount namespace of the service, so it has access to private /tmp files, unlike any other process outside of the service (including your other service).

I initially hated systemd for its feature bloat, but its declarative configuration system is both powerful and very flexible.

[adrfantini]

Oh, yes, I misunderstood your previous point, I thought you suggested to add ExecStartPre to the service that linked the folders, not as an addon to hddfancontrol. This is indeed a more elegant solution, thanks for the suggestion, I'll implement it.