Does not lock screen on lid close

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.

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

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

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.

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.

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

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.

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.

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

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

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

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.

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

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.

Please copy&paste the output of

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

Thanks!

Here you go:

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

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?

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

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.

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

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.

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

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

> 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

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

>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!

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!

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

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

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!

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

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

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@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?

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)

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.

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.

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".

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.

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

> 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.

> 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).

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.

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.

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

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.

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!

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.

@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. :-)

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.