System / Shut Down Suspend does not lock screen

Bug #446191 reported by Rocko on 2009-10-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-session (Ubuntu)
Chris Coulson
Chris Coulson

Bug Description

Binary package hint: gnome-panel

Resuming karmic after suspending via gnome-panel's "System / Shut Down - Suspend" brings you straight back into the current user session without asking for a password.

Reported as requested per

ProblemType: Bug
Architecture: amd64
Date: Thu Oct 8 17:54:32 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gnome-panel 1:2.28.0-0ubuntu3
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
SourcePackage: gnome-panel
Uname: Linux 2.6.31-12-generic x86_64

Rocko (rockorequin) wrote :
Chris Coulson (chrisccoulson) wrote :

*Sigh*, gnome-session is using "/apps/gnome-screensaver/lock_enabled" to determine whether to lock the screen or not, and this is set to false on Ubuntu. I see from that you haven't changed the preference from the default, so this won't work for you

affects: gnome-panel (Ubuntu) → gnome-session (Ubuntu)
Changed in gnome-session (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Medium
status: New → Confirmed
Rocko (rockorequin) wrote :

I think the priority on this bug should be 'high', as was (it's essentially the same problem, just in a different applet). People will expect it to lock the screen because it always has in the past, so it's a security issue - what's the point of being able to encrypt your home folder if you suspend and someone just has to open the lid to get into your data?

Changed in gnome-session:
importance: Undecided → Unknown
status: New → Unknown
Changed in gnome-session (Ubuntu):
status: Confirmed → Triaged
to be removed (liw) wrote :

I seem to have this bug as well. Suspend started locking the screen when I enabled the screensaver's locking. This is a change from jaunty, and pretty surprising. Is it always appropriate to require screensaver to lock when you want suspend to lock?

liw@havelock$ gconftool -g /apps/gnome-screensaver/lock_enabled
liw@havelock$ gconftool -g /apps/gnome-screensaver/lock_enabled

Rocko, if you enable screensaver locking, do you get locking working for suspend as well?

Rocko (rockorequin) wrote :

Yes. It's a new 'feature' in Gnome - but Chris has logged a bug for it (, so I guess we'll just have to wait.

I've changed over to using the indicator applet to suspend, but the applet takes up valuable real estate so it's not a good workaround.

Chris Coulson (chrisccoulson) wrote :

We're going to revert to the Jaunty behaviour for locking the screen on suspend, as just discussed on IRC:

(9:29:31 AM) chrisccoulson: hey pitti - do you think we should revert back to the jaunty behaviour for screen locking on suspend, and fix bug 446191 before release?
(9:29:44 AM) ubottu: Error: Could not parse data returned by Launchpad: The read operation timed out (
(9:29:57 AM) ***chrisccoulson prods launchpad again
(9:33:11 AM) pitti: chrisccoulson: read LP and upstream bug now
(9:33:28 AM) pitti: chrisccoulson: if we keep this gconf key disabled by default, we should revert, yes
(9:33:48 AM) pitti: chrisccoulson: I'm just not sure whether we shouldn't enable screensaver lock as well by default
(9:34:08 AM) pitti: chrisccoulson: my feeling is that it makes sense (as much as locking screen on suspend)
(9:34:33 AM) pitti: chrisccoulson: but at this point of the release cycle it's bad to change behaviour like that, so I agree to just reverting to jaunty g-p-m behaviour
(9:34:38 AM) chrisccoulson: yeah, i'm not sure about the default. i've always found it a bit strange that we turn the default to off
(9:34:48 AM) pitti: chrisccoulson: what would that mean technically? change gnome-session to not look at the screensaver gconf key when suspending?
(9:34:59 AM) pitti: seb128: ^ any opinion?
(9:35:09 AM) chrisccoulson: i'll work on a patch later to revert back to the jaunty behaviour then. it will involve the same logic to what is already in g-p-m
(9:35:17 AM) chrisccoulson: (i'll probably just copy and paste;))
(9:35:54 AM) chrisccoulson: that will mean that the behaviour follows g-p-m policy, which is how it used to work
(9:36:06 AM) seb128: chrisccoulson, is there a summary of jaunty and karmic behaviours?
(9:36:18 AM) seb128: I'm not sure what it used to do and what it does now
(9:36:41 AM) pitti: chrisccoulson: yes, that makes sense; so it will read g-p-m's gconf key instead of g-screensaver's?
(9:37:02 AM) chrisccoulson: seb128 - in jaunty, suspend used to be proxied through g-p-m, and the decision to lock the screen was based on g-p-m settings, which are independent of the screensaver settings in Preferences -> Screensaver
(9:37:05 AM) pitti: chrisccoulson: that's at least consistent with indicator-applet etc., so let's do that
(9:37:17 AM) chrisccoulson: cool, i'll work on that. thanks!
(9:37:55 AM) seb128: agreed with pitti
(9:38:04 AM) pitti: chrisccoulson: many thanks
(9:38:05 AM) chrisccoulson: excellent, thanks:)

Changed in gnome-session (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Chris Coulson (chrisccoulson)
status: Triaged → In Progress
Martin Pitt (pitti) wrote :

FWIW, for lucid I think we should enable screen saver locking by default as well, for consistency.

Launchpad Janitor (janitor) wrote :

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

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

  * debian/patches/100_fix_xsmp_stop_crash.patch:
    - Bugzilla patch to fix a crash when calling gsm_client_stop on
      an unregistered XSMP client in the client store (LP: #437425)
  * debian/patches/101_screen_lock_on_suspend.patch:
    - Use the same logic as gnome-power-manager for deciding the "screen
      lock on suspend" policy. This restores the Jaunty behaviour rather
      than just using the screensaver settings, which is surprising for
      users (LP: #446191)

 -- Chris Coulson <email address hidden> Fri, 23 Oct 2009 12:39:15 +0200

Changed in gnome-session (Ubuntu Karmic):
status: In Progress → Fix Released
Changed in gnome-session:
status: Unknown → New
Changed in gnome-session:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.