Hi so I have the fancontrol systemd service activated and ran pwmconfig several times and followed the advice on the Arch wiki but no luck.
I have my fans linked to GPU temps, which might be where the problem is coming from, and I’m using the manual path (work around on the Arch Wiki)
It works fine when manually activate either via sudo fancontrol or sudo systemctl start fancontrol.service but won’t activate during boot.
I wasn’t sure if this is a Arch problem or a Manjaro problem and since I’m using Manjaro and the Arch forum said it wasn’t a place for Manjaro users I thought I’d ask here first, but if you think this is better suited for Arch then please let me know.
The obligatory logs:
systemctl status:
Loaded: loaded (/usr/lib/systemd/system/fancontrol.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2020-08-29 00:01:05 BST; 29s ago
Process: 568 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE)
Main PID: 568 (code=exited, status=1/FAILURE)
Aug 29 00:01:05 cobalt fancontrol[568]: AVERAGE=1
Aug 29 00:01:05 cobalt fancontrol[568]: Error: file /sys/devices/pci0000:00/0000:00:03.1/0000:29:00.0/hwmon/[[:print:]]*/temp1_input doesn't exist
Aug 29 00:01:05 cobalt fancontrol[568]: Error: file /sys/devices/pci0000:00/0000:00:03.1/0000:29:00.0/hwmon/[[:print:]]*/temp1_input doesn't exist
Aug 29 00:01:05 cobalt fancontrol[568]: Error: file /sys/devices/pci0000:00/0000:00:03.1/0000:29:00.0/hwmon/[[:print:]]*/temp1_input doesn't exist
Aug 29 00:01:05 cobalt fancontrol[568]: Error: file /sys/devices/pci0000:00/0000:00:03.1/0000:29:00.0/hwmon/[[:print:]]*/temp1_input doesn't exist
Aug 29 00:01:05 cobalt fancontrol[568]: At least one referenced file is missing. Either some required kernel
Aug 29 00:01:05 cobalt fancontrol[568]: modules haven't been loaded, or your configuration file is outdated.
Aug 29 00:01:05 cobalt fancontrol[568]: In the latter case, you should run pwmconfig again.
Aug 29 00:01:05 cobalt systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE
Aug 29 00:01:05 cobalt systemd[1]: fancontrol.service: Failed with result 'exit-code'.```
I had kind of the same issue with mbpfan.service The service seemed to be started to early and could not work because some modules seemed to be unavailable when the service was starting. I did not really investigate and just changed the target in the service unit to be started later.
I changed to multi-user.target instead of the one defined by default (i don’t remember exactly sysinit i think)
@visone
Thanks for the suggestion. I checked, and I had already enabled fancontrol.service. It doesn’t appear that it works during bootstrapping, but when I run the start when I get into KDE or even when I get a command line it works fine. After some investigation, I have a suspicion that it is trying to load fan control before lm_sensors which would obviously cause this to not work, similar to what @scachemaille said. I checked what the wanted by line was for fancontrol as well as lm_senors and it was multi-user.target. Perhaps I could bump up lm_sensors and see if that works? If anyone knows a way to list the units systemd loads in the order that they are loaded in, that would be greatly appreciated in my troubleshooting efforts
To preface the solution, I’m not entirely sure if this is due to a race condition or just systemd being dumb, but it seemed that it was trying to load fancontrol before lm_sensors had loaded all the sensors causing my fan control to be unable to see the hwmon for my GPU (since I have my fans set to spin with the GPU).
For anyone else having an issue with this, here is the solution.
Open (as superuser) the file /usr/lib/systemd/system/fancontrol.service with your favourite text editor (for me, that’s VIM but for you that might be nano, emacs or whatever you use. You know you).
It is usually better to copy the changed service file to /etc/systemd/system . Because service files in that folder get priority over other service files with the same name. The service files in /usr/lib/systemd/system/ usually get overridden with updates without any notice.
Add the line After=default.target below the line ConditionFileNotEmpty=/etc/fancontrol (for me, I inserted onto line 3, but it could be different for you)
Change the last line from WantedBy=multi-user.target to WantedBy=default.target
Re-enable fancontrol with sudo systemctl reenable fancontrol.service
Hope this helps whoever else may be stuck on this!
P.S. For reference, my finished fancontrol.service:
Description=Start fan control, if configured
ConditionFileNotEmpty=/etc/fancontrol
After=default.target
[Service]
Type=simple
PIDFile=/var/run/fancontrol.pid
ExecStart=/usr/sbin/fancontrol
[Install]
WantedBy=default.target
All systemd services that are enabled are started simultaneously. But a service can have dependencies, that forces a service to wait for a different service to be started. There are different types of options that can be used to create a dependencies and a fixed start order.
For example Requires=, Wants= or Before=, After=
Sometimes a little ExecStartPre=/usr/bin/sleep 5 also works.
A good overview in which order the services are started form the current boot is the plot function of systemd-analyze.
systemd-analyze plot > plot.svg
But might changes form boot to boot. Specially if your system boots quite fast.
Just one note to your step 1. It is usually better to copy the changed service file to /etc/systemd/system . Because service files in that folder get priority over other service files with the same name. The service files in /usr/lib/systemd/system/ usually get overridden with updates without any notice.
@xabbu
Thanks for the suggestions and improvements. I will update the solution to reflect this. Also: I had set the Requires and After, but it seemed to ignore it. It still ran fancontrol.service before lm_sensors.service even though I put Requires=lm_sensors.service and After=lm_sensors.service. IDK what was up with that, but for now my system is doing what I want it to do (which is why I moved to Linux in the first place, I decide what I want). If I have to re-do the service after updates then I can live with that. Thanks for the comment!