** Description changed: [Impact] When resuming from suspend, the fancontrol service is in a failed state. Fans might be stopped, at full speed, or in an indeterminate state. A restart of the service after resume gets it working again, and this fix uses a system-sleep hook script to accomplish that. The change here also includes the change from bug #1967432, so that the service is only restarted if it was active before. [Test Plan] There are two hardware requirements to fully test this SRU: - a machine capable of suspend/resume, like a laptop - a machine with hardware fan control compatible with fancontrol/lm-sensors A valid /etc/fancontrol configuration file must be generated, either manually or via pwmconfig(8). Without this file, the fancontrol service won't start. I didn't have any of those when preparing the fix, so I used a similarly configured systemd service to emulate what would happen (rsync in this case, which also depends on a config file to start). With the above setup, this is the test plan. For the following combinations, check that the desired result wrt fancontrol.service is achieved when resuming from suspend: At suspend time -> When resuming: Service is enabled and active --> is restarted Service is disabled and active --> is restarted Service is enabled and inactive --> is not restarted Service is disabled and inactive --> is not restarted + [Where problems could occur] + If the script in /lib/systemd/system-sleep fails, there doesn't seem to be any impact on the resume event. An initial iteration of my fix was calling systemctl is-active incorrectly, and all that happened was a log entry about that. - [Where problems could occur] + In some cases, to achieve manual fancontrol, a BIOS setting has to be + adjusted to allow for that. In that case, I think the biggest danger of + not having this fix is the indeterminate state of the fans when the + system resumes. For example, they could be entirely disabled without + this service running, and lead to overheating. This is just an + assumption, though, as I don't have such a system to experiment with. - * Think about what the upload changes in the software. Imagine the change is - wrong or breaks something else: how would this show up? + Depending on the hardware, users might not experience this bug, and + fancontrol works fine after a resume. These users would now have a + fancontrol restart in that scenario, which should be harmless. That + being said, the usual case of having made an invalid config file change + without restarting the service right away might show its head the first + time they suspend/resume. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. - - * This must '''never''' be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] fancontrol system daemon works great. If I suspend to RAM and wake up again it fails: > sudo service fancontrol status fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-06-05 18:47:10 CEST; 6s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 624293 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS) Process: 624444 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE) Main PID: 624444 (code=exited, status=1/FAILURE) Jun 05 18:33:43 jeeves fancontrol[624444]: Adjusing hwmon0/device/fan1_input -> hwmon0/fan1_input Jun 05 18:33:43 jeeves fancontrol[624444]: Enabling PWM on fans... Jun 05 18:33:43 jeeves fancontrol[624444]: Starting automatic fan control... Jun 05 18:47:09 jeeves fancontrol[624444]: /usr/sbin/fancontrol: line 643: echo: write error: Device or resource busy Jun 05 18:47:10 jeeves fancontrol[624444]: /usr/sbin/fancontrol: line 649: echo: write error: Device or resource busy Jun 05 18:47:10 jeeves fancontrol[624444]: Error writing PWM value to /sys/class/hwmon/hwmon0/pwm1 Jun 05 18:47:10 jeeves fancontrol[624444]: Aborting, restoring fans... Jun 05 18:47:10 jeeves fancontrol[624444]: Verify fans have returned to full speed Jun 05 18:47:10 jeeves systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE Jun 05 18:47:10 jeeves systemd[1]: fancontrol.service: Failed with result 'exit-code'. BUGFIX: add file to /lib/systemd/system-sleep/fancontrol with content #!/bin/bash case "$1" in post) exec service fancontrol restart;; esac ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: fancontrol 1:3.6.0-2ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Fri Jun 5 18:41:51 2020 InstallationDate: Installed on 2020-05-08 (28 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) PackageArchitecture: all SourcePackage: lm-sensors UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed: [Impact] When resuming from suspend, the fancontrol service is in a failed state. Fans might be stopped, at full speed, or in an indeterminate state. A restart of the service after resume gets it working again, and this fix uses a system-sleep hook script to accomplish that. The change here also includes the change from bug #1967432, so that the service is only restarted if it was active before. [Test Plan] There are two hardware requirements to fully test this SRU: - a machine capable of suspend/resume, like a laptop - a machine with hardware fan control compatible with fancontrol/lm-sensors A valid /etc/fancontrol configuration file must be generated, either manually or via pwmconfig(8). Without this file, the fancontrol service won't start. I didn't have any of those when preparing the fix, so I used a similarly configured systemd service to emulate what would happen (rsync in this case, which also depends on a config file to start). With the above setup, this is the test plan. For the following combinations, check that the desired result wrt fancontrol.service is achieved when resuming from suspend: At suspend time -> When resuming: Service is enabled and active --> is restarted Service is disabled and active --> is restarted Service is enabled and inactive --> is not restarted Service is disabled and inactive --> is not restarted [Where problems could occur] If the script in /lib/systemd/system-sleep fails, there doesn't seem to be any impact on the resume event. An initial iteration of my fix was calling systemctl is-active incorrectly, and all that happened was a log entry about that. In some cases, to achieve manual fancontrol, a BIOS setting has to be adjusted to allow for that. In that case, I think the biggest danger of not having this fix is the indeterminate state of the fans when the system resumes. For example, they could be entirely disabled without this service running, and lead to overheating. This is just an assumption, though, as I don't have such a system to experiment with. Depending on the hardware, users might not experience this bug, and fancontrol works fine after a resume. These users would now have a fancontrol restart in that scenario, which should be harmless. That being said, the usual case of having made an invalid config file change without restarting the service right away might show its head the first time they suspend/resume. + [Other Info] + This update uses the original fix from Debian in 3.6.0-6, plus our fix for bug #1967432. - [Other Info] + While preparing the fix, since I didn't have hardware compatible with + fancontrol, I used a similar service (rsync) and the same script in + /lib/systemd/system-sleep/ except with the service name changed (from + fancontrol to rsync), and observed rsync's behavior during + suspend/resume cycles. I chose rsync because it also has a condition on + a configuration file to start, just like fancontrol. - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance [Original Description] fancontrol system daemon works great. If I suspend to RAM and wake up again it fails: > sudo service fancontrol status fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-06-05 18:47:10 CEST; 6s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 624293 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS) Process: 624444 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE) Main PID: 624444 (code=exited, status=1/FAILURE) Jun 05 18:33:43 jeeves fancontrol[624444]: Adjusing hwmon0/device/fan1_input -> hwmon0/fan1_input Jun 05 18:33:43 jeeves fancontrol[624444]: Enabling PWM on fans... Jun 05 18:33:43 jeeves fancontrol[624444]: Starting automatic fan control... Jun 05 18:47:09 jeeves fancontrol[624444]: /usr/sbin/fancontrol: line 643: echo: write error: Device or resource busy Jun 05 18:47:10 jeeves fancontrol[624444]: /usr/sbin/fancontrol: line 649: echo: write error: Device or resource busy Jun 05 18:47:10 jeeves fancontrol[624444]: Error writing PWM value to /sys/class/hwmon/hwmon0/pwm1 Jun 05 18:47:10 jeeves fancontrol[624444]: Aborting, restoring fans... Jun 05 18:47:10 jeeves fancontrol[624444]: Verify fans have returned to full speed Jun 05 18:47:10 jeeves systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE Jun 05 18:47:10 jeeves systemd[1]: fancontrol.service: Failed with result 'exit-code'. BUGFIX: add file to /lib/systemd/system-sleep/fancontrol with content #!/bin/bash case "$1" in post) exec service fancontrol restart;; esac ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: fancontrol 1:3.6.0-2ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Fri Jun 5 18:41:51 2020 InstallationDate: Installed on 2020-05-08 (28 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) PackageArchitecture: all SourcePackage: lm-sensors UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882272 Title: fancontrol does not work after sleep/wakeup To manage notifications about this bug go to: https://bugs.launchpad.net/lmsensors/+bug/1882272/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
