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
On Sun, Oct 21, 2012 at 3:20 PM, Jasmine Hassan <jasmine.a...@gmail.com>wrote:
> 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):
>
> (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
>
>
>
> On Sun, Oct 21, 2012 at 2:54 PM, Jasmine Hassan <jasmine.a...@gmail.com>wrote:
>
>> 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
>>
>> 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
>>
>>
>> On Sun, Oct 21, 2012 at 2:43 PM, Jasmine Hassan
>> <jasmine.a...@gmail.com>wrote:
>>
>>> 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
>>>>>
>>>>
>>>>
>>>
>>
>
