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
On Sun, Oct 21, 2012 at 1:58 PM, Jasmine Hassan <jasmine.a...@gmail.com>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?
>
> --jas
>
>
> On Sun, Oct 21, 2012 at 12:43 PM, Jasmine Hassan
> <jasmine.a...@gmail.com>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
>>
>> > 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.
>>
>> Yes, please.
>>
>> > * 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.
>>
>> Yes, that was the initial issue I was reporting.
>>
>> > * When invoked through udev, we do not care or create the "enabled"
>> file.
>>
>> 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!
>> #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
>> > 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.
>>
>> >
>> > 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!
>>
>> >
>> > 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.
>>
>> >
>> >
>> >
>> >
>> > --
>> > Ritesh Raj Sarraf
>> > RESEARCHUT - http://www.researchut.com
>> > "Necessity is the mother of invention."
>>
>> Kind Regards,
>> Jasmine
>>
>
>
