idle/screensaver inhibition feature doesn't work reliably

Bug #448438 reported by Jeff Fortin Tam on 2009-10-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Eye of GNOME
GNOME Screensaver
Project Hamster
Fix Released
hamster-applet (Ubuntu)
Chris Coulson

Bug Description

Binary package hint: totem

Ok, this is really weird. I know that gnome-power-manager's inhibition features have been migrated over to be handled by gnome-session, and the g-p-m features for that were deprecated in gnome 2.28.

What I'm seeing here is that
- totem does seem to inhibit the screensaver (contrary to what other bug reports say), however:
- it sometimes "forgets" to release the inhibition. If you run it with --debug, you can see errors such as this one:

jeff@kusanagi:~$ totem --debug Vidéos/8-bit\ trip.mp4

(totem:4604): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Method "AllowActivation" with signature "" on interface "org.gnome.ScreenSaver" doesn't exist

** (totem:4604): WARNING **: Problem inhibiting the screensaver: Method "UnInhibit" with signature "u" on interface "org.gnome.ScreenSaver" doesn't exist

Now, I'm not sure exactly why, the inhibition sometimes seems to work, sometimes not. When it doesn't work,
- the screen will not blank anymore, the session will not go idle (and will not lock)
- if you attempt to log out of gnome, you will get a warning about totem (sometimes, multiple instances of totem!) being busy and inhibiting (while totem has only a single instance, and it is long gone).

I hope I'm clear enough and that this info is helpful. One thing that is certainly crucial to get right for Ubuntu 9.10 final is session inhibition, especially when dealing with the default video player.

ProblemType: Bug
Architecture: i386
Date: Sat Oct 10 23:08:38 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/totem
Package: totem 2.28.1-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.31-13.44-generic-pae
SourcePackage: totem
Uname: Linux 2.6.31-13-generic-pae i686

Jeff Fortin Tam (kiddo) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (

Changed in totem (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
Sebastien Bacher (seb128) wrote :

Thank you for sending the bug to GNOME

Changed in totem (Ubuntu):
status: New → Triaged
Luis Medinas (lmedinas) wrote :

I can reproduce this bug on opensuse 11.2 too. This is a upstream bug.

Jeff Fortin Tam (kiddo) wrote :

Upstream replied that they fixed the warnings in totem, and that they "couldn't reproduce the problem, but I can see how the original warning might happen. Most likely, gnome-screensaver crashed, or was killed, and the gnome-session inhibition didn't notice. gnome-screensaver is supposed to proxy to
gnome-session, and it should be transparent to users."

Bastien finished by: "File a bug against gnome-screensaver if you still see the problem."

Now the question is whether we will still be affected now that a fix for the warnings has been committed in totem, or if gnome-screensaver is still problematic, or something.

Luis, could you help doing some additional testing on this? I'm not sure how to proceed myself.

Jeff Fortin Tam (kiddo) wrote :

It also affects EoG when you use fullscreen/slideshow:

jeff@kusanagi:~$ eog Capture.png

(eog:2262): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Method "InhibitActivation" with signature "s" on interface "org.gnome.ScreenSaver" doesn't exist

** (eog:2262): WARNING **: Problem inhibiting the screensaver: Method "Inhibit" with signature "ss" on interface "org.gnome.ScreenSaver" doesn't exist

But then I'm not sure if it's the same kind of bug (probably not) and if I need to file a new launchpad report for this.

Sebastien Bacher (seb128) wrote :

do you have gnome-screensaver running?

Jeff Fortin Tam (kiddo) wrote :

Yes, along with gnome-session and gnome-power-manager.

I did some further testing, and indeed, eog causes the same kinds of problems as totem did: if you use fullscreen once, you won't have working session idling (ie: eog doesn't uninhibit, it seems) until you logout.

Jeff Fortin Tam (kiddo) wrote :

I just filed upstream, but I don't know how to retroactively link to a second upstream bug from launchpad...

Sebastien Bacher (seb128) wrote :

the fact that you get the same issue on different softwares suggests it would rather be a gnome-screensaver bug

Jeff Fortin Tam (kiddo) wrote :

Well, now I filed a third bug, hoping that it gets anywhere...

affects: totem (Ubuntu) → gnome-screensaver (Ubuntu)
Kẏra (thekyriarchy) on 2009-10-28
Changed in eog:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Responding to your list comment, the issue is not a blocker because there is only one user running into it so far you, and the bug without steps describing how to trigger the issue is not easy to work on, would still be nice to get fixed though

In the hope that it can help as per previous comment, here are some
steps for reproducing:

- in gnome-power-preferences, set the screen to blank after 1 minute of
- (optional?): in gnome-screensaver-preferences, set the session to go
idle/screensaver to activate at 1 minute

Now, logout and login (to make sure you have a clean session). Then:
1. do nothing for 2 minutes. The screen should blank. If you have
empathy running, the status should become "Away"
2. move the mouse or type something, the session becomes active again
3. to break this normal cycle, open any image (with the default image
viewer, eog), go in fullscreen (F11) or slideshow mode (F5), the message
'Method "InhibitActivation" with signature "s" on interface
"org.gnome.ScreenSaver" doesn't exist' will be printed in the terminal
if you ran it from a terminal.**
4. close eog*
5. wait as long as you want, the session will not go idle.

*: step 3 can (at the time I am writing this) be tested also by playing
any movie with totem, then exiting totem
**: for some reason, this happens on my generic desktop machine, but not
on my lpia netbook.

Jeff Fortin Tam (kiddo) wrote :

After further testing, I was able to determine that this is not
architecture/package-specific either. Creating a blank account account
on this computer, I can see that only my main account is affected, so it
must be the usual "broken/corrupt configuration" problem.

The problem is that I have no idea where to look. I have tried resetting
gnome-power-manager's gconf values, removing various folders in
~/.config, ~/.gnome2/, ~/.local/share/, etc. Advice on what to look
at/attempt would be welcome!

Is anyone here using the hamster-applet?

Changed in gnome-screensaver (Ubuntu):
status: Triaged → Incomplete
Chris Coulson (chrisccoulson) wrote :

There's likely only one issue affecting totem and eog here. Closing the eog task for now

Changed in eog:
status: Confirmed → Invalid

I've spent some time debugging this, and actually found a bug in the hamster-applet which triggers the behaviour described here. hamster-applet is watching all messages on the org.gnome.ScreenSaver interface, but doesn't handle them correctly, causing dbus to return an error even when the message is handled correctly by gnome-screensaver. See

affects: gnome-screensaver (Ubuntu) → hamster-applet (Ubuntu)
Changed in hamster-applet (Ubuntu):
status: Incomplete → Triaged
importance: Low → Medium
Changed in totem:
importance: Unknown → Undecided
status: Unknown → New
status: New → Invalid
Changed in hamster-applet (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Chris Coulson (chrisccoulson)

I often have the case that the screenblanker does not kick in if I don't use the computer, but if I touch the mouse again, it suddenly activates. Is this a separate bug to this?

Just checking the pulse here, from what I understand this has been fixed
upstream by hamster. Will the fix be backported to the karmic package?

I've built an updated hamster-applet package in the following PPA:

Please try it, along with the gnome-screensaver security update for karmic that came out a couple of days ago, and give feedback here.

If this solves the problem, I'll push it as a karmic security update.


Chris Coulson (chrisccoulson) wrote :

Marc - I had a look at the patch from upstream, and I still think it's wrong. I was going to propose a different way to handle this upstream, but haven't had a chance to look at it properly yet. hamster-applet really shouldn't be intercepting and handling messages on the org.gnome.ScreeSaver interface at all, and it still does that even with the upstream change (albeit, D-Bus doesn't return an error anymore, like it does currently)

Marc Deslauriers (mdeslaur) wrote :

I agree that hamster-applet shouldn't be doing that, and will be looking forward to your better way of handling it.

Meanwhile, the ugly fix will help with screen-locking issues, and I'd rather get something out that at least takes care of the issue sooner rather than later.

tm (toms-baugis) wrote :

I'm looking forward too.
Marc - where can i see the ugly fix you are referring to?

Chris Coulson (chrisccoulson) wrote :

Marc - Ok, I'm happy with going with the current solution in Karmic for now then, as long as it solves the issue. It also has minimal regression potential for hamster-applet.

I'll have a think about a longer term solution over the next few days though, and propose that to upstream.


tm (toms-baugis) wrote :

Chris - if you are up to the task, I can well suggest looking in two places.
First the DBUS should be able to survive invalid listeners.
Second, it might be useful that screensaver / gnome session DBUS API differentiate between a user-requested screen lock and idle timeout, because that is what hamster is trying to deduce.

Marc Deslauriers (mdeslaur) wrote :


Sorry, I didn't meant the fix was ugly, I just meant releasing an update with it is less ideal than the type of solution Chris was proposing. A bad choice of words on my part.

This is the commit I put in the test package:

> I've built an updated hamster-applet package in the following PPA:
> Please try it, along with the gnome-screensaver security update for
> karmic that came out a couple of days ago, and give feedback here.

I gave it a shot, tested with totem, hamster, fullscreen eye-of-gnome,
- screensaver
- screen blanking
- automatic suspend/sleep/whatever

...and it works! Great! :)

On a side note, I did have the impression that my netbook (also running
9.10, but not running hamster applet) also sometimes had a problem with
session idling, suggesting the possible presence of *yet another* bug on
top of all this, but maybe it was just my imagination; I am not really
qualified enough to investigate that. Time will tell, or maybe Chris
Coulson knows about "other" session idling problems?

In any case, the most visible part of this bug is fixed by the (not
optimal, but working) hamster patch.
It feels all warm and fuzzy to finally have working session idling

The updated hamster-applet from comment #21 does not seem to fix anything for me:

Still, the Screenblanker sometimes "forgets" to kick in. In these cases, the moment I move the mouse again, the screen fades out as if the Screenblanker is about to activate, but then switches back on (probably because of the mouse move).

Also, the "Lock" keyboard shortcut (Ctrl-Alt-L) does not work when a menu (e.g. in Firefox: Help Menu) is visible.

Marc Deslauriers (mdeslaur) wrote :


Those are different issues. Could you please open two new bugs for them, and we'll get them investigated.


Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hamster-applet - 2.28.0-0ubuntu1.1

hamster-applet (2.28.0-0ubuntu1.1) karmic-security; urgency=low

  * SECURITY UPDATE: broken screen-locking idle timeout (LP: #448438)
    - debian/patches/01-fix_inhibit_cookie: fix screensaver inhibit issue.
 -- Marc Deslauriers <email address hidden> Wed, 09 Dec 2009 09:26:52 -0500

Changed in hamster-applet (Ubuntu):
status: Triaged → Fix Released

Re-opening. This shouldn't be marked Fix Released as the fix is not present in Lucid.

Changed in hamster-applet (Ubuntu Karmic):
status: New → Fix Released
importance: Undecided → Medium
Changed in hamster-applet (Ubuntu):
status: Fix Released → Confirmed
summary: - idle/screensaver inhibition feature doesn't work reliably in karmic
+ idle/screensaver inhibition feature doesn't work reliably
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hamster-applet - 2.29.4-0ubuntu1

hamster-applet (2.29.4-0ubuntu1) lucid; urgency=low

  [ Robert Ancell ]
  * debian/
    - Remove old debian VCS links

  [ Andrew Starr-Bochicchio ]
  * New upstream release. (LP: #488783)
   - Fixed problems with hamster interfering with
     screensaver hibernation code. (LP: #448438)
   - Fixes to the dropdown in compiz (not spanning
     over virtual desktops anymore). (LP: #303572)

  * Merge with Debian testing, remaining Ubuntu changes:
   - Adapt debian/watch to take unstable version.
   - Point Vcs field at lp:~ubuntu-desktop/hamster-applet/ubuntu

hamster-applet (2.28.1-1) unstable; urgency=low

  * New upstream release.

hamster-applet (2.28.0-1) unstable; urgency=low

  * New upstream release.
    - Fixes to idle detection (Closes: #538790).
  * debian/
    - added a depends on python-gnome2 needed at runtime.
    - removed python-glade2 depends, it's no more needed.
  * debian/copyright:
    - added missing copyright holders.
  * debian/patches/01_startup-fix.patch:
    - this patch removes the __file__ test at startup preventing
      hamster to fail when loading needed modules.
  * debian/rules:
    - added include.
 -- Andrew Starr-Bochicchio <email address hidden> Tue, 22 Dec 2009 17:52:52 -0500

Changed in hamster-applet (Ubuntu):
status: Confirmed → Fix Released
Changed in hamster-applet:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in gnome-screensaver:
importance: Unknown → High
Changed in gnome-screensaver:
status: Unknown → Invalid
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.