Closing the lid does not suspend the device

Thanks for the report. Please attach /var/log/repowerd.log.

The problem is that the program with dbus address :1.219 requested the "active" state for the system, i.e. it has disallowed suspend.

The program first requests the "active" state and then clears it:

2017-02-28T09:50:13.018142+01:00 ubuntu-Inspiron-3138 repowerd[1041]: UnityScreenService: dbus_requestSysState(:1.219,active,1)
2017-02-28T09:50:13.030120+01:00 ubuntu-Inspiron-3138 repowerd[1041]: UnityScreenService: dbus_requestSysState(:1.219,active,1) => 1
2017-02-28T09:50:14.484885+01:00 ubuntu-Inspiron-3138 repowerd[1041]: UnityScreenService: dbus_clearSysState(:1.219,1)

And ~10 seconds later it requests the "active" state again and never clears it after that:

2017-02-28T09:50:25.021176+01:00 ubuntu-Inspiron-3138 repowerd[1041]: UnityScreenService: dbus_requestSysState(:1.219,active,1)
2017-02-28T09:50:25.030948+01:00 ubuntu-Inspiron-3138 repowerd[1041]: UnityScreenService: dbus_requestSysState(:1.219,active,1) => 2

As mentioned in the previous comment the failure to suspend is caused by a program incorrectly holding a suspend block after it is needed. Repowerd correctly respects the block and doesn't suspend until the block is released. Do we want repowerd to act differently?

Question, does repowerd "know" there's a lid involved? (or could we make it know there's a lid involved)
If so, then in this case, I'd say: yes, since hw trigger is involved repowerd should override the client request and go to a suspend mode.

I'm open to other thoughts - but I can't imagine where a user would expect their device to not suspend with a lid being shut.

"I'm open to other thoughts - but I can't imagine where a user would expect their device to not suspend with a lid being shut."

For example when you're downloading some files in the background, or watching a video on an external screen - your laptop might be docked and closed in that case.

I am not sure if a closed lid will make the heat dissipation worse.

If it does, and the laptop didn't have good design like suspend as over-heat, then we have potential problem to burn the laptop.

> Question, does repowerd "know" there's a lid involved? (or could we make it know there's a lid involved)

It knows about the lid, so we could customize the behavior just for the lid-closing action.

> I'm open to other thoughts - but I can't imagine where a user would expect their device to not suspend with a lid being shut.

> For example when you're downloading some files in the background, or watching a video on an external screen - your laptop might be docked and closed in that case.

repowerd already handles the external display case and doesn't suspend if an external display is connected and active when the lid is closed (you can still suspend explicitly or by inactivity timeout if configured).

In other cases, whether closing the lid should respect suspend blocks is a matter of trade-offs:

+ The user won't inadvertently interrupt a critical operation that has acquired a suspend block (e.g. flashing a firmware update)
+ A suspend block is more meaningful, provides stronger guarantees
+ Better support for multiple user sessions (e.g. a non-active user is flashing firmware and the active user closes the lid)
- Broken (malicious?) apps holding suspend blocks for more than required can keep the device awake
- Closing the lid has unpredictable behavior (may or may not suspend)

An approach I have been considering for the past few days and I am warming up to:

* Closing the lid (if configured to suspend) and explicitly suspending, should not take into account blocks and should suspend unconditionally UNLESS any blocks have been requested by a privileged (euid=0) process.

* Suspending after an inactivity timeout (if configured) should always take into account suspend blocks

The differentiation is that the first case involves explicit user actions, whereas the second case does not. The "UNLESS" part in the first case allows privileged processes to force suspend blocks for very important cases (e.g. firmware updates).

For the cases the user doesn't want to suspend after closing the lid they can change the setting in the power settings dialog.

Thoughts?

There will be a setting in the power settings for the user to choose whether to suspend on lid closed or not. We should honor that setting and always spend if the user has chosen that option regardless of what software is running or who has what lock.

On Mar 22, 2017, at 6:03 AM, Alexandros Frantzis <email address hidden> wrote:

>> Question, does repowerd "know" there's a lid involved? (or could we
> make it know there's a lid involved)
>
> It knows about the lid, so we could customize the behavior just for the
> lid-closing action.
>
>> I'm open to other thoughts - but I can't imagine where a user would
> expect their device to not suspend with a lid being shut.
>
>> For example when you're downloading some files in the background, or
> watching a video on an external screen - your laptop might be docked and
> closed in that case.
>
> repowerd already handles the external display case and doesn't suspend
> if an external display is connected and active when the lid is closed
> (you can still suspend explicitly or by inactivity timeout if
> configured).
>
> In other cases, whether closing the lid should respect suspend blocks is
> a matter of trade-offs:
>
> + The user won't inadvertently interrupt a critical operation that has acquired a suspend block (e.g. flashing a firmware update)
> + A suspend block is more meaningful, provides stronger guarantees
> + Better support for multiple user sessions (e.g. a non-active user is flashing firmware and the active user closes the lid)
> - Broken (malicious?) apps holding suspend blocks for more than required can keep the device awake
> - Closing the lid has unpredictable behavior (may or may not suspend)
>
> An approach I have been considering for the past few days and I am
> warming up to:
>
> * Closing the lid (if configured to suspend) and explicitly suspending,
> should not take into account blocks and should suspend unconditionally
> UNLESS any blocks have been requested by a privileged (euid=0) process.
>
> * Suspending after an inactivity timeout (if configured) should always
> take into account suspend blocks
>
> The differentiation is that the first case involves explicit user
> actions, whereas the second case does not. The "UNLESS" part in the
> first case allows privileged processes to force suspend blocks for very
> important cases (e.g. firmware updates).
>
> For the cases the user doesn't want to suspend after closing the lid
> they can change the setting in the power settings dialog.
>
> Thoughts?
>
> --
> You received this bug notification because you are a member of Ubuntu
> Phablet Team, which is subscribed to repowerd in Ubuntu.
> https://bugs.launchpad.net/bugs/1668596
>
> Title:
> Closing the lid does not suspend the device
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1668596/+subscriptions

This bug was fixed in the package repowerd - 2017.03+17.04.20170403-0ubuntu1

---------------
repowerd (2017.03+17.04.20170403-0ubuntu1) zesty; urgency=medium

  * 2017.03 release
    - Fix "Closing the lid does not suspend the device" (LP: #1668596)
    - Fix "messages are logged on every input event" (LP: #1674736)
    - Fix brightness issues when turning on the screen on Fairphone 2
    - Add apport hook

 -- Alexandros Frantzis <email address hidden> Mon, 03 Apr 2017 14:19:32 +0000