resuming from S3 wrongly prompts for password

Bug #578542 reported by marcw on 2010-05-10
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Session Menu
Incomplete
Medium
Unassigned
Upower
Won't Fix
Medium
gnome-power
New
Medium
gnome-power-manager (Ubuntu)
Low
Phillip Susi
indicator-session (Ubuntu)
Undecided
Phillip Susi
upower (Ubuntu)
Undecided
Phillip Susi

Bug Description

Binary package hint: gnome-power-manager

Despite the gconf items
/apps/gnome-power-manager/lock/use_screensaver_settings and
/apps/gnome-power-manager/lock/suspend
both being set to false, I am still prompted for a password when resuming my workstation from S3. I do not want to be prompted. Other than this, my suspend & resume work fine.

Description: Ubuntu 10.04 LTS
Release: 10.04
32 bit
---
Architecture: i386
DistroRelease: Ubuntu 10.04
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
Lsusb:
 Bus 002 Device 002: ID 0458:0024 KYE Systems Corp. (Mouse Systems)
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 003: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NonfreeKernelModules: nvidia
Package: gnome-power-manager 2.30.0-0ubuntu1
PackageArchitecture: i386
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-24-generic-pae root=UUID=90fb6769-d9c5-44a0-9aa9-253a95e9bf49 ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-24.39-generic-pae 2.6.32.15+drm33.5
Tags: lucid
Uname: Linux 2.6.32-24-generic-pae i686
UserGroups: adm admin cdrom dialout libvirtd lpadmin mythtv plugdev sambashare vboxusers
dmi.bios.date: 02/26/2009
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FHe
dmi.board.name: M57SLI-S4
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFHe:bd02/26/2009:svn:pn:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM57SLI-S4:rvrx.x:cvn:ct3:cvr:

Related branches

Pedro Villavicencio (pedro) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please open a terminal and execute: apport-collect 578542 ? It will attach the necessary information to this report. Thanks in advance.

Changed in gnome-power-manager (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
marcw (marcw) wrote : BootDmesg.txt

apport information

tags: added: apport-collected
description: updated

apport information

apport information

marcw (marcw) wrote : DevkitPower.txt

apport information

apport information

marcw (marcw) wrote : Lspci.txt

apport information

marcw (marcw) wrote : ProcCpuinfo.txt

apport information

apport information

apport information

marcw (marcw) wrote : UdevDb.txt

apport information

marcw (marcw) wrote : UdevLog.txt

apport information

apport information

Phillip Susi (psusi) wrote :

I have observed the same thing on my laptop.

Changed in gnome-power-manager (Ubuntu):
status: Incomplete → Confirmed
marcw (marcw) wrote :

In the past couple days I've figured out a work around for this issue: I uninstalled gnome-screensaver and installed xscreensaver instead. This seems to have solved the issue. And I get better screens to boot!

Phillip Susi (psusi) wrote :

It looks like gnome-power-manager is not used to handle suspend any more. Indicator-session appears to directly lock the screen, kick off the screen saver, and ask UPower to transition the system to sleep mode. I can not see any dbus interface being exported by g-p-m to even ask it to suspend, so I guess that interface must have been removed. It does appear to still suspend when it decides the system has been idle long enough to auto suspend.

I think that the gpm interface needs put back and indicator-session needs fixed to call on it instead of handling the locking/screen saver and UPower calls itself. Either that or it needs to only call UPower, and if g-p-m wants to lock the screen then it should monitor for the Suspending signal UPower emits.

Phillip Susi (psusi) on 2011-03-19
Changed in upower (Ubuntu):
assignee: nobody → Phillip Susi (psusi)
status: New → In Progress
Changed in indicator-session (Ubuntu):
assignee: nobody → Phillip Susi (psusi)
status: New → In Progress
Changed in gnome-power-manager (Ubuntu):
assignee: nobody → Phillip Susi (psusi)
status: Confirmed → In Progress
Ted Gould (ted) wrote :

Adding an indicator-session task with it marked as "incomplete" to see if the other patches get merged as it effects how this should be accepted. I think this is the right approach, but there are a couple of dependencies here.

Changed in indicator-session:
assignee: nobody → Ted Gould (ted)
importance: Undecided → Medium
status: New → Incomplete

Created attachment 45048
Adds signal arg

In Ubuntu, we got a bug filed about how suspends initiated outside of gnome-power-manager were not locking the screen correctly.

This is because it handled locking as a result of internal methods, not as a response to the Sleeping signal from upower. Ideally it would do that instead, but first, that signal needs to have enough information for a policy agent like gnome-power-manager to determine policy.

Which means it needs to tell listeners whether the sleep is a suspend or hibernate.

We received a patch for this by Phillip Susi (attached). It simply adds an int argument to the signal. Will existing dbus listeners be confused by the addition of a new argument?

Ah, sorry, searched bugs, but didn't think about the mailing list.

What about a second signal, named "SleepingFull" or something?

SleepingFull might be best, I though perhaps Sleeping2, but both seem non-ideal. Got any better ideas?

Richard.

The only alternative to a second signal I can think of is a query method like GetCurrentSleepType(), but that's a whole 'nother round trip eating into the precious second before suspend (I don't know how much of a concern that is).

Oh, I think you meant naming ideas? SleepingWithType?

(In reply to comment #4)
> The only alternative to a second signal I can think of is a query method like
> GetCurrentSleepType(), but that's a whole 'nother round trip eating into the
> precious second before suspend (I don't know how much of a concern that is).

Eek. RTT is probably too high for that. Even setting a property might be racy, I'm not sure. A PropertyChanged signal in GDBus is run in a new thread, and I'm not sure how it works when we're using the clunky dbus-glib.

At the moment I'm erring for ::SleepingKind and ::ResumingKind as we call things kinds internally (rather than type, which upsets glib sometimes).

Michael Terry (mterry) wrote :

I filed upstream bugs with your patches, Phillip. I think upstream should probably greenlight such patches, as the new dbus signal argument will likely impact all listeners to that signal.

Changed in upower:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in gnome-power:
importance: Unknown → Medium
status: Unknown → New
Conor Curran (cjcurran) on 2011-09-01
Changed in indicator-session (Ubuntu):
status: In Progress → Incomplete
Ted Gould (ted) on 2012-09-28
Changed in indicator-session:
assignee: Ted Gould (ted) → nobody

The Sleeping signal is deprecated, and removed in my branch. We won't get a new signal.

Changed in upower:
status: Confirmed → Won't Fix
Charles Kerr (charlesk) on 2014-03-14
Changed in gnome-power-manager (Ubuntu):
status: In Progress → New
Changed in upower (Ubuntu):
status: In Progress → New
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.