crash on sensor file read error

[qbe]

I recently noticed that on my machine, for some reason, some of the sensor files get removed and / or renamed on reboot and / or update. That in itself would neither be tragic not the fault of thinkfan, but the thinkfan service crashes as soon as it fails to read one of the sensors in its configuration.

I propose a more graceful handling of sensor file read errors, either ignoring (and warning about) unreadable sensors, or possibly a way of specifying alternate names for sensors, or some combination of both.

[qbe]

some ideas about warning behavior on sensor read fails:

• to avoid flooding the journal, warnings should only be issued when a specific sensor encounters its first read error (and is removed from the active sensors)
• thinkfan should try to read from the "disabled" sensors periodically, but not issue warnings if reading from those sensors fails again, as those sensors should already be considered inactive
• if a previously disabled sensor starts returning sensible values again, it should be re-added to the list of "active" sensors, a message indicating that this occurred may be issued, but it should not be a warning.

[qbe]

edit: just discovered the "yaml config syntax", and the possibilities of if ... lets see if the "name-based hwmon" solves my specific issue for good, but i still think read errors should never crash the thinkfan process

[qbe]

confirmed that read errors can crash the service, even if the sensor section has the "optional" flag set, but only on service startup / restart. If the service is already running, a "Lost" message is added to the log periodically instead.

[vmatare]

This should have been fixed in the master branch for a while now, but it hadn't been released until now: https://github.com/vmatare/thinkfan/releases/tag/1.2.2

[qbe]

Wonderful, its already up-to-date on the AUR

[qbe]

Seems to have fixed the issue.