services: thinkfan: run with realtime priority

[spikespaz]

I consider this process a critical part of the system software stack and as such want it to be responsive to sensor readings.

This reflects vmatare/thinkfan#198, which has not been merged.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[paepckehh]

Just my personal view (thinkpad user here, not a hardware engineer):

Im not sure if the upstream analysis, that a delayed fan response leads to a system crash, is reproducible with almost any current hardware. AMD and Intel have both measures to suppress this by slow down at hardware rate level - even a rt scheduler process or physical fan / pwm can not respond in any way. (categories apart!)

But there is a good point in there!
Protect this process systemd side from:

• getting into swap (could led to many ns or even some ms delays under pressure) [MemorySwapMax=0]
• getting killed by OOM [OOMScoreAdjust=1000]

could avoid pointless slowdown of a system under pressure.

Currently we have a even a systemd 30s blackout after an internal error or OOM kills the process:

• Restart = "on-failure";
• RestartSec = "30s";

A 30second downtime is a category that could indeed lead to some problems.
I'm not sure if the (security sensitive) real-time integration (nanosecond response) does help!?

Maybe some linux kernel specialist can jump in here?
Maybe I'm totally wrong here. For me pwm response times and cpu-rt are totally different worlds.

At least, Im very curious how upstream expertise will proceed 👍

[spikespaz]

@paepckehh I have incorporated your suggestions with comments.

According to the manpages, I believe you meant OOMScoreAdjust = -1000.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2423