But maybe the errors are happening before suspend and systemd isn't reporting them until after. Then I suspended for long enough to tell the difference between timestamps before and after suspend, and found that systemd reports the errors happening after resume from suspend, not before suspend. Turns out CheckFiles doesn't even check for writeability, only readability I added some code to check for writeability and CheckFiles still succeeds in its checks. I was expecting it to tell me something like the file handle is not writeable. I tried running the CheckFIles function immediately before the line that crashed. I guessed the problem had something to do with the kernel not making the file handles for the fans writable soon enough after resume from suspend. TL DR there is an error writing to the file the kernel creates for controlling fan speed, but that file exists and bash reports it as writeable just before writing to it. DEBUG=1 on line 47 of fancontrol) What is actually causing the problem?

usr/sbin/fancontrol: line 610: echo: write error: Invalid argumentĮrror writing PWM value to /sys/class/hwmon/hwmon1/pwm1įrvice: Main process exited, code=exited, status=1/FAILUREįrvice: Failed with result 'exit-code'. Checking the logs for fancontrol ( journalctl -u rvice) I find this message After crashing, fans behave the way they are set in UEFI/BIOS, not the way they were set with fancontrol (determined by audio inspection). The problem is reproducible by starting fancontrol ( systemctl start rvice) then suspending my computer. Original Issue Report OS / Environmentįancontrol works, but crashes when the computer is suspended. Such a change has potential to fix this whole situation, as systemd is involved in the process of suspending, and might magically wait the right amount of time before letting fancontrol run. Also it seems to me like fancontrol could be a systemd timer service rather than a systemd simple service like this.

As a quick, hacky fix, I added Restart=always to my rvice, and it restarts after failing related to suspend (though that's not a great default behavior and I don't think it should be shipped that way). If it is a kernel bug, shouldn't we report it? and if it isn't, is some investigation in order? (I would be happy to do that investigation).įurthermore, regardless of if it is a kernel bug or not, I think we can work around it with systemd. But first, I'm a tad disappointed that the response is 'its a kernel bug'. I had this same problem and was in the middle of writing an issue for it when I found this thread.

How to reset hwinfo fan control