Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#690748: laptop-mode-tools: enabling Laptop Mode even if disabled in LMT config
44 views
Skip to first unread message
Jasmine Hassan
Oct 17, 2012, 3:20:02 AM10/17/12
to
Package: laptop-mode-tools
Version: 1.61-1
# grep ENABLE_LAPTOP_MODE_TOOLS /etc/laptop-mode/laptop-mode.conf
ENABLE_LAPTOP_MODE_TOOLS=0
# ls -l /var/run/laptop-mode-tools/enabled
ls: cannot access /var/run/laptop-mode-tools/enabled: No such file or directory
# /etc/init.d/laptop-mode start
[ ok ] Enabling laptop mode...done (Warning: Configuration file
/etc/laptop-mode/conf.d/board-specific/*.conf is not readable,
skipping.
laptop-mode-tools is disabled in config file. Exiting).
# ls -l /var/run/laptop-mode-tools/enabled
-rw-r--r-- 1 root root 0 Sep 21 17:12 /var/run/laptop-mode-tools/enabled
----
I can see at least two problems with this:
1. /usr/lib/pm-utils/power.d/95hdparm-apm checks for the presence of
/var/run/laptop-mode-tools/enabled , and when found, the pm-utils hook
immediately exits because it assumes laptop-mode-tools is managing HDD
PM (by checking for CONTROL_HD_POWERMGMT in
/etc/laptop-mode/laptop-mode.conf).
This also affects suspend/resume/hibernate/thaw modes, due to symlink
from /usr/lib/pm-utils/sleep.d/95hdparm-apm
This effectively prevents hdparm from managing HDD's APM.
2. /usr/lib/pm-utils/sleep.d/01laptop-mode , when it finds
/usr/sbin/laptop_mode, runs it with the arguments "auto force". This
results in error: laptop-mode-tools is disabled in config file.
Exiting
Best,
Jasmine
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Version: 1.61-1
# grep ENABLE_LAPTOP_MODE_TOOLS /etc/laptop-mode/laptop-mode.conf
ENABLE_LAPTOP_MODE_TOOLS=0
# ls -l /var/run/laptop-mode-tools/enabled
ls: cannot access /var/run/laptop-mode-tools/enabled: No such file or directory
# /etc/init.d/laptop-mode start
[ ok ] Enabling laptop mode...done (Warning: Configuration file
/etc/laptop-mode/conf.d/board-specific/*.conf is not readable,
skipping.
laptop-mode-tools is disabled in config file. Exiting).
# ls -l /var/run/laptop-mode-tools/enabled
-rw-r--r-- 1 root root 0 Sep 21 17:12 /var/run/laptop-mode-tools/enabled
----
I can see at least two problems with this:
1. /usr/lib/pm-utils/power.d/95hdparm-apm checks for the presence of
/var/run/laptop-mode-tools/enabled , and when found, the pm-utils hook
immediately exits because it assumes laptop-mode-tools is managing HDD
PM (by checking for CONTROL_HD_POWERMGMT in
/etc/laptop-mode/laptop-mode.conf).
This also affects suspend/resume/hibernate/thaw modes, due to symlink
from /usr/lib/pm-utils/sleep.d/95hdparm-apm
This effectively prevents hdparm from managing HDD's APM.
2. /usr/lib/pm-utils/sleep.d/01laptop-mode , when it finds
/usr/sbin/laptop_mode, runs it with the arguments "auto force". This
results in error: laptop-mode-tools is disabled in config file.
Exiting
Best,
Jasmine
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ritesh Raj Sarraf
Oct 17, 2012, 4:50:01 AM10/17/12
to
Hello Jasmine,
On Wednesday 17 October 2012 12:39 PM, Jasmine Hassan wrote:
> Package: laptop-mode-tools
> Version: 1.61-1
>
> # grep ENABLE_LAPTOP_MODE_TOOLS /etc/laptop-mode/laptop-mode.conf
> ENABLE_LAPTOP_MODE_TOOLS=0
>
> # ls -l /var/run/laptop-mode-tools/enabled
> ls: cannot access /var/run/laptop-mode-tools/enabled: No such file or directory
>
> # /etc/init.d/laptop-mode start
> [ ok ] Enabling laptop mode...done (Warning: Configuration file
> /etc/laptop-mode/conf.d/board-specific/*.conf is not readable,
> skipping.
> laptop-mode-tools is disabled in config file. Exiting).
>
> # ls -l /var/run/laptop-mode-tools/enabled
> -rw-r--r-- 1 root root 0 Sep 21 17:12 /var/run/laptop-mode-tools/enabled
Yes. This should be handled better. Currently the "enabled" file is
touched in the init script. So even if LMT exited, the file doesn't get
cleaned.
Thanks for reporting this.
TODO: Investigate how to capture state, especially given that now we
have multiple invocation sources, pm-utils, acpid, kernel etc.
> ----
>
> I can see at least two problems with this:
>
> 1. /usr/lib/pm-utils/power.d/95hdparm-apm checks for the presence of
> /var/run/laptop-mode-tools/enabled , and when found, the pm-utils hook
> immediately exits because it assumes laptop-mode-tools is managing HDD
> PM (by checking for CONTROL_HD_POWERMGMT in
> /etc/laptop-mode/laptop-mode.conf).
> This also affects suspend/resume/hibernate/thaw modes, due to symlink
> from /usr/lib/pm-utils/sleep.d/95hdparm-apm
> This effectively prevents hdparm from managing HDD's APM.
>
> 2. /usr/lib/pm-utils/sleep.d/01laptop-mode , when it finds
> /usr/sbin/laptop_mode, runs it with the arguments "auto force". This
> results in error: laptop-mode-tools is disabled in config file.
> Exiting
>
> Best,
> Jasmine
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
On Wednesday 17 October 2012 12:39 PM, Jasmine Hassan wrote:
> Package: laptop-mode-tools
> Version: 1.61-1
>
> # grep ENABLE_LAPTOP_MODE_TOOLS /etc/laptop-mode/laptop-mode.conf
> ENABLE_LAPTOP_MODE_TOOLS=0
>
> # ls -l /var/run/laptop-mode-tools/enabled
> ls: cannot access /var/run/laptop-mode-tools/enabled: No such file or directory
>
> # /etc/init.d/laptop-mode start
> [ ok ] Enabling laptop mode...done (Warning: Configuration file
> /etc/laptop-mode/conf.d/board-specific/*.conf is not readable,
> skipping.
> laptop-mode-tools is disabled in config file. Exiting).
>
> # ls -l /var/run/laptop-mode-tools/enabled
> -rw-r--r-- 1 root root 0 Sep 21 17:12 /var/run/laptop-mode-tools/enabled
touched in the init script. So even if LMT exited, the file doesn't get
cleaned.
Thanks for reporting this.
TODO: Investigate how to capture state, especially given that now we
have multiple invocation sources, pm-utils, acpid, kernel etc.
> ----
>
> I can see at least two problems with this:
>
> 1. /usr/lib/pm-utils/power.d/95hdparm-apm checks for the presence of
> /var/run/laptop-mode-tools/enabled , and when found, the pm-utils hook
> immediately exits because it assumes laptop-mode-tools is managing HDD
> PM (by checking for CONTROL_HD_POWERMGMT in
> /etc/laptop-mode/laptop-mode.conf).
> This also affects suspend/resume/hibernate/thaw modes, due to symlink
> from /usr/lib/pm-utils/sleep.d/95hdparm-apm
> This effectively prevents hdparm from managing HDD's APM.
>
> 2. /usr/lib/pm-utils/sleep.d/01laptop-mode , when it finds
> /usr/sbin/laptop_mode, runs it with the arguments "auto force". This
> results in error: laptop-mode-tools is disabled in config file.
> Exiting
>
> Best,
> Jasmine
--
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
Ritesh Raj Sarraf
Oct 17, 2012, 5:10:01 AM10/17/12
to
Jasmine,
Does this patch help?
diff --git a/usr/sbin/laptop_mode
b/usr/sbin/laptop_mode
index 4628bc8..89f140f
100755
---
a/usr/sbin/laptop_mode
+++
b/usr/sbin/laptop_mode
@@ -253,6 +253,10 @@ lmt_load_config
()
if [ x$ENABLE_LAPTOP_MODE_TOOLS = x0 ];
then
log "MSG" "laptop-mode-tools is disabled in config file.
Exiting"
+ if [ -f /var/run/laptop-mode-tools/enabled ];
then
+ rm -rf
/var/run/laptop-mode-tools/enabled
+
fi
+ log "VERBOSE" "Clean up laptop-mode-tools init state"
exit 0;
fi
Does this patch help?
diff --git a/usr/sbin/laptop_mode
b/usr/sbin/laptop_mode
index 4628bc8..89f140f
100755
---
a/usr/sbin/laptop_mode
+++
b/usr/sbin/laptop_mode
@@ -253,6 +253,10 @@ lmt_load_config
()
if [ x$ENABLE_LAPTOP_MODE_TOOLS = x0 ];
then
log "MSG" "laptop-mode-tools is disabled in config file.
Exiting"
+ if [ -f /var/run/laptop-mode-tools/enabled ];
then
+ rm -rf
/var/run/laptop-mode-tools/enabled
+
fi
+ log "VERBOSE" "Clean up laptop-mode-tools init state"
exit 0;
fi
Jasmine Hassan
Oct 17, 2012, 5:10:02 AM10/17/12
to
please don't send patches in-line. they automatically get
line-wrapped, and this is a bother to fix just to save a .diff. so
better attach em.
though, from the logic you propose, yes. that's one way to go. I was
thinking even something like:
if [ "`cat /proc/sys/vm/laptop_mode`" = "$LM_SECONDS_BEFORE_SYNC" ] ...
for laptop-mode status
because I can start laptop-mode, edit the config file to disable, and
status won't otherwise report the _actual_ status.
also no need for the -r in rm -f. it's a file, so we don't need
"recursive" flag.
cheers
line-wrapped, and this is a bother to fix just to save a .diff. so
better attach em.
though, from the logic you propose, yes. that's one way to go. I was
thinking even something like:
if [ "`cat /proc/sys/vm/laptop_mode`" = "$LM_SECONDS_BEFORE_SYNC" ] ...
for laptop-mode status
because I can start laptop-mode, edit the config file to disable, and
status won't otherwise report the _actual_ status.
also no need for the -r in rm -f. it's a file, so we don't need
"recursive" flag.
cheers
Ritesh Raj Sarraf
Oct 17, 2012, 8:20:02 AM10/17/12
to
On Wednesday 17 October 2012 02:37 PM, Jasmine Hassan wrote:
> please don't send patches in-line. they automatically get
> line-wrapped, and this is a bother to fix just to save a .diff. so
> better attach em.
>
> though, from the logic you propose, yes. that's one way to go. I was
> thinking even something like:
> if [ "`cat /proc/sys/vm/laptop_mode`" = "$LM_SECONDS_BEFORE_SYNC" ] ...
> for laptop-mode status
No. That won't help. It is not just about setting the kernel knob. We do
> please don't send patches in-line. they automatically get
> line-wrapped, and this is a bother to fix just to save a .diff. so
> better attach em.
>
> though, from the logic you propose, yes. that's one way to go. I was
> thinking even something like:
> if [ "`cat /proc/sys/vm/laptop_mode`" = "$LM_SECONDS_BEFORE_SYNC" ] ...
> for laptop-mode status
a lot more than that.
Jasmine Hassan
Oct 17, 2012, 8:40:02 AM10/17/12
to
On Wed, Oct 17, 2012 at 2:08 PM, Ritesh Raj Sarraf <r...@researchut.com> wrote:
> On Wednesday 17 October 2012 02:37 PM, Jasmine Hassan wrote:
>> though, from the logic you propose, yes. that's one way to go. I was
>> thinking even something like:
>> if [ "`cat /proc/sys/vm/laptop_mode`" = "$LM_SECONDS_BEFORE_SYNC" ] ...
>> for laptop-mode status
> No. That won't help. It is not just about setting the kernel knob. We do
> a lot more than that.
Of course. It's just that:
> On Wednesday 17 October 2012 02:37 PM, Jasmine Hassan wrote:
>> though, from the logic you propose, yes. that's one way to go. I was
>> thinking even something like:
>> if [ "`cat /proc/sys/vm/laptop_mode`" = "$LM_SECONDS_BEFORE_SYNC" ] ...
>> for laptop-mode status
> No. That won't help. It is not just about setting the kernel knob. We do
> a lot more than that.
set_sysctl /proc/sys/vm/laptop_mode 0
is hardcoded in /usr/share/laptop-mode-tools/modules/laptop-mode ,
when deactivating.
So if I do `service start laptop-mode`m edit config file to disable
LMT, I can still do `service stop laptop-mode` without it enabled.
As it stands:
/usr/sbin/laptop_mode
# If the init script has not been run or has been run with the "stop"
# argument, then we should never start laptop mode.
if [ ! -f /var/run/laptop-mode-tools/enabled ] ; then
log "VERBOSE" "Laptop mode disabled because
/var/run/laptop-mode-tools/enabled is missing."
STATE=disabled
fi
...
if [ "$STATE" = "disabled" ] ; then
ACTIVATE=0
fi
...
if [ "$ACTIVATE" -eq 0 ] ; then
ACTIVATE_WITH_POSSIBLE_DATA_LOSS=0
...
# WAS_ACTIVE is used later on. If there is no
/var/run/laptop-mode-tools/state, then
# we know that laptop mode wasn't active before.
WAS_ACTIVE=0
...
I fail to see how it would be stopped, when service was started but
user disabled in config.
It's been a while since I looked at /usr/sbin/laptop_mode :)
>
>
> --
> Ritesh Raj Sarraf
> RESEARCHUT - http://www.researchut.com
> "Necessity is the mother of invention."
>
>
Ritesh Raj Sarraf
Oct 17, 2012, 10:00:02 AM10/17/12
to
On Wednesday 17 October 2012 06:01 PM, Jasmine Hassan wrote:
> So if I do `service start laptop-mode`m edit config file to disable
> LMT, I can still do `service stop laptop-mode` without it enabled.
I don't know what you are intending here.
> So if I do `service start laptop-mode`m edit config file to disable
> LMT, I can still do `service stop laptop-mode` without it enabled.
Whenever LMT is invoked, it'll call lmt_load_config(). There it checks
for, if LMT is enabled and proceeds, or otherwise it just exits out.
Jasmine Hassan
Oct 17, 2012, 10:10:02 AM10/17/12
to
On Wed, Oct 17, 2012 at 3:53 PM, Ritesh Raj Sarraf <r...@researchut.com> wrote:
> On Wednesday 17 October 2012 06:01 PM, Jasmine Hassan wrote:
>> So if I do `service start laptop-mode`m edit config file to disable
>> LMT, I can still do `service stop laptop-mode` without it enabled.
>
> I don't know what you are intending here.
Sorry I wasn't clear (and for the typo). Rephrase:
> On Wednesday 17 October 2012 06:01 PM, Jasmine Hassan wrote:
>> So if I do `service start laptop-mode`m edit config file to disable
>> LMT, I can still do `service stop laptop-mode` without it enabled.
>
> I don't know what you are intending here.
1. start laptop-mode
2. nano /etc/laptop-mode/laptop-mode.conf
and change:
ENABLE_LAPTOP_MODE_TOOLS=1
to:
ENABLE_LAPTOP_MODE_TOOLS=0
Now, although laptop-mode is enabled, the init script doesn't tell the
actual status, when invoking `service laptop-mode status`.
And how would `service laptop-mode stop` react in this case? Does it
not bother try to deactivate laptop-mode just because it sees
ENABLE_LAPTOP_MODE_TOOLS=0 in config? i.e. are we accounting for the
possibility that, although config file shows LMT is disabled, that LMT
may have been started (and not manually stopped) before we disabled?
What happens then if I suspend? LMT thinks its disabled, does nothing,
when it should actually be deactivating because we
started-before-config-disable.
Am I making a bit more sense?
>
> Whenever LMT is invoked, it'll call lmt_load_config(). There it checks
> for, if LMT is enabled and proceeds, or otherwise it just exits out.
>
> --
> Ritesh Raj Sarraf
> RESEARCHUT - http://www.researchut.com
> "Necessity is the mother of invention."
>
>
Ritesh Raj Sarraf
Oct 21, 2012, 5:10:02 AM10/21/12
to
On Wednesday 17 October 2012 07:36 PM,
Jasmine Hassan wrote:
Sorry I wasn't clear (and for the typo). Rephrase: 1. start laptop-mode 2. nano /etc/laptop-mode/laptop-mode.conf and change: ENABLE_LAPTOP_MODE_TOOLS=1 to: ENABLE_LAPTOP_MODE_TOOLS=0 Now, although laptop-mode is enabled, the init script doesn't tell the actual status, when invoking `service laptop-mode status`.
The problem seemed to be caused because we were exiting if LMT was
disabled in the config file. Attached patch should help improve your
use case.
But I would like to change the way LMT invokes. Currently it is a hodge podge of /var/run/laptop-mode-tools/enabled and ENABLE_LMT settings.
LMT now is events based. So as soon as the kernel and the basic system is up, it gets invoked. It needs to be checked how LMT behaves when invoked before the initscript. In the init script, it is invoked with "init auto" argument. Also the /var/run/laptop-mode-tools/enabled file is created there. Where as when invoked through udev, we pass it the "auto" argument only.
There are many problems here:
* When invoked through init scripts, it touched the "enabled" file, then called LMT, realized that ENABLE_LMT was set to 0 and it exited. But it did not clean the "enabled" file. For that, I proposed the change in one of the previous emails.
* When invoked through udev, we do not care or create the "enabled" file.
With it, when the ENABLE_LMT is set to 0, we get
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
[sudo] password for rrs:
But I would like to change the way LMT invokes. Currently it is a hodge podge of /var/run/laptop-mode-tools/enabled and ENABLE_LMT settings.
LMT now is events based. So as soon as the kernel and the basic system is up, it gets invoked. It needs to be checked how LMT behaves when invoked before the initscript. In the init script, it is invoked with "init auto" argument. Also the /var/run/laptop-mode-tools/enabled file is created there. Where as when invoked through udev, we pass it the "auto" argument only.
There are many problems here:
* When invoked through init scripts, it touched the "enabled" file, then called LMT, realized that ENABLE_LMT was set to 0 and it exited. But it did not clean the "enabled" file. For that, I proposed the change in one of the previous emails.
* When invoked through udev, we do not care or create the "enabled" file.
With it, when the ENABLE_LMT is set to 0, we get
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
[sudo] password for rrs:
Warning: Configuration file
/etc/laptop-mode/conf.d/board-specific/*.conf is not readable,
skipping.
laptop-mode-tools is disabled in config file. Exiting
laptop-mode-tools is disabled in config file. Exiting
With ENABLE_LMT=1, we get
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
Warning: Configuration file
/etc/laptop-mode/conf.d/board-specific/*.conf is not readable,
skipping.
Laptop
mode
enabled,
active [unchanged]
With "enabled" file removed, it shows:
rrs@champaran:~$ sudo rm /var/run/laptop-mode-tools/enabled
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
enabled,
active [unchanged]
With "enabled" file removed, it shows:
rrs@champaran:~$ sudo rm /var/run/laptop-mode-tools/enabled
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is not readable, skipping.
Laptop mode
disabled,
not active [unchanged]
So it just disabled LMT because it was not "enabled".
And if "enabled" is set again, things go right.
rrs@champaran:~$ sudo touch /var/run/laptop-mode-tools/enabled
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
disabled,
not active [unchanged]
So it just disabled LMT because it was not "enabled".
And if "enabled" is set again, things go right.
rrs@champaran:~$ sudo touch /var/run/laptop-mode-tools/enabled
rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is not readable, skipping.
Laptop mode
enabled, active
There are 2 items to fix.
* Invocation
* Status
If you have time, you can review the patch and do some tests. Let me know.
enabled, active
There are 2 items to fix.
* Invocation
* Status
If you have time, you can review the patch and do some tests. Let me know.
Jasmine Hassan
Oct 21, 2012, 6:50:02 AM10/21/12
to
On Sun, Oct 21, 2012 at 11:07 AM, Ritesh Raj Sarraf <r...@researchut.com> wrote:
> The problem seemed to be caused because we were exiting if LMT was disabled
> in the config file. Attached patch should help improve your use case.
>
Yes, that is one of the problems. If I may suggest, to be more user-proof:
> The problem seemed to be caused because we were exiting if LMT was disabled
> in the config file. Attached patch should help improve your use case.
>
change:
echo "$ENABLE_LAPTOP_MODE" |grep y
to:
echo "$ENABLE_LAPTOP_MODE" | egrep -i "(y|1)"
Though, there's no /etc/default/laptop-mode installed on debian by LMT 1.61-1
> But I would like to change the way LMT invokes. Currently it is a hodge
> podge of /var/run/laptop-mode-tools/enabled and ENABLE_LMT settings.
> * When invoked through init scripts, it touched the "enabled" file, then
> called LMT, realized that ENABLE_LMT was set to 0 and it exited. But it did
> not clean the "enabled" file. For that, I proposed the change in one of the
> previous emails.
> * When invoked through udev, we do not care or create the "enabled" file.
For that, I had overridden it in
/etc/udev/rules.d/99-laptop-mode.rules, with comments, as I intended
to report this to you as well (way back) and totally forgot.
# /lib/udev/power-lmt-udev runs both lmt & pm-powersave
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0",
RUN+="/lib/udev/power-lmt-udev"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1",
RUN+="/lib/udev/power-lmt-udev"
# Laptop-mode-tools default rules below, and reasons for disabling them
# This generates 2 events, running script(s) twice. No good!
#ACTION=="change", SUBSYSTEM=="power_supply", RUN+="/lib/udev/lmt-udev auto"
# What is machinecheck? See: http://www.researchut.com/site/node/158
# We don't need it as we're handling LMT from
/etc/pm/sleep.d/01_laptop-mode-tools
#ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="/lib/udev/lmt-udev auto"
# We're also not using LMT's usb-autosuspend module
#ACTION=="add", SUBSYSTEM=="usb", RUN+="/lib/udev/lmt-udev force
modules=usb-autosuspend devices=%k"
=> LMT is also adding hooks for acpid in /etc/acpi/(actions|events)
and hooks for upower in (/etc/power/scripts.d|events.d) and even hooks
for the antiquated apmd in /etc/apm/event.d/ , even though it's not
even installed on my system.
i.e. All over the place. This caused me some grief.
udev+acpid+upowerd. Quite excessive I must say.
I had to edit each of the three lm_* files in /etc/acpi/events/, and
comment out the two lines in each of them.
So, can't this be better managed via a postinst script? Say it would:
1. detect available facilities (pm-utils/udev/acpid/upowerd/apmd),
pick one and only one, based on an ordered LMT preference list. Warn
the user if none of the recommended facilities are installed/enabled.
This could be later fixed by the user via dpkg-reconfigure
laptop-mode-tools, or whatever.
2. create symlinks to a common startup directory, say
/usr/share/laptop-mode-tools/startup-hooks/*, for event/script hooks
applicable to the chosen, available facility.
> With ENABLE_LMT=1, we get
>
> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
> not readable, skipping.
> Laptop mode enabled
N.B. in my pre-last email I attached a little patch that amends this
output. I really disliked getting two separate lines for each LMT
invocation in my pm-* logs, for only a few words.
The warning about board-specific conf is also quite annoying. What use
is "board-specific", as a (non-existent by default) sub-directory of
"conf.d", if "conf.d" itself already serves the purpose of a dynamic
user-configuration-include directory? There's also no mention of it in
the laptop-mode.conf manpage.
>
> With "enabled" file removed, it shows:
>
> rrs@champaran:~$ sudo rm /var/run/laptop-mode-tools/enabled
> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>
> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
> not readable, skipping.
> Laptop mode
> disabled,
> not active [unchanged]
>
> So it just disabled LMT because it was not "enabled".
>
>
> And if "enabled" is set again, things go right.
>
> rrs@champaran:~$ sudo touch /var/run/laptop-mode-tools/enabled
> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>
> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
> not readable, skipping.
> Laptop mode
> enabled, active
>
Per the laptop_mode man-page:
auto Enable or disable laptop mode based on the current power
state. Note that this will not do anything if the laptop-mode service
has not been started!
>
> There are 2 items to fix.
>
> * Invocation
> * Status
>
> If you have time, you can review the patch and do some tests. Let me know.
>
deprecated "backwards-compatibility" stuff needs to go.
I'm sorry, but overall, I really don't like the current state of LMT.
And although I have all power-management stuff scripted in a pm-utils
power.d script, I still find LMT useful for the disabling of
data-sensitive feature and the (system-level) auto-hibernate at
configurable low and critical battery levels (without polling)
feature.
LMT needs much more love than the patch you propose.
Hope I'm not being too harshly critical.
>
>
>
>
> --
> Ritesh Raj Sarraf
> RESEARCHUT - http://www.researchut.com
> "Necessity is the mother of invention."
Jasmine
Jasmine Hassan
Oct 21, 2012, 8:10:01 AM10/21/12
to
Ritesh,
Another thing:
$ /etc/init.d/laptop-mode status
Laptop mode status:
/usr/sbin/laptop_mode: 1175: /usr/sbin/laptop_mode: cannot create /var/lock/lmt-req.lock: Permission denied
Do I really need to be root to get the status of LMT? Why are we creating a lock file when all we want is get the status of LMT?
--jas
Another thing:
$ /etc/init.d/laptop-mode status
Laptop mode status:
/usr/sbin/laptop_mode: 1175: /usr/sbin/laptop_mode: cannot create /var/lock/lmt-req.lock: Permission denied
Do I really need to be root to get the status of LMT? Why are we creating a lock file when all we want is get the status of LMT?
--jas
Jasmine Hassan
Oct 21, 2012, 8:50:02 AM10/21/12
to
Now the superfluous, yet unsatisfying output of `/etc/init.d/laptop-mode status` -- below the comments.
1. The first line says "Laptop mode status:", but it doesn't tell me whether LMT is active/inactive, enabled/disabled.
2. LMT has nothing to do with how sysfs, proc, udev, debugfs, etc. are mounted. Therefore, it shouldn't be printing all mounts.
I have in the config:
CONTROL_NOATIME=0
LM_BATT_MAX_LOST_WORK_SECONDS=600
LM_AC_MAX_LOST_WORK_SECONDS=360
So, I expect `laptop-mode status` to only show me mounts that have their commit value changed by LMT. This is much easier to read, than having to look through 14 long lines to determine which 2 lines are affected by LMT, and then look for the commit value in each of them.
And if you want to be a little more verbose, you could just tell me that LMT is not configured to manage (REL|NO)ATIME.
3. In the config, I have:
CONTROL_HD_IDLE_TIMEOUT=0
Which tells LMT not to control the hard drive idle timeout settings. So, I shouldn't be seeing output about drive status, nor a note that LMT drive settings cannot be retrieved, because I configured LMT not to manage drive idle timeout.
4. "LMT allowed to run, enabled file exists". This probably doesn't concern most end-users, as they don't ever directly interact with this file.
5. I don't have LMT cpufreq module enabled, and ENABLE_AUTO_MODULES=0 is set in LMT config. Again, it shouldn't be printing information about something it is not managing.
Also, if I enabled cpufreq, there surely must be a more user-friendly way of displaying various information:
a. not having to scroll through so many lines, for each cpu's min/amx/cur frequency,
b. frequencies in MHz (instead of default Hz),
c. I probably don't need to see scaling_governor for each cpu core, if they're all the same (often the case)
----
$ sudo /etc/init.d/laptop-mode status
Laptop mode status:
Mounts:
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=492916,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/disk/by-uuid/56dd2ec2-7c29-4fdc-a531-ab6f83fa6e04 on / type ext4 (rw,relatime,errors=remount-ro,commit=360,data=ordered)
tmpfs on /var/run type tmpfs (rw,nosuid,noexec,relatime,size=395532k,mode=755)
tmpfs on /var/run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=791060k)
tmpfs on /var/run/shm type tmpfs (rw,nosuid,nodev,relatime,size=791060k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda7 on /media/data type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
cgroup on /dev/cgroup/cpu type cgroup (rw,relatime,cpu,release_agent=/usr/local/sbin/cgroup_clean)
Drive power status:
/dev/sda:
drive state is: active/idle
(NOTE: drive settings affected by Laptop Mode cannot be retrieved.)
Readahead states:
/dev/disk/by-uuid/56dd2ec2-7c29-4fdc-a531-ab6f83fa6e04: 6144 kB
/dev/sda7: 6144 kB
Laptop Mode Tools is allowed to run: /var/run/laptop-mode-tools/enabled exists.
/proc/sys/vm/laptop_mode:
5
/proc/sys/vm/dirty_ratio:
60
/proc/sys/vm/dirty_background_ratio:
1
/proc/sys/vm/dirty_expire_centisecs:
36000
/proc/sys/vm/dirty_writeback_centisecs:
36000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:
1200000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:
1200000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq:
2501000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:
1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:
ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:
ondemand
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:
ondemand
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:
ondemand
/proc/acpi/button/lid/LID0/state:
state: closed
/sys/class/power_supply/ACAD/online:
1
1. The first line says "Laptop mode status:", but it doesn't tell me whether LMT is active/inactive, enabled/disabled.
2. LMT has nothing to do with how sysfs, proc, udev, debugfs, etc. are mounted. Therefore, it shouldn't be printing all mounts.
I have in the config:
CONTROL_NOATIME=0
LM_BATT_MAX_LOST_WORK_SECONDS=600
LM_AC_MAX_LOST_WORK_SECONDS=360
So, I expect `laptop-mode status` to only show me mounts that have their commit value changed by LMT. This is much easier to read, than having to look through 14 long lines to determine which 2 lines are affected by LMT, and then look for the commit value in each of them.
And if you want to be a little more verbose, you could just tell me that LMT is not configured to manage (REL|NO)ATIME.
3. In the config, I have:
CONTROL_HD_IDLE_TIMEOUT=0
Which tells LMT not to control the hard drive idle timeout settings. So, I shouldn't be seeing output about drive status, nor a note that LMT drive settings cannot be retrieved, because I configured LMT not to manage drive idle timeout.
4. "LMT allowed to run, enabled file exists". This probably doesn't concern most end-users, as they don't ever directly interact with this file.
5. I don't have LMT cpufreq module enabled, and ENABLE_AUTO_MODULES=0 is set in LMT config. Again, it shouldn't be printing information about something it is not managing.
Also, if I enabled cpufreq, there surely must be a more user-friendly way of displaying various information:
a. not having to scroll through so many lines, for each cpu's min/amx/cur frequency,
b. frequencies in MHz (instead of default Hz),
c. I probably don't need to see scaling_governor for each cpu core, if they're all the same (often the case)
----
$ sudo /etc/init.d/laptop-mode status
Laptop mode status:
Mounts:
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=492916,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/disk/by-uuid/56dd2ec2-7c29-4fdc-a531-ab6f83fa6e04 on / type ext4 (rw,relatime,errors=remount-ro,commit=360,data=ordered)
tmpfs on /var/run type tmpfs (rw,nosuid,noexec,relatime,size=395532k,mode=755)
tmpfs on /var/run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=791060k)
tmpfs on /var/run/shm type tmpfs (rw,nosuid,nodev,relatime,size=791060k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda7 on /media/data type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
cgroup on /dev/cgroup/cpu type cgroup (rw,relatime,cpu,release_agent=/usr/local/sbin/cgroup_clean)
Drive power status:
/dev/sda:
drive state is: active/idle
(NOTE: drive settings affected by Laptop Mode cannot be retrieved.)
Readahead states:
/dev/disk/by-uuid/56dd2ec2-7c29-4fdc-a531-ab6f83fa6e04: 6144 kB
/dev/sda7: 6144 kB
Laptop Mode Tools is allowed to run: /var/run/laptop-mode-tools/enabled exists.
/proc/sys/vm/laptop_mode:
5
/proc/sys/vm/dirty_ratio:
60
/proc/sys/vm/dirty_background_ratio:
1
/proc/sys/vm/dirty_expire_centisecs:
36000
/proc/sys/vm/dirty_writeback_centisecs:
36000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:
1200000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq:
1200000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq:
2501000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:
1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:
2501000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:
1200000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:
ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:
ondemand
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:
ondemand
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:
ondemand
/proc/acpi/button/lid/LID0/state:
state: closed
/sys/class/power_supply/ACAD/online:
1
Jasmine Hassan
Oct 21, 2012, 9:00:02 AM10/21/12
to
Another obvious issue:
----
$ less /etc/laptop-mode/laptop-mode.conf
$ grep ENABLE_LAPTOP_MODE_ON /etc/laptop-mode/laptop-mode.conf
ENABLE_LAPTOP_MODE_ON_BATTERY=1
ENABLE_LAPTOP_MODE_ON_AC=0
$ cat /sys/class/power_supply/ACAD/online
1
$ sudo /usr/sbin/laptop_mode auto
----
$ less /etc/laptop-mode/laptop-mode.conf
$ grep ENABLE_LAPTOP_MODE_ON /etc/laptop-mode/laptop-mode.conf
ENABLE_LAPTOP_MODE_ON_BATTERY=1
ENABLE_LAPTOP_MODE_ON_AC=0
$ cat /sys/class/power_supply/ACAD/online
1
$ sudo /usr/sbin/laptop_mode auto
Laptop mode
enabled, active [unchanged]
-----
Why is it active, even after running `laptop_mode auto`, if I didn't ENABLE_LAPTOP_MODE_ON_AC, and am on AC?
This is laptop_mode with your proposed patch applied.
--jas
Why is it active, even after running `laptop_mode auto`, if I didn't ENABLE_LAPTOP_MODE_ON_AC, and am on AC?
This is laptop_mode with your proposed patch applied.
--jas
Jasmine Hassan
Oct 21, 2012, 9:30:02 AM10/21/12
to
disregard point #3 regarding `laptop-mode status` output, because even though I have configured idle timeout 0:
# We don't want spin-down (Start_Stop_Count)
CONTROL_HD_IDLE_TIMEOUT=0
.. I've also configured:
# Should laptop mode tools control the hard drive power management settings?
CONTROL_HD_POWERMGMT="auto"
# 128 = Highest power-management without allowing spin-downs
BATT_HD_POWERMGMT=128
LM_AC_HD_POWERMGMT=128
NOLM_AC_HD_POWERMGMT=254
But that information could actually be retrieved (if I'm forced to run `/etc/init.d/laptop-mode status` as root anyway):
$ sudo /sbin/hdparm -I /dev/sda | grep "power management level:"
Advanced power management level: 128
So the following statement is incorrect (So long as I'm required to run `laptop-mode status` as root):
# We don't want spin-down (Start_Stop_Count)
CONTROL_HD_IDLE_TIMEOUT=0
.. I've also configured:
# Should laptop mode tools control the hard drive power management settings?
CONTROL_HD_POWERMGMT="auto"
# 128 = Highest power-management without allowing spin-downs
BATT_HD_POWERMGMT=128
LM_AC_HD_POWERMGMT=128
NOLM_AC_HD_POWERMGMT=254
But that information could actually be retrieved (if I'm forced to run `/etc/init.d/laptop-mode status` as root anyway):
$ sudo /sbin/hdparm -I /dev/sda | grep "power management level:"
Advanced power management level: 128
So the following statement is incorrect (So long as I'm required to run `laptop-mode status` as root):
(NOTE: drive settings affected by Laptop Mode cannot be retrieved.)
---
Now another issue:
$ sudo /etc/init.d/laptop-mode stop
[....] Disabling laptop mode...mount: /dev/cgroup/cpu is busy
done (disabled, not active).
Why is LMT messing with /dev/cgroup/cpu?
$ grep ^PARTITIONS /etc/laptop-mode/laptop-mode.conf
PARTITIONS="auto"
$ egrep -r '^(CONTROL|ENABLE)_.*=1' /etc/laptop-mode/conf.d
/etc/laptop-mode/conf.d/auto-hibernate.conf:ENABLE_AUTO_HIBERNATION=1
/etc/laptop-mode/conf.d/terminal-blanking.conf:CONTROL_TERMINAL=1
/etc/laptop-mode/conf.d/start-stop-programs.conf:CONTROL_START_STOP=1
--jas
Now another issue:
$ sudo /etc/init.d/laptop-mode stop
[....] Disabling laptop mode...mount: /dev/cgroup/cpu is busy
done (disabled, not active).
Why is LMT messing with /dev/cgroup/cpu?
$ grep ^PARTITIONS /etc/laptop-mode/laptop-mode.conf
PARTITIONS="auto"
$ egrep -r '^(CONTROL|ENABLE)_.*=1' /etc/laptop-mode/conf.d
/etc/laptop-mode/conf.d/auto-hibernate.conf:ENABLE_AUTO_HIBERNATION=1
/etc/laptop-mode/conf.d/terminal-blanking.conf:CONTROL_TERMINAL=1
/etc/laptop-mode/conf.d/start-stop-programs.conf:CONTROL_START_STOP=1
--jas
Jasmine Hassan
Oct 21, 2012, 9:30:02 AM10/21/12
to
Also, with the patch applied:
$ sudo /etc/init.d/laptop-mode stop
[ ok ] Disabling laptop mode...done (disabled, not active [unchanged]).
$ ls -l /var/run/laptop-mode-tools/enabled
-rw-r--r-- 1 root root 0 Oct 21 15:23 /var/run/laptop-mode-tools/enabled
$ sudo /etc/init.d/laptop-mode stop
[ ok ] Disabling laptop mode...done (disabled, not active [unchanged]).
$ ls -l /var/run/laptop-mode-tools/enabled
-rw-r--r-- 1 root root 0 Oct 21 15:24 /var/run/laptop-mode-tools/enabled
$ sudo /etc/init.d/laptop-mode stop
[ ok ] Disabling laptop mode...done (disabled, not active [unchanged]).
$ ls -l /var/run/laptop-mode-tools/enabled
-rw-r--r-- 1 root root 0 Oct 21 15:23 /var/run/laptop-mode-tools/enabled
$ sudo /etc/init.d/laptop-mode stop
[ ok ] Disabling laptop mode...done (disabled, not active [unchanged]).
$ ls -l /var/run/laptop-mode-tools/enabled
-rw-r--r-- 1 root root 0 Oct 21 15:24 /var/run/laptop-mode-tools/enabled
Ritesh Raj Sarraf
Oct 23, 2012, 5:10:01 AM10/23/12
to
Hello Jasmine,
Please see responses in-line.
On Sunday 21 October 2012 04:13 PM, Jasmine Hassan wrote:
> On Sun, Oct 21, 2012 at 11:07 AM, Ritesh Raj Sarraf <r...@researchut.com> wrote:
>> The problem seemed to be caused because we were exiting if LMT was disabled
>> in the config file. Attached patch should help improve your use case.
>>
> Yes, that is one of the problems. If I may suggest, to be more user-proof:
> change:
> echo "$ENABLE_LAPTOP_MODE" |grep y
> to:
> echo "$ENABLE_LAPTOP_MODE" | egrep -i "(y|1)"
Done. THanks.
reference of it being installed in the distro-neutral install.sh file also.
> I had more issues with the default udev rules file added by LMT.
> For that, I had overridden it in
> /etc/udev/rules.d/99-laptop-mode.rules, with comments, as I intended
> to report this to you as well (way back) and totally forgot.
>
> # /lib/udev/power-lmt-udev runs both lmt & pm-powersave
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0",
> RUN+="/lib/udev/power-lmt-udev"
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1",
> RUN+="/lib/udev/power-lmt-udev"
>
> # Laptop-mode-tools default rules below, and reasons for disabling them
>
> # This generates 2 events, running script(s) twice. No good!
I am aware that udev generates too many events for the same subsystem.
Not just that, imagine different subsystems (power, hardware etc)
generating events that interest LMT, all at one go. We do not want to
honor every event.
The way LMT works, at any given time it will only honor 2 events in a
window on 10 seconds. There are 2 locks that LMT uses. A request lock
and an invocation lock. Every invocation first needs to acquire the
request lock, then try to acquire the invocation lock for the actual
invocation. When the invocation lock is acquired, the request lock is
released to honor further events. But only 2 locks. While the 1st event
is busy with the invocation lock and the 2nd events has acquired the
request lock, no further events will work. They will try to acquire the
request lock and fail.
>
> => LMT is also adding hooks for acpid in /etc/acpi/(actions|events)
> and hooks for upower in (/etc/power/scripts.d|events.d) and even hooks
> for the antiquated apmd in /etc/apm/event.d/ , even though it's not
> even installed on my system.
>
> i.e. All over the place. This caused me some grief.
> udev+acpid+upowerd. Quite excessive I must say.
> I had to edit each of the three lm_* files in /etc/acpi/events/, and
> comment out the two lines in each of them.
Yes. That's because we have multiple ways of being invoked. We started
with acpid, then later added support for pm-utils resume, and now are
totally independent with the help of udev. But we don't want to break
compatibility with older tools.
On my box, both acpid and pm-utils are uninstalled. I don't see this to
be a problem. Even if they are installed, like I mentioned above, not
all invocations will be honored.
>
> So, can't this be better managed via a postinst script? Say it would:
> 1. detect available facilities (pm-utils/udev/acpid/upowerd/apmd),
> pick one and only one, based on an ordered LMT preference list. Warn
> the user if none of the recommended facilities are installed/enabled.
> This could be later fixed by the user via dpkg-reconfigure
> laptop-mode-tools, or whatever.
What about scenarios where acpid/pm-utils etc are installed after LMT ?
Also, as upstream, it is simpler to just install the hooks and let the
installed daemons do the interpretation.
> 2. create symlinks to a common startup directory, say
> /usr/share/laptop-mode-tools/startup-hooks/*, for event/script hooks
> applicable to the chosen, available facility.
>
>> With ENABLE_LMT=1, we get
>>
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode enabled
>> active [unchanged]
> N.B. in my pre-last email I attached a little patch that amends this
> output. I really disliked getting two separate lines for each LMT
> invocation in my pm-* logs, for only a few words.
I will fix this.
>> With "enabled" file removed, it shows:
>>
>> rrs@champaran:~$ sudo rm /var/run/laptop-mode-tools/enabled
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>>
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode
>> disabled,
>> not active [unchanged]
>>
>> So it just disabled LMT because it was not "enabled".
>>
>>
>> And if "enabled" is set again, things go right.
>>
>> rrs@champaran:~$ sudo touch /var/run/laptop-mode-tools/enabled
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>>
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode
>> enabled, active
>>
> Doesn't this fundamentally conflict with the purpose of "auto"?
> Per the laptop_mode man-page:
> auto Enable or disable laptop mode based on the current power
> state. Note that this will not do anything if the laptop-mode service
> has not been started!
I would prefer this change some time. The init service assumption is not
serving much.
>> There are 2 items to fix.
>>
>> * Invocation
>> * Status
>>
>> If you have time, you can review the patch and do some tests. Let me know.
>>
> And laptop_mode cleanups.. At the very least, lots of very old,
> deprecated "backwards-compatibility" stuff needs to go.
>
> I'm sorry, but overall, I really don't like the current state of LMT.
> And although I have all power-management stuff scripted in a pm-utils
> power.d script, I still find LMT useful for the disabling of
> data-sensitive feature and the (system-level) auto-hibernate at
> configurable low and critical battery levels (without polling)
> feature.
>
> LMT needs much more love than the patch you propose.
>
> Hope I'm not being too harshly critical.
>
>
:-)
Not really. If you have the interest, you can submit a patch too.
Please see responses in-line.
On Sunday 21 October 2012 04:13 PM, Jasmine Hassan wrote:
> On Sun, Oct 21, 2012 at 11:07 AM, Ritesh Raj Sarraf <r...@researchut.com> wrote:
>> The problem seemed to be caused because we were exiting if LMT was disabled
>> in the config file. Attached patch should help improve your use case.
>>
> Yes, that is one of the problems. If I may suggest, to be more user-proof:
> change:
> echo "$ENABLE_LAPTOP_MODE" |grep y
> to:
> echo "$ENABLE_LAPTOP_MODE" | egrep -i "(y|1)"
>
> Though, there's no /etc/default/laptop-mode installed on debian by LMT 1.61-1
Yes. I noticed that too. It seems to be an old leftover. And I see no
> Though, there's no /etc/default/laptop-mode installed on debian by LMT 1.61-1
reference of it being installed in the distro-neutral install.sh file also.
> I had more issues with the default udev rules file added by LMT.
> For that, I had overridden it in
> /etc/udev/rules.d/99-laptop-mode.rules, with comments, as I intended
> to report this to you as well (way back) and totally forgot.
>
> # /lib/udev/power-lmt-udev runs both lmt & pm-powersave
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0",
> RUN+="/lib/udev/power-lmt-udev"
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1",
> RUN+="/lib/udev/power-lmt-udev"
>
> # Laptop-mode-tools default rules below, and reasons for disabling them
>
> # This generates 2 events, running script(s) twice. No good!
Not just that, imagine different subsystems (power, hardware etc)
generating events that interest LMT, all at one go. We do not want to
honor every event.
The way LMT works, at any given time it will only honor 2 events in a
window on 10 seconds. There are 2 locks that LMT uses. A request lock
and an invocation lock. Every invocation first needs to acquire the
request lock, then try to acquire the invocation lock for the actual
invocation. When the invocation lock is acquired, the request lock is
released to honor further events. But only 2 locks. While the 1st event
is busy with the invocation lock and the 2nd events has acquired the
request lock, no further events will work. They will try to acquire the
request lock and fail.
>
> => LMT is also adding hooks for acpid in /etc/acpi/(actions|events)
> and hooks for upower in (/etc/power/scripts.d|events.d) and even hooks
> for the antiquated apmd in /etc/apm/event.d/ , even though it's not
> even installed on my system.
>
> i.e. All over the place. This caused me some grief.
> udev+acpid+upowerd. Quite excessive I must say.
> I had to edit each of the three lm_* files in /etc/acpi/events/, and
> comment out the two lines in each of them.
with acpid, then later added support for pm-utils resume, and now are
totally independent with the help of udev. But we don't want to break
compatibility with older tools.
On my box, both acpid and pm-utils are uninstalled. I don't see this to
be a problem. Even if they are installed, like I mentioned above, not
all invocations will be honored.
>
> So, can't this be better managed via a postinst script? Say it would:
> 1. detect available facilities (pm-utils/udev/acpid/upowerd/apmd),
> pick one and only one, based on an ordered LMT preference list. Warn
> the user if none of the recommended facilities are installed/enabled.
> This could be later fixed by the user via dpkg-reconfigure
> laptop-mode-tools, or whatever.
Also, as upstream, it is simpler to just install the hooks and let the
installed daemons do the interpretation.
> 2. create symlinks to a common startup directory, say
> /usr/share/laptop-mode-tools/startup-hooks/*, for event/script hooks
> applicable to the chosen, available facility.
>
>> With ENABLE_LMT=1, we get
>>
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode enabled
>> active [unchanged]
> N.B. in my pre-last email I attached a little patch that amends this
> output. I really disliked getting two separate lines for each LMT
> invocation in my pm-* logs, for only a few words.
> The warning about board-specific conf is also quite annoying. What use
> is "board-specific", as a (non-existent by default) sub-directory of
> "conf.d", if "conf.d" itself already serves the purpose of a dynamic
> user-configuration-include directory? There's also no mention of it in
> the laptop-mode.conf manpage.
This one too.
> is "board-specific", as a (non-existent by default) sub-directory of
> "conf.d", if "conf.d" itself already serves the purpose of a dynamic
> user-configuration-include directory? There's also no mention of it in
> the laptop-mode.conf manpage.
>> With "enabled" file removed, it shows:
>>
>> rrs@champaran:~$ sudo rm /var/run/laptop-mode-tools/enabled
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>>
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode
>> disabled,
>> not active [unchanged]
>>
>> So it just disabled LMT because it was not "enabled".
>>
>>
>> And if "enabled" is set again, things go right.
>>
>> rrs@champaran:~$ sudo touch /var/run/laptop-mode-tools/enabled
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>>
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode
>> enabled, active
>>
> Doesn't this fundamentally conflict with the purpose of "auto"?
> Per the laptop_mode man-page:
> auto Enable or disable laptop mode based on the current power
> state. Note that this will not do anything if the laptop-mode service
> has not been started!
serving much.
>> There are 2 items to fix.
>>
>> * Invocation
>> * Status
>>
>> If you have time, you can review the patch and do some tests. Let me know.
>>
> And laptop_mode cleanups.. At the very least, lots of very old,
> deprecated "backwards-compatibility" stuff needs to go.
>
> I'm sorry, but overall, I really don't like the current state of LMT.
> And although I have all power-management stuff scripted in a pm-utils
> power.d script, I still find LMT useful for the disabling of
> data-sensitive feature and the (system-level) auto-hibernate at
> configurable low and critical battery levels (without polling)
> feature.
>
> LMT needs much more love than the patch you propose.
>
> Hope I'm not being too harshly critical.
>
>
Not really. If you have the interest, you can submit a patch too.
Ritesh Raj Sarraf
Oct 23, 2012, 5:10:02 AM10/23/12
to
On Sunday 21 October 2012 05:28 PM, Jasmine Hassan wrote:
> Ritesh,
>
> Another thing:
>
> $ /etc/init.d/laptop-mode status
> Laptop mode status:
>
> /usr/sbin/laptop_mode: 1175: /usr/sbin/laptop_mode: cannot create
> /var/lock/lmt-req.lock: Permission denied
>
> Do I really need to be root to get the status of LMT? Why are we
> creating a lock file when all we want is get the status of LMT?
Because the status output is not that of the init service. The status
> Ritesh,
>
> Another thing:
>
> $ /etc/init.d/laptop-mode status
> Laptop mode status:
>
> /usr/sbin/laptop_mode: 1175: /usr/sbin/laptop_mode: cannot create
> /var/lock/lmt-req.lock: Permission denied
>
> Do I really need to be root to get the status of LMT? Why are we
> creating a lock file when all we want is get the status of LMT?
output you see is a full blown output from LMT, for which it seeks root
permissions.
Ritesh Raj Sarraf
Oct 23, 2012, 5:20:01 AM10/23/12
to
On Sunday 21 October 2012 06:50 PM, Jasmine Hassan wrote:
> Now another issue:
>
> $ sudo /etc/init.d/laptop-mode stop
> [....] Disabling laptop mode...mount: /dev/cgroup/cpu is busy
> done (disabled, not active).
>
> Why is LMT messing with /dev/cgroup/cpu?
Can you file this as a separate issue?
> Now another issue:
>
> $ sudo /etc/init.d/laptop-mode stop
> [....] Disabling laptop mode...mount: /dev/cgroup/cpu is busy
> done (disabled, not active).
>
> Why is LMT messing with /dev/cgroup/cpu?
Some assumption about block devices have broken.
Ritesh Raj Sarraf
Oct 23, 2012, 6:40:02 AM10/23/12
to
On Sunday 21 October 2012 06:13 PM,
Jasmine Hassan wrote:
1. The first line says "Laptop mode status:", but it doesn't tell me whether LMT is active/inactive, enabled/disabled.
I checked it out. This string is printed from the init script and
not LMT itself. So here you don't see the enabled/disabled state.
Looking at how it is, it was never giving the state on that line. :-)
I want to thank you for spending time providing feedback on LMT. It really helps a lot.
I have fixed the concerns about invocation and status.
https://github.com/rickysarraf/laptop-mode-tools/blob/master/usr/sbin/laptop_mode
Please copy the laptop_mode file from the above link and overwrite it to the one in /usr/sbin/ on your box. Then you can test it out.
If you see anything missing, please continue to provide feedback.
With all these changes, it now warrants a new release. If you can provide me the feedback, I can plan a newer release soon.
On the topic of clean-up, I am open to suggestions. But please note that we do not want to break compatibility. For example, the hooks for acpid/pm-utils. If you see anything else that is redundant, I will be happy to get it cleaned up.
Thank you for your time, patience and contribution.
Ritesh
Looking at how it is, it was never giving the state on that line. :-)
I want to thank you for spending time providing feedback on LMT. It really helps a lot.
I have fixed the concerns about invocation and status.
https://github.com/rickysarraf/laptop-mode-tools/blob/master/usr/sbin/laptop_mode
Please copy the laptop_mode file from the above link and overwrite it to the one in /usr/sbin/ on your box. Then you can test it out.
If you see anything missing, please continue to provide feedback.
With all these changes, it now warrants a new release. If you can provide me the feedback, I can plan a newer release soon.
On the topic of clean-up, I am open to suggestions. But please note that we do not want to break compatibility. For example, the hooks for acpid/pm-utils. If you see anything else that is redundant, I will be happy to get it cleaned up.
Thank you for your time, patience and contribution.
Ritesh
Ritesh Raj Sarraf
Oct 25, 2012, 11:40:02 AM10/25/12
to
On Tuesday 23 October 2012 02:41 PM, Ritesh Raj Sarraf wrote:
> On Sunday 21 October 2012 06:50 PM, Jasmine Hassan wrote:
>> > Now another issue:
>> >
>> > $ sudo /etc/init.d/laptop-mode stop
>> > [....] Disabling laptop mode...mount: /dev/cgroup/cpu is busy
>> > done (disabled, not active).
>> >
>> > Why is LMT messing with /dev/cgroup/cpu?
> Can you file this as a separate issue?
>
> Some assumption about block devices have broken.
This should be fixed with what I committed today. Any feedback is welcome.
> On Sunday 21 October 2012 06:50 PM, Jasmine Hassan wrote:
>> > Now another issue:
>> >
>> > $ sudo /etc/init.d/laptop-mode stop
>> > [....] Disabling laptop mode...mount: /dev/cgroup/cpu is busy
>> > done (disabled, not active).
>> >
>> > Why is LMT messing with /dev/cgroup/cpu?
> Can you file this as a separate issue?
>
> Some assumption about block devices have broken.
https://github.com/rickysarraf/laptop-mode-tools/blob/master/usr/share/laptop-mode-tools/modules/laptop-mode
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
Jasmine Hassan
Oct 30, 2012, 8:50:02 AM10/30/12
to
Hi Ritesh,
Sorry I've been caught up. I have really been meaning to respond
sooner but couldn't. Will test ASAP (hopefully within the next couple
days) and report back.
Kindest Regards,
Jasmine
Sorry I've been caught up. I have really been meaning to respond
sooner but couldn't. Will test ASAP (hopefully within the next couple
days) and report back.
Kindest Regards,
Jasmine
0 new messages