systemd: Run lm-sensors after modprobe

Question

I have a Gigabyte X570 GAMING X motherboard and want to control the fans from my XUbuntu 24.04, but it has issues detecting the fans. There is a suggested solution, but modprobe it87 force_id=0x8628 only works on the console (I don't want to use dkms). Now I want this to work directly after a reboot.

So I now have:

root@runlikehell:~# cat /etc/modprobe.d/fans.conf 
options it87 force_id=0x8628

root@runlikehell:~# 

and added these to the "[Unit]"-section in /usr/lib/systemd/system/lm-sensors.service:

Requires=systemd-modules-load.service
After=systemd-modules-load.service

Note that I asked AI and it halucinates as it suggests this:

After=modprobe@*.service
Wants=modprobe@*.service

but systemd doesn't allow wildcards there.

After a reboot I see this, so the conf-file was loaded:

root@runlikehell:~# modprobe -c | grep it87
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
blacklist it8712f_wdt
blacklist it87_wdt
options it87 force_id=0x8628
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*AB350*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*AX370*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*B550AORUSPROAC*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*TRX40AORUSXTREME*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570AORUSMASTER*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570AORUSPRO*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570AORUSPROWIFI*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570SAEROG*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z390AORUSULTRA_CF*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z690AORUSPRO*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z690AORUSPRODDR4*: it87
alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z97X_GamingG1*: it87
alias dmi*:rvn*nVIDIA*:rn*FN68PT*: it87
root@runlikehell:~# 

The lm-sensors.service is running, but it didn't find the it87-related stuff:

root@runlikehell:~# journalctl -b 0 -u lm-sensors.service 
... systemd[1]: Starting lm-sensors.service - Initialize hardware monitoring sensors...
... sensors[1334]: k10temp-pci-00c3
... sensors[1334]: Adapter: PCI adapter
... sensors[1334]: Tctl:         +48.4°C
... sensors[1334]: Tccd1:        +56.5°C
... sensors[1334]: acpitz-acpi-0
... sensors[1334]: Adapter: ACPI interface
... sensors[1334]: temp1:        +16.8°C
... sensors[1334]: temp2:        +16.8°C
... sensors[1334]: temp3:        +16.8°C
... sensors[1334]: gigabyte_wmi-virtual-0
... sensors[1334]: Adapter: Virtual device
... sensors[1334]: temp1:        +25.0°C
... sensors[1334]: temp2:        +26.0°C
... sensors[1334]: temp3:        +48.0°C
... sensors[1334]: temp4:        +26.0°C
... sensors[1334]: temp5:        +28.0°C
... sensors[1334]: temp6:        +39.0°C
... sensors[1334]: nvme-pci-0300
... sensors[1334]: Adapter: PCI adapter
... sensors[1334]: Composite:    +40.9°C  (low  =  -0.1°C, high = +74.8°C)
... sensors[1334]:                        (crit = +79.8°C)
... systemd[1]: Finished lm-sensors.service - Initialize hardware monitoring sensors.
root@runlikehell:~# 

So to me it means that the configuration of modprobe hasn't been read or applied when lm-sensors.service starts.

journalctl -b 0 doesn't contain "it87" at all (I don't know if it should).

How do I run the lm-sensors.service after the modprobe-stuff properly?

Answer 1

systemd-modules-load.service is only responsible for static module loading, i.e. what is manually listed in /etc/modules-load.d (linked to /etc/modules in some distributions).

The same goes for [email protected], which is only instantiated for a few statically-defined modules – a more fine-grained equivalent of systemd-modules-load.service – and not for each and every module in general. Dynamic module loading happens entirely inside udev, without invoking [email protected] nor indeed /bin/modprobe at all – although modprobe.d configuration will still be honored.

But wildcards don't make sense there regardless, because you want it to apply to a specific module anyway, so if [email protected] were in use, then why would you not specify the name that you already know? As in "After=modprobe@it87"?

Back to the point – Normally udev will load modules for each device as it incrementally receives kernel events. There is no set point where it is "done" – the closest is "done with the initial queue of 'coldplugged' devices" (systemd-udev-settle.service), but it is generally recommended to use something more fine-grained instead.

The entire design of systemd is about precise dependencies, so the recommended way would be After=sys-class-whatever-*****.device – the virtual .device units become "active" when udev is done with them, i.e. the device is definitely available at that point. This might take some setup though as systemd only pays attention to those devices which udev rules have tagged TAG+="systemd".

Alternatively, you could try Requires= and After= [email protected] specifically. But this returns as soon as the module has been loaded – which is not the same as when the module has probed its devices; it's possible that the dependency would be satisfied (i.e. 'modprobe' has exited) while the devices are still being initialized.