laptop_mode gets executed twice on (un)plug events

On Wednesday 27 August 2014 08:07 AM, Daniel Hahler wrote:
> I have just install laptop-mode-tools, and noticed that `/usr/sbin/laptop_mode`
> gets executed twice when (un)plugging the laptop:
>
> Aug 27 04:29:05 host laptop-mode: Determining power state from /sys/class/power_supply/AC/online.
> Aug 27 04:29:05 host laptop-mode: Determining power state from /sys/class/power_supply/AC/online.
> Aug 27 04:29:05 host laptop-mode: Not trying other options, already found a power supply.
> Aug 27 04:29:05 host laptop-mode: Not trying other options, already found a power supply.
> Aug 27 04:29:05 host laptop-mode: Battery level polling is disabled.
> Aug 27 04:29:05 host laptop-mode: Battery level polling is disabled.
> Aug 27 04:29:05 host laptop-mode: Prelim lock acquisition on descriptor 8 with pid 21553
> Aug 27 04:29:05 host laptop-mode: Couldn't acquire prelim lock on descriptor 8 with pid 21554
> Aug 27 04:29:05 host laptop-mode: Prelim lock acquisition on descriptor 9 with pid 21553
> Aug 27 04:29:05 host laptop-mode: Couldn't acquire prelim lock on descriptor 9 with pid 21554
>
> That's not really a problem, since the second instance will then recognize that
> nothing needs to get changed in the end:
>
> Aug 27 04:29:06 host laptop-mode: Laptop mode
> Aug 27 04:29:06 host laptop-mode: Checking if desired state is different from current state.
> Aug 27 04:29:06 host laptop-mode: enabled, not active [unchanged]

This must be something else, given the fact that the timestamps are
same. Perhaps there are 2 logging services logging at the same time.

For LMT, Only 1 invocation of laptop-mode-tools is allowed. All further
invocations will find the lock acquired and just be ignored until the
previous acquisition of the lock is released.

--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

> This must be something else, given the fact that the timestamps are same.

Isn't this just because two processes get started simultaneously?

And one of these processes then finds that the state needs not to get changed (after waiting for the lock).

On Sunday 31 August 2014 05:41 AM, Daniel Hahler wrote:
>> This must be something else, given the fact that the timestamps are
> same.
>
> Isn't this just because two processes get started simultaneously?
>
> And one of these processes then finds that the state needs not to get
> changed (after waiting for the lock).

Actually. Yes. You are right. I went back and checked the code. That
section of the code (lmt_load_config() ) is before we acquire the lock.
So based on how many events trigger, you will see equal number of
messages. But only one among them will be allowed to proceed further.

So I see this behavior fine. Do you have a different idea on how you'd
like to see it behave ?

--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."