![]() ![]() Jun 05 18:33:43 jeeves fancontrol: Starting automatic fan control. Jun 05 18:33:43 jeeves fancontrol: Enabling PWM on fans. Jun 05 18:33:43 jeeves fancontrol: Adjusing hwmon0/ device/ fan1_input -> hwmon0/fan1_input Main PID: 624444 (code=exited, status=1/FAILURE) Process: 624444 ExecStart= /usr/sbin/ fancontrol (code=exited, status=1/FAILURE) Process: 624293 ExecStartPre= /usr/sbin/ fancontrol -check (code=exited, status=0/SUCCESS) service enabled vendor preset: enabled)Īctive: failed (Result: exit-code) since Fri 18:47:10 CEST 6s ago ![]() Loaded: loaded (/lib/systemd/ system/ fancontrol. If I suspend to RAM and wake up again it fails: I chose rsync because it also has a condition on a configuration file to start, just like fancontrol.įancontrol system daemon works great. 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. This update uses the original fix from Debian in 3.6.0-6, plus our fix for bug #1967432. 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. These users would now have a fancontrol restart in that scenario, which should be harmless. This is just an assumption, though, as I don't have such a system to experiment with.ĭepending on the hardware, users might not experience this bug, and fancontrol works fine after a resume. For example, they could be entirely disabled without this service running, and lead to overheating. In that case, I think the biggest danger of not having this fix is the indeterminate state of the fans when the system resumes. In some cases, to achieve manual fancontrol, a BIOS setting has to be adjusted to allow for that. An initial iteration of my fix was calling systemctl is-active incorrectly, and all that happened was a log entry about that. If the script in /lib/systemd/ system- sleep fails, there doesn't seem to be any impact on the resume event. Service is disabled and inactive -> is not restarted Service is enabled and inactive -> is not restarted Service is disabled and active -> is restarted Service is enabled and active -> is restarted With the above setup, this is the test plan.įor the following combinations, check that the desired result wrt rvice is achieved when resuming from suspend: 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). Without this file, the fancontrol service won't start. a machine with hardware fan control compatible with fancontrol/ lm-sensorsĪ valid /etc/fancontrol configuration file must be generated, either manually or via pwmconfig(8). a machine capable of suspend/resume, like a laptop There are two hardware requirements to fully test this SRU: The change here also includes the change from bug #1967432, so that the service is only restarted if it was active before. Fans might be stopped, at full speed, or in an indeterminate state.Ī restart of the service after resume gets it working again, and this fix uses a system-sleep hook script to accomplish that. When resuming from suspend, the fancontrol service is in a failed state. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |