FS#32465 - [laptop-mode-tools] laptop-mode not correctly restarted by systemd after suspend
Attached to Project:
Community Packages
Opened by Nicola Mori (snack) - Sunday, 04 November 2012, 19:58 GMT
Last edited by Lukas Jirkovsky (6xx) - Tuesday, 01 January 2013, 10:25 GMT
Opened by Nicola Mori (snack) - Sunday, 04 November 2012, 19:58 GMT
Last edited by Lukas Jirkovsky (6xx) - Tuesday, 01 January 2013, 10:25 GMT
|
Details
Description:
After recovery from suspend-to-ram the APM level of HDD is not correctly restored. Manually restarting laptop-mode fixes the problem. For example, starting with APM_level=254, suspending and then resuming gives: $ sudo hdparm -B /dev/sda /dev/sda: APM_level = 128 $ sudo systemctl restart laptop-mode $ sudo hdparm -B /dev/sda /dev/sda: APM_level = 254 I never noticed such a behavior with sysvinit. Additional info: * package version(s) laptop-mode-tools 1.62-2 systemd 195-2 * config and/or log files etc. journalctl is polluted by messages like: Nov 04 20:55:13 elric laptop-mode[9881]: Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/* is not readable, skipping. I don't know if it is relevant or not. It is also briefly reported in this forum thread: https://bbs.archlinux.org/viewtopic.php?id=152126 Steps to reproduce: * Check APM level using hdparm -B * Suspend-to-ram * Recover from suspend * Check APM level using hdparm -B * Restart laptop-mode: sudo systemctl restart laptop-mode * Check APM level using hdparm -B |
This task depends upon
Closed by Lukas Jirkovsky (6xx)
Tuesday, 01 January 2013, 10:25 GMT
Reason for closing: Duplicate
Additional comments about closing: see FS#33262
Tuesday, 01 January 2013, 10:25 GMT
Reason for closing: Duplicate
Additional comments about closing: see
It doesn't run correctly on startup but issuing the systemctl restart through bash, once logged in, correctly starts it.
Checking the tunables through powertop upon start up shows this.
FS#32395?$ ll /etc/systemd/system/multi-user.target.wants/laptop-mode.service
lrwxrwxrwx 1 root root 43 4 nov 12.16 /etc/systemd/system/multi-user.target.wants/laptop-mode.service -> /usr/lib/systemd/system/laptop-mode.service
$ ll /usr/lib/systemd/system/laptop-mode.service
-rw-r--r-- 1 root root 298 3 nov 10.21 /usr/lib/systemd/system/laptop-mode.service
I ebnabled the service through sudo systemctl enable laptop-mode.service, and eventually restart it with sudo systemctl restart laptop-mode.service. No laptop-mode-tools in any place.
Issuing the restart resolves this but it is temporary and has to be done each time logged in.
I'm in touch with the author, and am going through the motions of generating a fail-log to send to him and i'll report back afterwards...
Here's what he stated about the tty-to-syslog thing:
There are some issues the way systemd provides access to the input/output descriptors. If not specifying the tty in the systemd service, LMT fails to append messages to standard output and standard error. This was a PITA to root cause when I was adding the systemd support.
That is why the upstream systemd service specifies stdout and stderr as tty. Unless someone can explain their purpose and provide a better option, this will remain as it is.
Changing it from tty to anything else break logging for LMT.
So it seems that it is not only a systemd issue...
The problem is that the pm-utils are no longer used to suspend, instead some systemd crap is used that wreaks havoc in the power saving settings. You can test it with pm-suspend - laptop-mode should work correctly after wake up. It should be possible to write some kind of script that makes everything sane even when systemd is used, but I don't know systemd well enough to create a good and high-quality (is it even possible to have a high-quality hack?) script for that.
So far it looks that the problem occurs only if the system is suspended using "systemctl suspend", pm-suspend doesn't exhibit the issue. I'm going to report that as a systemd bug and close this one.