Fancontrol service doesn't start at boot but runs on manual request

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'.```

Hi!
You can try enable first, then start

sudo systemctl enable fancontrol.service
sudo systemctl start fancontrol.services

Also you can try to run sensors in the terminal and check the temps

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

[Edits: Layout]

Hey folks, I got it working.

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.

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

Note from @xabbu:

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.

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

  2. Change the last line from WantedBy=multi-user.target to WantedBy=default.target

  3. 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
1 Like

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.

2 Likes

@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!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.