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
>

Reply via email to