g-screensaver starts after idle period, regardless of user input

i'm pretty sure this is a duplicate of #22018, can you check the dpms settings of gnome-screensaver with gconf-editor ? gconf doesnt delete user settings on upgrades, so if someone had the broken package installed early in the release cycle and changed a setting, the complete set of broken settings persists.
to get the shipped defaults, you can try to flush the user settings with:
gconftool-2 --recursive-unset /apps/gnome-screensaver

the release cycle above should indeed read development cycle :)

The only actions on the dbus are all reactive after this happens:

signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=ActiveChanged
 boolean true
signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=SessionIdleChanged
 boolean true
signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=SessionIdleChanged
 boolean false
signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=ActiveChanged
 boolean false

$ gconftool-2 -R /apps/gnome-screensaver | cut -d, -f1
 activate_delay = 10
 mode = random
 themes = [antinspect
 logout_enabled = false
 lock_enabled = false
 cycle_delay = 10
 idle_delay = 10
 dpms_standby = 60
 logout_delay = 120
 dpms_suspend = 60
 dpms_off = 120
 logout_command =
 user_switch_enabled = true
 idle_activation_enabled = true
 lock_delay = 0
 dpms_enabled = false

The screensaver popping up is occuring on both AC and battery.

$ gconftool-2 -R /apps/gnome-power-manager
 battery_brightness = 0
 ac_sleep_display = 300
 use_icon_for_desktops = false
 check_type_cpu = true
 can_hibernate = true
 lock_on_hibernate = true
 battery_sleep_computer = 0
 action_ac_button_lid = blank
 lock_on_suspend = true
 dim_on_idle = true
 lock_on_blank_screen = true
 ac_brightness = 20
 notify_hal_error = true
 display_icon_policy = always
 use_time_for_policy = true
 notify_fully_charged = true
 action_button_lid = nothing
 action_sleep_type = suspend
 action_button_suspend = nothing
 policy_suppression_timeout = 5
 battery_sleep_display = 120
 notify_ac_adapter = true
 ac_sleep_computer = 0
 action_battery_button_lid = blank
 can_suspend = true
 action_button_hibernate = hibernate
 action_battery_critical = nothing
 suppress_suspend_warning = false
 check_type_net = true
 lock_use_screensaver_settings = true
 /apps/gnome-power-manager/general:
  threshold_critical = 1
  threshold_low = 5
  display_icon_policy = always
 /apps/gnome-power-manager/policy:
  button_lid = nothing
  battery_critical = hibernate
  button_suspend = suspend
  sleep_type = suspend
  /apps/gnome-power-manager/policy/battery:
   brightness = 0
   sleep_display = 300
   sleep_computer = 1200
  /apps/gnome-power-manager/policy/ac:
   brightness = 11
   sleep_display = 1800
   sleep_computer = 0
 /apps/gnome-power-manager/notify:
  ac_adapter = true
  fully_charged = true

same problem here with version 2.13.92-0ubuntu1

This started happening around a week ago. This is on an IBM X40 laptop that I regularly suspend-to-ram. In case it matters, this bug has never ocurred on my Dapper desktop machine (which I never suspend).

my relevant gconf keys are:
 idle_delay = 5
 dpms_standby = 60
 logout_delay = 120
 dpms_suspend = 60
 dpms_off = 120

btw, that's the politest bug report I've ever seen.

The suspend (likely introducing a clock slew) maybe the key to solving this; the activiation seems to be coming internally from the main 'gnome-screensaver' process as there is no activity on the DBus that is generated externally (these are only feedback/status updates):

  signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=ActiveChanged boolean true
  signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=SessionIdleChanged boolean true
  signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=SessionIdleChanged boolean false
  signal sender=:1.3 -> dest=(null destination) interface=org.gnome.ScreenSaver; member=ActiveChanged boolean false

'src/gs-listener-dbus.c:gs_listener_set_active()' is the function called to active the screensaver, this in turn calls 'listener_set_active_internal()' immediately above it.

This is called from very few places; of which 'src/gs-monitor.c:watcher_idle_notice_cb()' is the one that's probably at fault.

This probably explains where the random fade-outs are coming from; lots of extra timers that aren't getting destoryed:

  $ grep -c 'killing idle_timer' gnome_screensaver_debug_xLIHlJ
  536
  $ grep -c 'starting idle_timer' gnome_screensaver_debug_xLIHlJ
  582

eg. Here's a snippet during/around a suspend:

  [add_idle_timer] gs-watcher-x11.c:474 (02:02:24): starting idle_timer (50000, 454)
  [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1389 (02:02:24): Idle 0 seconds
  ...
  [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1389 (02:03:08): Idle 44 seconds
  [check_for_clock_skew] gs-watcher-x11.c:1308 (02:03:08): checking wall clock for hibernation, changed: 0:00:02
  XXX this is gap of 13 seconds whilst suspended
  [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1389 (02:03:21): Idle 57 seconds
  [check_for_clock_skew] gs-watcher-x11.c:1308 (02:03:21): checking wall clock for hibernation, changed: 0:00:13
  [idle_timer] gs-watcher-x11.c:1239 (02:03:21): in idle timer
  [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1389 (02:03:21): Idle 57 seconds
  [check_for_clock_skew] gs-watcher-x11.c:1308 (02:03:21): checking wall clock for hibernation, changed: 0:00:00
  [add_idle_timer] gs-watcher-x11.c:474 (02:03:21): starting idle_timer (3000, 455)
  [watcher_idle_notice_cb] gs-monitor.c:126 (02:03:21): Idle notice signal detected: 1

The ''wall clock has jumped by ..." code never seems to notice...

BTW, this is related to the short one-second fade that is normally used for locking (but the lock dialogue is not activated).

i just added a patch from upstream CVS to 2.13.92-0ubuntu2, please check if it still occurs with this version

Bingo, here's the log from when it actually occurs:

[add_idle_timer] gs-watcher-x11.c:474 (12:11:03): starting idle_timer (590000, 6856)
[idle_timer] gs-watcher-x11.c:1239 (12:11:04): in idle timer
[_gs_watcher_check_pointer_position] gs-watcher-x11.c:1389 (12:11:04): Idle 1 seconds
[check_for_clock_skew] gs-watcher-x11.c:1308 (12:11:04): checking wall clock for hibernation, changed: 0:00:02
[watcher_idle_cb] gs-monitor.c:110 (12:11:04): Idle signal detected: 1
[gs_listener_set_session_idle] gs-listener-dbus.c:367 (12:11:04): Setting session idle: 1
[listener_check_activation] gs-listener-dbus.c:260 (12:11:04): Checking for activation
[listener_check_activation] gs-listener-dbus.c:275 (12:11:04): Trying to activate
[gs_grab_get_keyboard] gs-grab-x11.c:166 (12:11:04): Grabbing keyboard widget=4C
[gs_grab_get_mouse] gs-grab-x11.c:192 (12:11:04): Grabbing mouse widget=4C
[gs_fade_set_active] gs-fade.c:500 (12:11:04): Setting fade: ON
[_gs_watcher_check_pointer_position] gs-watcher-x11.c:1389 (12:11:04): Idle 1 seconds
[check_for_clock_skew] gs-watcher-x11.c:1308 (12:11:04): checking wall clock for hibernation, changed: 0:00:00
[gs_fade_set_active] gs-fade.c:500 (12:11:05): Setting fade: OFF
[window_map_cb] gs-manager.c:906 (12:11:05): Handling window map event
[gs_window_clear] gs-window-x11.c:220 (12:11:05): Clearing window
[clear_all_children] gs-window-x11.c:201 (12:11:05): Clearing all child windows
[window_show_cb] gs-manager.c:959 (12:11:05): Handling window show
[gs_watcher_set_active] gs-watcher-x11.c:764 (12:11:06): turning watcher: OFF
[_gs_watcher_set_active_internal] gs-watcher-x11.c:747 (12:11:06): Stopping idle watcher
[_gs_watcher_set_session_idle] gs-watcher-x11.c:546 (12:11:06): Changing idle state: 1
[gs_window_xevent] gs-window-x11.c:439 (12:11:06): not raising our windows
[window_map_event_cb] gs-manager.c:893 (12:11:06): Handling window map_event event
[gs_grab_move_keyboard] gs-grab-x11.c:328 (12:11:06): Moving keyboard grab from 4C to 2400328
[gs_grab_move_keyboard] gs-grab-x11.c:335 (12:11:06): *** doing X server grab

This is still happening as of 2006-03-23. The fade is the short (1second) fade. The screen is not locked afterwards and the fade can't be cancelled as it is happening.

Two hibernate cycles took place prior to this.

I also see this behavior - though it eventually seems to resove.

ii gnome-screensa 2.14.0-0ubuntu a screen saver and locker

Was having this problem... it appears fixed for now

Though this was fixed, happened again tonight after a hibernate. Every ten minutes without fail it activates regardless of activity. Before the hibernate it was fine.

Yup, happened to me this morning as well after a sleep.

I think I also saw this bug today, but I recently had ntpdate step my clock by an hour (daylight savings time and hardware clock non-UTC). Don't know if that has anything to do with it.

nope, thats a different one, see bug 33331

Has this been forwarded upstream yet?

I guess this is fixed upstream[1].

[1] http://bugzilla.gnome.org/show_bug.cgi?id=332576

 gnome-screensaver (2.14.0-0ubuntu3) dapper; urgency=low
 .
   * added 75_reset_emergency_lock_variable patch that (hopefully)
     solves malone #33523 (needs user feedback since i cant reproduce)

I haven't seen this problem recur in a while.

This bug occurs several times on my machine.
Latest updates of Dapper are active.
So the problem is still there

I came across this one yesterday with a fully updated Dapper installation.

you should try again, there have been a couple of new releases, and report back.

I still haven't personally seen this bug in a long time.

since you start to repeat yourself, i'll close it then ;)
everybody: feel free to reopen if it still occurs its important that this works for the release