Ubuntu

Does not lock screen on lid close

Reported by Andrew Aylett on 2009-09-11
118
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Session Menu
Medium
Unassigned
gnome-power-manager (Ubuntu)
High
Martin Pitt
Karmic
High
Martin Pitt
gnome-session (Ubuntu)
High
Ubuntu Desktop Bugs
Karmic
High
Ubuntu Desktop Bugs
indicator-session (Ubuntu)
High
Canonical Desktop Experience Team
Karmic
High
Canonical Desktop Experience Team

Bug Description

Binary package hint: gnome-power-manager

Since a recent update to Karmic, my laptop doesn't lock when exiting suspend or when the lid is lifted. Both worked fine in Jaunty and in Karmic up to a few days ago (I've been updating more than weekly). The laptop appears to correctly blank the screen when the lid is shut and it does suspend (although I have an issue with using my hardware button to activate suspend, bug to follow).

ProblemType: Bug
Architecture: i386
Date: Fri Sep 11 21:44:01 2009
DistroRelease: Ubuntu 9.10
Package: gnome-power-manager 2.27.92-0ubuntu1
ProcEnviron:
 LANGUAGE=en_GB.utf8
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=en_GB.UTF8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: gnome-power-manager
Uname: Linux 2.6.31-10-generic i686

Andrew Aylett (andrew-aylett) wrote :
tags: added: regression-potential
Brian Murray (brian-murray) wrote :

I experienced this bug using gnome-power-manger version 2.27.92-0ubuntu1 in karmic. I built the previous version of the package, version 2.27.91-0ubuntu1, and installed it. Using that version of the package the bug no longer occurs, the gconf settings with both version of the package installed were the same.

Changed in gnome-power-manager (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
importance: Undecided → High
status: New → Triaged
Martin Pitt (pitti) on 2009-09-21
Changed in gnome-power-manager (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti)
Martin Pitt (pitti) on 2009-09-21
Changed in gnome-power-manager (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-power-manager - 2.28.0-0ubuntu1

---------------
gnome-power-manager (2.28.0-0ubuntu1) karmic; urgency=low

  * New upstream release:
    - Use accessor functions instead direct access.
    - Only print the DeviceKit-power device data when debugging.
    - Use the correct interface name for DeviceKit-disks.
    - Use the correct gnome-screensaver path. (LP: #428115)
    - Use g_ptr_array_unref() in more places, which also fixes a few small
      memory leaks.
    - Comment out the AuthRequest signal handling.
    - Change the default of show_actions_in_menu to FALSE.
    - Inhibit applet now will inhibit the session from being marked IDLE.
      Gnome #593800.
    - Many translation updates.

 -- Martin Pitt <email address hidden> Mon, 21 Sep 2009 16:04:07 +0200

Changed in gnome-power-manager (Ubuntu):
status: Fix Committed → Fix Released
Changed in gnome-session (Ubuntu):
importance: Undecided → High
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
Changed in gnome-session (Ubuntu):
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-session - 2.28.0-0ubuntu1

---------------
gnome-session (2.28.0-0ubuntu1) karmic; urgency=low

  * New upstream version:
    - Trivial code fixes
    - Lock the screen before hibernate/suspend (lp: #428115)
  * debian/patches/98_autotools.patch:
    - new version update

  [ Chris Coulson ]
  * debian/patches/97_fix_query_end_session_crash.patch:
    - Don't crash on XSMP clients which don't respond to SaveYourself
      within the timeout, and which don't have a SmProgram property set
      (lp: #408481, #432692, #433302)

 -- Sebastien Bacher <email address hidden> Tue, 22 Sep 2009 00:39:18 +0200

Changed in gnome-session (Ubuntu):
status: Fix Committed → Fix Released
Daniel Lee (longinus00) wrote :

apt-cache shows me as having gnome-session and gnome-power-manager 2.28.0-0ubuntu1 installed but I still get taken directly to my desktop when resuming.

Daniel Lee [2009-09-22 16:20 -0000]:
> apt-cache shows me as having gnome-session and gnome-power-manager
> 2.28.0-0ubuntu1 installed but I still get taken directly to my desktop
> when resuming.

Did you restart your session after the upgrade?

I have the same problem here and have restarted the whole system.

unggnu (unggnu) wrote :

Ok, I have found the reason. If I suspend the system through closing lid the system is locked properly but if I use the indicator-applet no screensaver/locking is initiated.

Sebastien Bacher (seb128) wrote :

thank you for the update, indicator-session probably needs to be updated too

Changed in indicator-session (Ubuntu):
importance: Undecided → High
Changed in indicator-session (Ubuntu Karmic):
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
unggnu (unggnu) wrote :

I have found another problem. It is not only the indicator applet, if the system goes to sleep after x minutes because of the gnome-power-manager setting the screen is also not locked.
It seems that only the lid close and sleep button function seem to lock the system.

Ted Gould (ted) wrote :

This seems to be caused by the fact that in Jaunty we asked GNOME Power to suspend for us but now we're using DeviceKit-power (which is good) but it's not handling the desktop side of things for us. So it seems we should be locking the screen now.

Changed in indicator-session:
importance: Undecided → Medium
milestone: none → ubuntu-9.10-beta-freeze
status: New → Confirmed
Noel J. Bergman (noeljb) wrote :

FWIW, the indicator-session lock menu item does work for me, as does the Fn-F2 (lock) button, lid close (recently fixed again), etc.

unggnu (unggnu) wrote :

@Noel J. Bergman
The indicator session lock menu works but the screen is not locked if you use the suspend function of this applet.

Ted Gould (ted) on 2009-09-24
Changed in indicator-session:
milestone: ubuntu-9.10-beta-freeze → 0.1.5
status: Confirmed → Fix Committed
Ted Gould (ted) on 2009-09-24
Changed in indicator-session:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-session - 0.1.5-0ubuntu1

---------------
indicator-session (0.1.5-0ubuntu1) karmic; urgency=low

  * Upstream release 0.1.5 (LP: #436223)
    * PolicyKit-1 support (LP: #418643)
    * GDM User list support (LP: #422052)
    * MissionControl5 support (LP: #427643)
    * Better locking of the screensaver (LP: #428115)
  * debian/control: Adding in a libempathy-dev build dependency
    as it's now required by upstream.
  * Removing patches 01_polkit-1.patch and 99_autoreconf.patch
    as they were merged upstream.

 -- Ted Gould <email address hidden> Thu, 24 Sep 2009 17:07:51 -0500

Changed in indicator-session (Ubuntu Karmic):
status: New → Fix Released
unggnu (unggnu) wrote :

The problem still appears if standby is initiated through the gnome shut down menu under System and through gnome-power-manager after x minutes absence.

Changed in gnome-power-manager (Ubuntu Karmic):
status: Fix Released → Confirmed
Dave Gilbert (ubuntu-treblig) wrote :

For me this appears to be working as of about today - so maybe that fix did it

Bart Rose (jbrose3) wrote :

My Acer Aspire One will return from suspend locked if suspended via the indicator applet, but not if through lid closure. My packages are up to date and I have restarted today.

Martin Pitt (pitti) wrote :

Please copy&paste the output of

  gconftool -R /apps/gnome-power-manager/buttons

Thanks!

Changed in gnome-power-manager (Ubuntu Karmic):
status: Confirmed → Incomplete
Bart Rose (jbrose3) wrote :

Here you go:

 lid_battery = suspend
 hibernate = hibernate
 suspend = suspend
 lid_ac = suspend
 power = interactive

Martin Pitt (pitti) wrote :

I cannot reproduce this. On current Karmic, when I close the lid and reopen it again, it resumes and I get the gnome-screensaver lock dialog. Bart, do you have anything in ~/.xsession-errors after a lid close/open? Can you please attach it?

Martin Pitt (pitti) wrote :

I also got confirmation from mat_t that it works for him as well.

Martin Pitt (pitti) wrote :

Bart, can you please confirm with "dpkg -l gnome-power-manager|cat" that you have 2.28.0 installed? 2.27.x was known broken.

Bart Rose (jbrose3) wrote :

Here is my .xsession-errors output following a lid closure:

** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: old state indicates that this was not a disconnect 2
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: foo_client_state_changed_cb
** (nm-applet:1660): DEBUG: going for offline with icon: notification-network-wireless-disconnected
** (nm-applet:1660): DEBUG: going for offline with icon: notification-network-wireless-disconnected
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: old state indicates that this was not a disconnect 1
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: old state indicates that this was not a disconnect 1
** (nm-applet:1660): DEBUG: foo_client_state_changed_cb
** (nm-applet:1660): DEBUG: going for offline with icon: notification-network-disconnected
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: old state indicates that this was not a disconnect 2
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: foo_client_state_changed_cb
** (nm-applet:1660): DEBUG: going for offline with icon: notification-network-disconnected
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: applet_common_device_state_changed
** (nm-applet:1660): DEBUG: foo_client_state_changed_cb

Here is the dpkg output:

gnome-power-manager 2.28.0-0ubuntu1

Martin Pitt (pitti) wrote :

Bart, thanks. Nothing interesting in xsession-errors then. Can you please check whether this happens for a newly created user as well? This will tell us if it's a package/hardware specific problem or a problem in the per-user configuration.

Bart Rose (jbrose3) wrote :

Logging in as new user didn't fix the issue. Still no lockscreen.

JanG (jan-ge) wrote :

For me, there is nothing fixed. Using indicator-session -> hibernate and turning back on brings me directly to the desktop, even if i have activated locking the screen in screensaver settings.
Or is this the same as https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/436724 as I have auto-login enabled?

Packages are up-to-date karmic:
gnome-power-manager: 2.28.0-0ubuntu2
indicator-session: 0.1.6-0ubuntu1

$ gconftool -R /apps/gnome-power-manager/buttons
 lid_battery = blank
 hibernate = hibernate
 suspend = suspend
 lid_ac = nothing
 power = interactive

Sebastien Bacher (seb128) wrote :

> Using indicator-session -> hibernate and turning back on brings me directly to the desktop, even if i have activated locking the screen in screensaver settings.

The bug is about suspend, hibernate is a different case and could use a different bug

Daniel Lee (longinus00) wrote :

My computer still doesn't lock when suspending if I use the interactive chooser when I push the power button.

JanG (jan-ge) wrote :

>The bug is about suspend, hibernate is a different case and could use
> a different bug

Sorry, I meant suspend!
With gdm auto-login disabled this is working for me, so bug #436724 is the right one for my problem.

I updated the bug title. In this report, let's track the missing screen locking on lid close when using gdm autologin. Please file (or lookfor) separate reports for other cases, like the indicator or the power button dialog, otherwise it becomes too hard to track.

Thanks!

summary: - Computer no longer locks on suspend or lid close
+ Does not lock screen on lid close when using gdm autologin
Martin Pitt (pitti) wrote :

Please open a terminal, and do

  killall gnome-power-manager
  gnome-power-manager --verbose 2>&1 | tee /tmp/gpm.log

Then close the lid, reopen again, confirm that it suspended/resumed, but does not lock the screen. Press Control-C, and attach /tmp/gpm.log here.

Then press Alt+F2 and run "gnome-power-manager", to restore it for your session.

Thanks!

Bart Rose (jbrose3) wrote :

Here you go. Also, I'm not using autologin...

Tormod Volden (tormodvolden) wrote :

Martin, isn't locking disabled by design when using autologin? http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk/revision/45

Chris Coulson (chrisccoulson) wrote :

Tormod - locking via the inidicator is a separate issue.

Anyway, this bit of the log shows why g-p-m is not locking the screen on lid-close:

TI:16:49:01 TH:0x84d5168 FI:gpm-control.c FN:gpm_control_get_lock_policy,227
 - Using ScreenSaver settings (0)

This is because it's disabled in your user config somewhere. Please post the output of:

gconftool -R /apps/gnome-screensaver
gconftool -R /apps/gnome-power-manager/lock

Thanks!

Chris Coulson (chrisccoulson) wrote :

I suspect that your user config shows "/apps/gnome-power-manager/lock/use_screensaver_settings = TRUE" and "/apps/gnome-screensaver/lock_enabled = FALSE"

Tormod Volden (tormodvolden) wrote :

Chris, it is a separate issue, but should not the same logic apply?

Chris Coulson (chrisccoulson) wrote :

Our current default setting for "/apps/gnome-power-manager/lock/use_screensaver_settings" is "true", which means that the screen will not lock on suspend (when you close the lid) if you have disabled locking in the screensaver preferences. The log above shows that this is the most likely cause for this issue.

Perhaps we should consider changing the default, and have g-p-m use it's own policy for screen locking instead?

Bart Rose (jbrose3) wrote :

bart@AAO-Lin:~$ gconftool -R /apps/gnome-screensaver
 lock_enabled = false
 idle_activation_enabled = true
 cycle_delay = 10
 status_message_enabled = true
 mode = blank-only
 theme = screensavers-ubuntu_theme
 user_switch_enabled = true
 idle_delay = 10
 logout_delay = 120
 power_management_delay = 30
 embedded_keyboard_enabled = false
 logout_enabled = false
 embedded_keyboard_command =
 lock_dialog_theme = default
 logout_command =
 themes = []
 lock_delay = 0

bart@AAO-Lin:~$ gconftool -R /apps/gnome-power-manager/lock
 hibernate = true
 suspend = true
 gnome_keyring_hibernate = true
 blank_screen = false
 use_screensaver_settings = true
 gnome_keyring_suspend = false

Your prediction was correct. Why would this work when suspended via the indicator applet and not lid closure?

Chris Coulson (chrisccoulson) wrote :

Tormod - perhaps the same logic should apply, but the indicator applet doesn't user gnome-power-manager for suspend (it talks directly to DK-power) so it is responsible for locking the screen itself. I'm not sure what the policy is for locking the screen on suspend from the session applet, as I'm not familiar with the code (and I can't test it reliably on my machine anyway). It should probably honour user preferences too (if it doesn't already)

Chris Coulson (chrisccoulson) wrote :

Bart - thanks. So your issue is that you disabled "Lock screen when screensaver is active" in the user preferences.

This is confusing, and I think we should change use_screensaver_settings to false by default.

Bart Rose (jbrose3) wrote :

This fixed the issue, however I never changed this option. It must have been a default on the alpha version I installed. This should definitely be the default option, if it isn't already with newer versions. Thanks for the help.

Chris Coulson (chrisccoulson) wrote :

You're right, "/apps/gnome-screensaver/lock_enabled" is actually false by default (it is true in the schema, but false in /use/share/gconf/defaults/10_gnome-screensaver".

Martin Pitt (pitti) wrote :

So I close this again. The initially reported bug was fixed in comment 3, and it was determined that the people who still experience this have a local configuration which disables locking.

I verified the default settings in karmic:

 * /apps/gnome-screensaver/lock_enabled is "false" by default (locking after screen saver timeout), which still makes sense IMHO. It was like this in all previous Ubuntu releases, changing it now would be unexpected, and you can easily enable it in the screensaver settings.

 * /apps/gnome-power-manager/lock/use_screensaver_settings is also false by default, and /suspend and /hibernate are true, meaning that it does lock by default.

summary: - Does not lock screen on lid close when using gdm autologin
+ Does not lock screen on lid close
Changed in gnome-power-manager (Ubuntu Karmic):
status: Incomplete → Fix Released
Rocko (rockorequin) wrote :

I have the same settings as the default karmic, ie as outlined in comment #43, but I still don't get prompted for a password when I resume. I'm running gnome-power-manager 2.28.0-0ubuntu3.

The only unusual thing I had to do when testing is that I had to manually suspend using "sudo /etc/acpi/sleep.sh sleep" because the suspend option has disappeared in the latest karmic.

Here's my relevant configuration details - is there something else that needs changing as well?

gconftool -R /apps/gnome-power-manager/lock
 hibernate = true
 suspend = true
 gnome_keyring_hibernate = true
 blank_screen = false
 use_screensaver_settings = false
 gnome_keyring_suspend = false

gconftool -R /apps/gnome-screensaver
 lock_enabled = false
 idle_activation_enabled = true
 cycle_delay = 10
 status_message_enabled = true
 mode = blank-only
 theme = screensavers-ubuntu_theme
 user_switch_enabled = true
 idle_delay = 10
 logout_delay = 120
 power_management_delay = 30
 embedded_keyboard_enabled = false
 logout_enabled = false
 embedded_keyboard_command =
 lock_dialog_theme = default
 logout_command =
 themes = []
 lock_delay = 0

Martin Pitt (pitti) wrote :

> The only unusual thing I had to do when testing is that I had to manually suspend using "sudo /etc/acpi/sleep.sh sleep"

Right, it won't (and can't even) lock the screen with sleep.sh. Please try it with closing/reopening the lid.

> because the suspend option has disappeared in the latest karmic.

This was fixed in yesterday's gnome-session upload.

Rocko (rockorequin) wrote :

> This was fixed in yesterday's gnome-session upload.

Yes - I discovered this after rebooting (it wasn't automatically applied).

However, the problem persists. If I suspend from the System / Shut Down menu and resume, I don't get asked for a password using my normal login. I created a new user, switched to this new user, suspended and resumed and I *did* get asked for password on resume.

So what might be different between my normal user and the default settings, given that I already have the settings mentioned above? It might be relevant that I copied my normal user folder from jaunty when I first installed karmic (at around alpha 2, I think it was).

Rocko (rockorequin) wrote :

I've discovered what it is - if you suspend from user switcher applet, it locks the screen on suspend; if you remove the applet from gnome-panel and suspend from the System / Shut Down menu, it doesn't lock the screen. Should I log a separate bug for this or is it still relevant to g-p-m and this bug?

Rocko [2009-10-08 8:51 -0000]:
> I've discovered what it is - if you suspend from user switcher applet,
> it locks the screen on suspend; if you remove the applet from gnome-
> panel and suspend from the System / Shut Down menu, it doesn't lock the
> screen. Should I log a separate bug for this or is it still relevant to
> g-p-m and this bug?

Ah, this sounds like a bug in gnome-panel then. Can you please file a
new one? I suppose it's something trivial like updating the gconf keys
for current gnome-screensaver.

unggnu (unggnu) wrote :

The problem was fixed in the indicator applet but it seems to have reappeared again. Locking is enabled in gconf and I am using the indicator applet.

unggnu (unggnu) wrote :

Just wanted to confirm that it works again. I haven't changed anything so I guess it was an update.

Rob W (wilsonr0) on 2009-11-12
description: updated
Noel J. Bergman (noeljb) wrote :

I found, on a clean karmic install, that I had to do this:

# blank screen and lock on lid close
gconftool -s --type bool /apps/gnome-power-manager/lock/blank_screen true
gconftool -s --type string /apps/gnome-power-manager/buttons/lid_battery blank
gconftool -s --type string /apps/gnome-power-manager/buttons/lid_ac blank

to get the laptop to work as desired.

Daniel (daniel-jacobs) wrote :

For me the screen is NOT locked on suspend.
(It doesn't matter if pressing Fn+Esc or using indicator-applet-session!)

Comment #51 does not work for me!

My system is up to date!

Changed in gnome-power-manager (Ubuntu):
status: Fix Released → New
Changed in indicator-session (Ubuntu Karmic):
status: Fix Released → New
status: New → Fix Released
Martin Pitt (pitti) wrote :

Daniel, the bug title is "does not lock screen on lid close" (which is what g-p-m does). Also comment 51 will actually _break_ it:

  gconftool -s --type string /apps/gnome-power-manager/buttons/lid_battery blank

This configured g-p-m to _not_ suspend any more on any lid actions. I suggest to revert with

  gconftool --recursive-unset /apps/gnome-power-manager/buttons/

to restore the defaults again.

Changed in gnome-power-manager (Ubuntu):
status: New → Fix Released
Noel J. Bergman (noeljb) wrote :

@Martin, "This configured g-p-m to _not_ suspend any more on any lid actions" -- Exactly. Perhaps should discuss this on IRC rather than back-and-forth here, but as you note, "the bug title is "does not lock screen on lid close"", not "the system does not suspend on lid close." My entries in comment 51 are exactly what I am using on a clean install of Karmic, and they work perfectly. I simply want it to lock. I never want it to suspend just because I close the lid. I, in fact, *hate* that feature. Perfectly happy with how karmic works now, with those gconf entries. :-)

Martin Pitt (pitti) wrote :

Noel J. Bergman [2009-11-13 19:00 -0000]:
> @Martin, "This configured g-p-m to _not_ suspend any more on any lid
> actions" -- Exactly. Perhaps should discuss this on IRC rather than
> back-and-forth here, but as you note, "the bug title is "does not lock
> screen on lid close"", not "the system does not suspend on lid close."

Oops, sorry. Friday-evening braindeath.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers