Description of problem: gnome-screensaver does not lock screen when active Version-Release number of selected component (if applicable): 2.26.1-2 How reproducible: Upgrade F10 to F11 Steps to Reproduce: 1. Set screensaver for 5 minutes 2. Go sleep a while (longer than 5 minutes) 3. Return and find, upon touching key(board), that screen is not locked Actual results: screen is not locked Expected results: screen is locked after timeout Additional info: gnome floating feet screensaver in use.
To be extra clear: YES the floating feet appear after 5 minutes but NO I am not asked for a password when I touch the key(board) or move the mouse after that. This is a security problem. Why was this released in this status?
I re-tested: I set the screensaver for one minute. I set the screensaver to lock the screen when going active. I waited for over one minute, not using the keyboard or mouse. NO SCREENSAVER at all. This worked in F10.
I removed gnome-screensaver. I reinstalled gnome-screensaver. No change. I ran it from the commandline: ** (gnome-screensaver:14296): WARNING **: Failed to get session presence proxy: Could not get owner of name 'org.gnome.SessionManager': no such name
Reported elsewhere as well: http://74.125.77.132/search?q=cache:V9-cq1UpQXAJ:https://fcp.surfsite.or g/modules/newbb/viewtopic.php%3Fviewmode%3Dflat%26topic_id%3D72471%26for um%3D10+gnome-screensaver+does+not+blank&cd=9&hl=nl&ct=clnk&gl=nl http://74.125.77.132/search?q=cache:Gp6HOJQbySUJ:osdir.com/ml/fedora-lis t/2009-06/msg02658.html+gnome-screensaver+does+not+blank+FEDORA&cd=4&hl= nl&ct=clnk&gl=nl
It appears that gnome-screensaver now (starting with 2.26.0) uses gnome-session to determine idle time. As long as you start gnome-session before starting gnome-screensaver the screensaver should appear and lock the screen.
gnome-session is running. gnome-session is a child of `pam: gdm-passwd`. I just updated to F11 from F10. Why should this change influence the functionality of the screensaver? How can I fix this? Or at least debug this?
Even when I restart gnome-screensaver with --debug I do not get clear errors that tell me why the saver doesn't activate: $ cat saver.log [gs_debug_init] gs-debug.c:106 (16:40:21): Debugging enabled [main] gnome-screensaver.c:87 (16:40:21): initializing gnome-screensaver 2.26.1 [init_session_id] gs-listener-dbus.c:1986 (16:40:21): Got session-id: /org/freedesktop/ConsoleKit/Session3 [gs_fade_init] gs-fade.c:689 (16:40:21): Fade type: 2 [set_status] gs-watcher-x11.c:345 (16:40:21): GSWatcher: not active, ignoring status changes [gs_watcher_set_active] gs-watcher-x11.c:275 (16:40:21): turning watcher: ON [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21): obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.97 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21): obj_path=(null) interface=(null) method=(null) destination=:1.97 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21): obj_path=(null) interface=(null) method=(null) destination=:1.97 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21): obj_path=(null) interface=(null) method=(null) destination=:1.97 [listener_service_deleted] gs-listener-dbus.c:1049 (16:40:21): DBUS service deleted: [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (16:40:21): obj_path=(null) interface=(null) method=(null) destination=:1.97 [listener_service_deleted] gs-listener-dbus.c:1049 (16:40:21): DBUS service deleted: [on_bg_changed] gs-manager.c:948 (16:40:21): background changed [listener_service_deleted] gs-listener-dbus.c:1049 (16:42:11): DBUS service deleted: [listener_service_deleted] gs-listener-dbus.c:1049 (16:42:11): DBUS service deleted: [listener_service_deleted] gs-listener-dbus.c:1049 (16:42:11): DBUS service deleted: :1.415 [listener_service_deleted] gs-listener-dbus.c:1049 (16:42:20): DBUS service deleted: :1.7 This was with the saver set for 1 minute and at least one period of inactivity lasting longer than that.
See https://bugzilla.redhat.com/show_bug.cgi?id=207966 ? Is gnome-screensaver maintained at all, you start wondering...
Created attachment 350142 [details] debug log Anything wrong to be seen in the log?
Same for me. I do not have this problem on my non x86-64 F11 installs. I have two other installs where the screensaver is behaving normally.
#10: And your gnome screensaver was OK when using Fedora 10? How to get this problem fixed or at least debugged?
Udo, Have you tried to create a new user account to see if g-screensaver locks properly with this new account? I asked because you stated you upgraded from F10 to F11, so you may have some config file from F10 that caused g-ssaver to misbehave. When I upgraded from KDE3 to KDE4, my existing config file caused KDE4 to miss letter 'e', ie. keyboard works fine except 'e' key (yes, letter 'e' is used most frequently in English). I thought it's a major bug in KDE4, but how come I was the only one saw it. Turned out to be a KDE3/4 config file incompatibility issue, with this workaround: remove ~/.kde/. On the several F11 I have, they all have g-ssaver worked fine, ie. locks ok (with password protection) at specified time. I used "new installation" for F11, not upgrade from F10, which may be the difference from you installation. g-ssaver on my F10 also locked ok. I do still have problem with g-ssaver: it locks screen, but did not turn off display as instructed by "Power Management" option. It (display off by power management) worked well in F10, but not F11.
Didn't try that but I did do an uninstall/reinstall. Where is the config for gnome-screensaver stored?
> but I did do an uninstall/reinstall. Do you mean uninstall/reinstall of the g-ssaver.rpm? I guess this does not remove your config. Gnome apps queries gconfd (/usr/libexec/gconfd-2) for config info, which is stored in ~/.gconf/ /etc/gconf/ You can probably rename both, restart gnome and see if it makes any difference. Creating a new account to test is a cleaner way for me.
Now at gnome-screensaver-2.26.1-3.fc11.x86_64, no change.
Udo, By any chance did you try the new account method? Did it make any difference? On the several F11 (32- and 64-bit) I have, g-ssaver does always lock with password.
Udo, Did you get the chance to try the new account test? If so, could you post the result? Either it works or it does not? If you don't want to try it, any reason?
hello, Same problem here: upgrade from F10 to F11 and screen saver does not ask for a password anymore. However, sytem->lock screen works. I'll try tonight the new account test to pin down the problem gnome-screensaver-2.26.1-3.fc11.i586
It works with a new user. Problem must be within the old conf not properly forward ported.
How to erase just the gnome-screensaver part of the config?
Laurent, Thanks a lot! For confirming the issue is with the old setting not properly forward ported. Udo, Earlier I stated gnome stores config in ~/.gconf, so cd ~/.gconf find | grep saver which in my case shows ./apps/gnome-screensaver/%gconf.xml which is in XML format. If you want to know exactly which entry caused the issue, which I am curious anyway, you can rename the file d=~/.gconf/apps/gnome-screensaver f=%gconf.xml mv $d/$f /tmp/ Note that g-ssaver does not read config file directly; it (or any gnome app) asks gconfd-2. So after renaming said file, you need to restart gconfd-2 and g-ssaver. The safe way I know is to log out of gnome and log in again. I guess you can kill gconfd-2 and restart, but I don't know the implication. Also note that in gnome, some settings are shared by several applications, eg. ~/.gconf/desktop/gnome/interface/%gconf.xml has "cursor_blink", which can be used by any gnome app that cares to use it. But let's be optimistic first, hoping that ~/.gconf/apps/gnome-screensaver/ is the one in question. If renaming the file works, and you are as curious as I am, you can start add items in the old config file to $d/$f and see which one caused the issue. Good luck to your adventure, and please let us know what item it is, if you find it out.
OK, this morning everything works: yesterday's update must have repaired the right(s) package(s). There were a lot of them, but here are those that could have an impact (ie remotely related in my opinion): cairo-1.8.8-1.fc11.i586 glib2-2.20.4-1.fc11.i586 compiz-gnome-0.7.8-19.fc11.i586 gnome-keyring-2.26.3-1.fc11.i586 orca-2.26.3-1.fc11.i586 policycoreutils-2.0.62-12.12.fc11.i586 pango-1.24.4-1.fc11.i586 gnome-session-2.26.2-1.fc11.i586 1:dbus-1.2.12-2.fc11.i586 gnome-panel-2.26.3-1.fc11.i586 1:gnome-applets-2.26.3-1.fc11.i586
I did move %gconf.xml to ~. I did the updates. I logged out and in. I set the screensaver for the floating feet and 1 minute. I waited 1 minute. No screensaver.
for the record: I did not touch gconf configuration, and I rebooted (due to the kernel update). My screensaver is the "picture directory" hope this helps
Maybe Udo can try what Laurent did (update to latest everything and reboot)? And see if we have better luck. Or create a new account (using system-config-users) and repeat Comment #19. Re: Comment #23 Udo, So you verified that ~/.gconf/apps/gnome-screensaver/%gconf.xml does not make a difference. If you don't want to create a new account, how about the nuclear option? mv ~/.gconf/ ~/gconf.old That is, nuke out your user setting for gnome. To play it safe, please follow this sequence: 1. logout from gnome, so you are at login screen. So we know gconfd-2 is not messing with your ~/.gconf/. 2. Press Ctrl-Alt-F2 to access tty2. 3. login as the user in question. 4. mv ~/.gconf/ ~/gconf.old 5. Press Ctrl-Alt-F1 to get back to gnome login screen. 6. Login and see how it goes.
hello, I would have added a 4.5 bullet: be sure gconfd is shutdown: ps -ef |grep gconf and kill the process if it is running
Re: Comment #26 I concur with Laurent.
Udo, Any news?
Sorry no news. I did not find a time yet to test. (busyily preparing for HAR2009) Do we have a fix or just a workaround? I do not get this from the comments.
Hmm. Logged out. Switched to a vt. Killed gconf Then had to init 3 ; init 5 Then logged in, started some stuff. Then timed 1 minute. And it appears to work. By why? I did not change anything except do updates. So who/what fixed it?
Did not log out or update aything but now the screensaver does *not* activate.
Re: Comment #30 > Then had to init 3 ; init 5 Did you try step #5 in Comment #25? 5. Press Ctrl-Alt-F1 to get back to gnome login screen.
Udo, Could you post the content of these two files? cat ~/.gconf/apps/gnome-screensaver/%gconf.xml #1 cat ~/.gconf/desktop/gnome/session/%gconf.xml #2 The content of my "good" F11 (upgraded from F10) is as attached. On you "bad" system, could you use gnome-screensaver-preferences to set your preference again and post the content of #2 again? And also please check if this causes g-ssaver to lock with passwd. In F10, g-ssaver uses #1 for "idle_delay"; In F11, g-ssaver uses #2 for "idle_delay". When upgrade from F10 to F11, the preference in #1 is not ported to #2 automatically, as pointed out by Laurent in Comment #19. "Problem must be within the old conf not properly forward ported." Content of #1,#2 in my "good" system. [timliim@taiwan ~]$ cat ~/.gconf/apps/gnome-screensaver/%gconf.xml <?xml version="1.0"?> <gconf> <entry name="themes" mtime="1250180573" type="list" ltype="string"> <li type="string"> <stringvalue>screensavers-footlogo-floaters</stringvalue> </li> </entry> <entry name="mode" mtime="1250180573" type="string"> <stringvalue>single</stringvalue> </entry> ===> <entry name="idle_delay" mtime="1249938965" type="int" value="2"/> <entry name="power_management_delay" mtime="1249938603" type="int" value="30"/> </gconf> [timliim@taiwan ~]$ cat ~/.gconf/desktop/gnome/session/%gconf.xml <?xml version="1.0"?> <gconf> ===> <entry name="idle_delay" mtime="1250180575" type="int" value="1"/> </gconf>
Re: Comment #26, #27 I checked gconfd-2 just now, by ps -ef | grep gconf A new instance is started (and old one stopped) when you log out and log in, so there is no need to kill gconfd-2 when doing test in Comment #25.
In response to #33: $ cat ~/.gconf/apps/gnome-screensaver/%gconf.xml <?xml version="1.0"?> <gconf> <entry name="themes" mtime="1249455557" type="list" ltype="string"> <li type="string"> <stringvalue>screensavers-footlogo-floaters</stringvalue> </li> </entry> <entry name="mode" mtime="1249455557" type="string"> <stringvalue>single</stringvalue> </entry> </gconf> $ cat ~/.gconf/desktop/gnome/session/%gconf.xml <?xml version="1.0"?> <gconf> <entry name="idle_delay" mtime="1248510279" type="int" value="1"/> </gconf>
Re: Comment #35 So you have a good ~/.gconf/desktop/gnome/session/%gconf.xml. But you said in Comment #31 g-ss "does *not* activate." Is this still the case? How about after rebooting your system?
did so two days ago. no change. no screensaver after the one (1!) minute I set the screensaver to.
I think I can add a bit to this as I am having the same (or similar) problem. I have found that the Screensaver (Either Gnome or xsreensaver will not lock if Ubuntu is booted from either CD or USB even if a new user is created with a password and without root privileges. I have tried this on a couple of machines - all with the same effect I have also tried all of the suggestions in this (and other)posts. It seems that Ubutnu knows when it is booted from USB/CD and (perhaps) sets a flag to indicate that the screen should not lock. If I could find this flag I could perhaps solve the problem.
Chris, Udo, Thanks for update. That's good info, the g-ssaver locking may be disabled. Looking thru g-ss code, I found in src/gs-prefs.c #define GNOME_LOCKDOWN_DIR "/desktop/gnome/lockdown" #define KEY_LOCK_DISABLE GNOME_LOCKDOWN_DIR "/disable_lock_screen" #define KEY_DIR "/apps/gnome-screensaver" #define KEY_LOCK_ENABLED KEY_DIR "/lock_enabled" Also the default values: prefs->lock_enabled = TRUE; prefs->lock_disabled = FALSE; As a test, I manually created ~/.gconf/desktop/gnome/lockdown/%gconf.xml with this content <?xml version="1.0"?> <gconf> <entry name="disable_lock_screen" mtime="1248404079" type="bool" value="true"/> </gconf> Logged out of gnome and login (so gconfd-2 reads the newly created file) And indeed, my g-ss starts in 1 minute (showing floating foots), but did _not_ ask for passwd when resumed. Udo, Chris, Could you post the result of this? cat ~/.gconf/desktop/gnome/lockdown/%gconf.xml
$ cat ~/.gconf/desktop/gnome/lockdown/%gconf.xml cat: /home/udo/.gconf/desktop/gnome/lockdown/%gconf.xml: No such file or directory
I set the screensaver for 2 minutes. I set the screensaver for 1 minutes. I killed the gnome-screensaver process. I started gnome-screensaver --debug --no-daemon, maximized the screen and waited a minute: $ gnome-screensaver --debug --no-daemon [gs_debug_init] gs-debug.c:106 (17:54:47): Debugging enabled [main] gnome-screensaver.c:87 (17:54:47): initializing gnome-screensaver 2.26.1 [init_session_id] gs-listener-dbus.c:1986 (17:54:47): Got session-id: /org/freedesktop/ConsoleKit/Session2 [gs_fade_init] gs-fade.c:689 (17:54:47): Fade type: 2 [set_status] gs-watcher-x11.c:345 (17:54:47): GSWatcher: not active, ignoring status changes [gs_watcher_set_active] gs-watcher-x11.c:275 (17:54:47): turning watcher: ON [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47): obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.847 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47): obj_path=(null) interface=(null) method=(null) destination=:1.847 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47): obj_path=(null) interface=(null) method=(null) destination=:1.847 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47): obj_path=(null) interface=(null) method=(null) destination=:1.847 [listener_service_deleted] gs-listener-dbus.c:1049 (17:54:47): DBUS service deleted: [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (17:54:47): obj_path=(null) interface=(null) method=(null) destination=:1.847 [listener_service_deleted] gs-listener-dbus.c:1049 (17:54:47): DBUS service deleted: [on_bg_changed] gs-manager.c:948 (17:54:47): background changed (after the previous line, probably related to resizing the terminal window, I did not touch the keyboard nor mouse for a minute; nothing happened)
Thanks for the reply. Tried adding the file manually but it made no difference for me. I am looking in to it this week so I will let you know how I get on. Regards Chris
Today the screensaver started working for me. xorg-x11-server-Xorg-1.6.1.901-1.fc11.x86_64.rpm xorg-x11-server-common-1.6.1.901-1.fc11.x86_64.rpm xorg-x11-utils-7.4-4.fc11.x86_64.rpm xorg-x11-server-utils-7.4-7.fc11.x86_64.rpm gnome-screensaver-2.26.1-3.fc11.x86_64
me too, works for me now
It stopped working for me now.
Killing and restarting gnome-screensaver does not restart the 'it works' sequence.
I use XFCE4 as my desktop and for some months gnome-screensaver has not been activating after the set period of inctavity. I now see that the reason is that gnome-session is not running and that gnome-screensaver will not now start without that process running. Will this be fixed for XFCE4 users? Is there any workaround?
How can we help fix, work around, etc?
I booted into 2.6.30.8 with CONFIG_EVDEV to work around the Xorg crash reported in https://bugzilla.redhat.com/show_bug.cgi?id=522936. Xorg is now at 1.6.4-0.1. Strangely gnome-screensaver now does not even activate right after a boot. See comment #48...
$ gnome-screensaver --nodaemon --debug ** (gnome-screensaver:31248): WARNING **: Unknown option --nodaemon [udo@surfplank2 ~]$ gnome-screensaver --no-daemon --debug [gs_debug_init] gs-debug.c:106 (12:56:10): Debugging enabled [main] gnome-screensaver.c:87 (12:56:10): initializing gnome-screensaver 2.26.1 [init_session_id] gs-listener-dbus.c:1986 (12:56:10): Got session-id: /org/freedesktop/ConsoleKit/Session4 [gs_fade_init] gs-fade.c:689 (12:56:10): Fade type: 2 [set_status] gs-watcher-x11.c:345 (12:56:10): GSWatcher: not active, ignoring status changes [gs_watcher_set_active] gs-watcher-x11.c:275 (12:56:10): turning watcher: ON [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10): obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.131 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10): obj_path=(null) interface=(null) method=(null) destination=:1.131 [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10): obj_path=(null) interface=(null) method=(null) destination=:1.131 [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:10): DBUS service deleted: [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10): obj_path=(null) interface=(null) method=(null) destination=:1.131 [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:10): DBUS service deleted: [listener_dbus_handle_system_message] gs-listener-dbus.c:1411 (12:56:10): obj_path=(null) interface=(null) method=(null) destination=:1.131 [on_bg_changed] gs-manager.c:948 (12:56:10): background changed [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:13): DBUS service deleted: [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:13): DBUS service deleted: [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:13): DBUS service deleted: :1.130 [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:18): DBUS service deleted: :1.7 [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:26): DBUS service deleted: [listener_service_deleted] gs-listener-dbus.c:1049 (12:56:32): DBUS service deleted: :1.7 Over here I let the system sit for a minute, the timeout for the screensaver, but nothing happened when the minute had passed.
Udo, Laurent, Could you try this? Thanks. - run g-ssaver with debug option: gnome-screensaver --no-daemon --debug - in another terminal, strace g-ssaver: pid=<pid of g-ssaver> strace -tt -e read=all -e write=all -o g-ssaver.strace -p $pid - stop the strace (ctrl-c) after 2 minutes (assume you have 1 minute g-ssaver timeout). - and post the result g-ssaver.strace. My recent observation: - g-ssaver --debug shows this line before waiting for timeout [on_bg_changed] gs-manager.c:948 (11:24:04): background changed - after 1 minute time, g-ssaver show this line [watcher_idle_notice_cb] gs-monitor.c:161 (11:25:08): Idle notice signal detected: 1 and start its fade-out/lock sequence. - In Comment #50, Comment #41, Udo's report lacks this line Idle notice signal detected: 1 and g-ssaver did not initiate its fade-out/lock sequence after timeout. - strace revealed g-ssaver received msg#1 ("StatusChanged" msg, see Appendix A) prior to printing msg#2 ("Idle notice signal detected: 1"). - In the bad case it would be helpful to find out if g-ssaver receives msg#1 or not. If it does, the issue is within g-ssaver; if not, the issue is with the entity sending msg#1, probably gnome-session. Appendix A: msgs from g-ssaver.strace (see attached file for full strace) msg#1 ("StatusChanged") ### probably this is the trigger 17:15:43.740666 read(4, "l\4\1\1\4\0\0\0"..., 2048) = 164 | 00000 6c 04 01 01 04 00 00 00 65 00 00 00 8d 00 00 00 l....... e....... | | 00010 01 01 6f 00 22 00 00 00 2f 6f 72 67 2f 67 6e 6f ..o."... /org/gno | | 00020 6d 65 2f 53 65 73 73 69 6f 6e 4d 61 6e 61 67 65 me/Sessi onManage | | 00030 72 2f 50 72 65 73 65 6e 63 65 00 00 00 00 00 00 r/Presen ce...... | | 00040 02 01 73 00 21 00 00 00 6f 72 67 2e 67 6e 6f 6d ..s.!... org.gnom | | 00050 65 2e 53 65 73 73 69 6f 6e 4d 61 6e 61 67 65 72 e.Sessio nManager | | 00060 2e 50 72 65 73 65 6e 63 65 00 00 00 00 00 00 00 .Presenc e....... | | 00070 03 01 73 00 0d 00 00 00 53 74 61 74 75 73 43 68 ..s..... StatusCh | | 00080 61 6e 67 65 64 00 00 00 08 01 67 00 01 75 00 00 anged... ..g..u.. | | 00090 07 01 73 00 04 00 00 00 3a 31 2e 30 00 00 00 00 ..s..... :1.0.... | | 000a0 03 00 00 00 .... | msg#2 ("Idle notice signal detected: 1") ### marks beginning of fade-out/lock sequence. 17:15:43.743040 write(2, "[watcher_idle_notice_cb] gs-monit"..., 86) = 86 | 00000 5b 77 61 74 63 68 65 72 5f 69 64 6c 65 5f 6e 6f [watcher _idle_no | | 00010 74 69 63 65 5f 63 62 5d 20 67 73 2d 6d 6f 6e 69 tice_cb] gs-moni | | 00020 74 6f 72 2e 63 3a 31 36 31 20 28 31 37 3a 31 35 tor.c:16 1 (17:15 | | 00030 3a 34 33 29 3a 09 20 49 64 6c 65 20 6e 6f 74 69 :43):. I dle noti | | 00040 63 65 20 73 69 67 6e 61 6c 20 64 65 74 65 63 74 ce signa l detect | | 00050 65 64 3a 20 31 0a ed: 1. |
I get: 11:11:09.636945 restart_syscall(<... resuming interrupted call ...> <unfinished ...> Nothing more than this.
Also: '[watcher_idle_notice_cb] gs-monitor.c:161' is not seen.
Upgraded to F12. For now it appears to work! May need a few more days of observation.
No problems found so far. Screen saver behaves normally.
F12 clean install. pretty much everything is default. The screensaver/xlock works normally except when are working in a VM (qemu/vnc) session window. In which case it does not lock UNTIL you release the pointer and go back to the desktop, then it activates. (I believe it also seems to activate when you work in the vm window for longer then your screensaver timeout..) (this is the default gnome desktop, and most of the gui stuff is a default install) From reading this thread, this seems to be a design flaw rather then a bug.
Any one still sees this issue, either in F11 or F12? If yes, please provide info. If not, should we close this bug? Re: Comment #52, Comment #53 Udo, Thanks for reply! Eventually I found time to debug the control flow of g-ss. Your comment #52 meant g-ss (gnome-screensaver) receives no idle notice from g-s (gnome-session), which in turn should receive idle notice from Xorg (X server). One bug I found in Xorg bug566350 Xext/sync.c IDLETIME counter sometimes fails to fire when wrapped around would prevent Xorg to send idle notice to g-s, thus g-ss no lock.
A problem persists across Fedora 11 and 12 on all 3 of my computers: x86_64 desktop machine i686 desktop machine An old DEll laptop The problem is that I use XFCE4 as my desktop, not Gnome itself. Others have the same problem running other Gnome-based desktops. Gnome screensaver is only triggered now by gnome-session. This is since Fedora 10 (or was it 9), before the change there was no problem. This bug #505915 has confused the issues about screen-locking not working and the issue that gnome-screensaver does not activate at all. These are two separate issues. I would like to have gnome-screensaver working again after so long of an absence. The screensaver should be triggered as it was previously so that users of desktops other than Gnome may benefit.
Martin, I tried XFCE4 as my desktop just now, and indeed g-ss did not kick in as you stated. I did strace on xfce4-session (which I presumed to be the counter part of gnome-session); xfce4-session (x-s) received no idle notice from Xorg (the X server), probably because x-s did not register with Xorg for idle notice. So x-s should but does not receive idle notice; isn't this a problem with x-s itself? Shouldn't we open a new bug for x-s? > The screensaver should be triggered as it was previously ... Do you mean you want gnome-screensaver (g-ss) to take two sources of idle notice (from gnome-session (g-s) and from whatever previous sources g-ss used in F10)? If so, shouldn't it be a separate enhancement bug for g-ss?
Tim, Many thanks for your very prompt response. A reasonable course of action is to determine whether fixes could be made to xfce4-session. It would be better if a fix in just one place could solve the problem but I do not have much knowledge about the inter-process communication to be of much more help. I do hope that it can be fixed because I like the picture slideshow feature of gnome-screensaver and have no wish to change from XFCE4 to Gnome.
I reported it for F12. It is the most annoying on the i686 laptop but my desktop x64 has the same issue (both F12). It is =really= bad when you have a qemu virtual machine console running in the foreground. The screensaver won't kick in until you click on a window outside of the console session. IE you can work in the qemu vm console walk away for an hour and if the qemu console was in the foreground the qemu session is still active. (if it isnt the screensaver usually kicks in.) The screensaver won't kick in until you click on a window outside the console. Once you click on something outside the qemu session it immediately kicks in. (this is all with the default gnome desktop.)
Solanum, I ran qemu console and indeed I reproduced the issue you described. I see this as a design conflict, not a g-ss issue, though. When you click on the qemu vm console, it grabs the input (mouse and keyboard): Pointer grabbed The mouse pointer has been restricted to the virtual console window. To release the pointer, press the key pair: Ctrl+Alt When g-ss activates, it also tries to grab the input, but could not: [gs_grab_get_keyboard] gs-grab-x11.c:171 (20:32:26): Grabbing keyboard widget=2800003 [gs_grab_get_keyboard] gs-grab-x11.c:186 (20:32:26): Couldn't grab keyboard! (AlreadyGrabbed) So here is the conflict: both qemu vm console and g-ss want to grab input, but only one can do it; and since g-ss is the 2nd one, g-ss will not get the grab, thus no lock. Good news for my LCD backlight is, g-p-m (gnome-power-manager) does not require grab, so it turns off my LCD backlight on time, although this does not help my laptop security. Can you live with vnc access to the vm? vnc will not do the grab, so g-ss will work as usual. Agree that this could be annoying, but I see it as an issue with qemu vm console, not with g-ss. You can register your complaint here in g-ss, but the guy in charge of qemu vm console will not see it, and thus no fix, since they are the only one who can release the input grab from qemu vm console. You should file a bug against the component "virt-manager", if it annoys you enough.
Thanks!!! I filed it as a bug with the virt-manager folks. I wasn't sure -where- the bug actually was. :)
Solanum, Glad that I can help! Just in case anyone comes to g-ss for this same issue, the bug in virt-manager is bug569830 qemu session not allowing screensaver on host os to activate
Re: Comment #60 Martin, So here is a summary of possibilities: #1 enhance xfce4-session (and any equivalent of gnome-session) so they behave like the new (F11 and later) gnome-session. That is, xxx-session registers idle alarm with Xorg (X server), and when informed of idleness, relay the info to g-ss. #2 request g-ss owner to add back its g-ss's old behavior (F10 and before). That is, in addition to receive idle notice from gnome-session (g-s), g-ss probably need to register with Xorg directly for idle alarm. The pros of #2 (according to Martin Comment #60) is, no need to change all equivalents of gnome-session. If you decide to go for #1, we need to file a bug for xfce4-session. If #2, we need to file a new enhancement bug for g-ss; I don't think #2 is related enough to be part of this bug505915. Personally I think #1 is the right way to go; but you decide what you want to do. > I like the picture slideshow feature of gnome-screensave Agree; g-ss is doing well now. I had hard time when F11 first came out.
Tim, I really do not have enough knowledge of the direction that gnome and derivative desktops are headed. I'm just a user, not a developer. If things are really headed towards standardization of xxx-session for different desktops then #1 is probably a good way to go. Solution #2 has the advantage of a fix in one place -- cut out the middle-man. A screensaver is very closely associated with the display and Xorg. I tend to favour solution #2 but, once again, I'm totally ignorant of how this all fits together. I don't know how xscreensaver is activated but it was working fine last time I used it in Fedora fc11. (xscreensaver does not have that nice slideshow of my multi-Gbyte photo collection).
Martin, I opened a bug against xfce4-session: bug570380 xfce4-session should send idle notice to gnome-screensaver Let me know if it addresses your concern. If so, we can move the discussion on x-s to bug570380. In that bug, I left the decision as to who should change to x-s and g-s folks, by saying If you believe it's g-ss that should revert its change, please negotiate with g-ss folks. They know what they are doing, so they should be able to make better decision than us. ps. yes, I also found the slideshow of g-ss a thing to enjoy.
Tim, Thanks. I don't mind how this will be resolved. I would just like g-ss to work for me again. I have a feeling that this issue was not well thought out at the beginning.
Martin, Definitely we need to move this issue to bug570380. In short, we are witnessing a war between gnome and xfce, with no resolution in sight. We probably need to pray more often :-). View from gnome (who owns g-ss): https://bugzilla.gnome.org/show_bug.cgi?id=592093#c2 2010-01-29 I'd say that the xfce session should probably do something like gnome-session. Either that or an external module that implements the same dbus interface. I don't think we are going to fix this. This is the gnome screensaver after all :) View from xfce (who borrows g-ss for its own use but complains about change in g-ss): http://bugzilla.xfce.org/show_bug.cgi?id=5927#c4 2009-10-30 Yes, it definitely suck, but there's not much one can do, exept asking for GNOME people to revert the change and stay with the X idle counter.
Can we close this bug now? - Comment #55 Udo no longer sees this issue in F12. - Comment #56 Solanum qemu-gss conflict now tracked in bug569830 - Comment #58 Martin xfce-gss conflict now tracked in bug570380 - Comment $57 Tim Liim filed bug566350 for Xext/sync.c IDLETIME counter bug Granted that the outlooks of bug569830, bug570380 are not great (everyone says someone else should fix it), but we should track separate issues in their own bugs. So I propose we close this bug now.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Re: Comment #70 Can we close this bug now?
For me it works, but for the others?
Udo, Yes, that's the reason why I kept on asking. Two months have passed since Comment #70 and no one said "I still have this issue, don't close it." Also it's not like once a bug is closed it's cemented in the underworld; people can reopen bugs, or open a new bug with reference to existing bugs, or keeping on commenting a closed bug. In your opinion, how long should we wait till we can close a bug that is no longer seen?
For me it was fixed after upgrading to F12. I saw one report that they still had the issue after upgrading to F12. Maybe wait for two different reports to confirm or deny a fix?
> I saw one report that they still had the issue after upgrading to > F12. Could you point out which Comment (or bug#) it is? > Maybe wait for two different reports to confirm or deny a fix? Agree, but I'd add "within certain time limit." How long should we wait is personal opinion, and two months is long enough for me, because this (closing a bug) is not a one-way operation; you can always undo it by reopening a bug (or by opening a new bug).
I'm still seeing this problem in Fedora 12.
Great! You proved Udo's point. Could you please run gnome-screensaver --nodaemon --debug and attach the output, as in Comment #50? Thanks!
Umm. Typo. Should be --no-daemon gnome-screensaver --no-daemon --debug
I set the idle time to 1 minute, and ran: gnome-screensaver --no-daemon --debug The results: [gs_debug_init] gs-debug.c:106 (09:32:16): Debugging enabled [main] gnome-screensaver.c:87 (09:32:16): initializing gnome-screensaver 2.28.3 [init_session_id] gs-listener-dbus.c:1979 (09:32:16): Got session-id: /org/freedesktop/ConsoleKit/Session2 [gs_fade_init] gs-fade.c:881 (09:32:17): Fade type: 3 [set_status] gs-watcher-x11.c:345 (09:32:17): GSWatcher: not active, ignoring status changes [gs_watcher_set_active] gs-watcher-x11.c:275 (09:32:17): turning watcher: ON [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus method=NameAcquired destination=:1.282 [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=(null) interface=(null) method=(null) destination=:1.282 [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=(null) interface=(null) method=(null) destination=:1.282 [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=(null) interface=(null) method=(null) destination=:1.282 [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=(null) interface=(null) method=(null) destination=:1.282 [on_bg_changed] gs-manager.c:949 (09:32:17): background changed [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:17): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:18): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:19): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:19): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:19): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:20): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:20): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:20): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:21): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:22): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:22): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:22): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:23): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:23): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:23): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:24): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:25): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:25): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:25): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:26): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:32:26): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [watcher_idle_notice_cb] gs-monitor.c:125 (09:33:27): Idle notice signal detected: 1 [gs_grab_grab_offscreen] gs-grab-x11.c:540 (09:33:27): Grabbing an offscreen window [gs_grab_get_keyboard] gs-grab-x11.c:171 (09:33:27): Grabbing keyboard widget=3A00003 [gs_grab_get_mouse] gs-grab-x11.c:206 (09:33:27): Grabbing mouse widget=3A00003 [_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:202 (09:33:28): Changing idle notice state: 1 [watcher_idle_notice_cb] gs-monitor.c:125 (09:33:28): Idle notice signal detected: 0 [watcher_idle_notice_cb] gs-monitor.c:149 (09:33:28): manager not active, performing fade cancellation [gs_fade_reset] gs-fade.c:826 (09:33:28): Resetting fade [_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:202 (09:33:28): Changing idle notice state: 0 [listener_dbus_handle_system_message] gs-listener-dbus.c:1404 (09:33:28): obj_path=/org/freedesktop/Hal/devices/computer_logicaldev_input_0 interface=org.freedesktop.Hal.Device method=Condition destination=(null) [gs_grab_release] gs-grab-x11.c:418 (09:33:29): Releasing all grabs [gs_grab_release_mouse] gs-grab-x11.c:267 (09:33:29): Ungrabbing pointer [gs_grab_release_keyboard] gs-grab-x11.c:244 (09:33:29): Ungrabbing keyboard [xorg_lock_smasher_set_active] gs-grab-x11.c:124 (09:33:29): No XFree86-Misc extension present
Regarding myself, you may close this bug
Re: Comment #80 Sean, Thanks for fast response. I see this time line in Comment #80: 09:32:16 g-ss started 09:33:27 Idle notice signal detected: 1 [start gamma fading (10 sec)] 09:33:28 Idle notice signal detected: 0 manager not active, performing fade cancellation That is, after 60 sec g-ss received idle notice and started gamma fading, which would take 10 sec. But you interrupted the fading in 1 sec, so you see no lock, which is expected and desired behavior. Could you repeat the same test, but wait at least 15 sec (ie. do not interrupt the fading). And when posting the result, please skip the "listener_dbus_handle_system_message" portion; these seems to be unrelated to our issue.
Re: Comment #81 Martin, thanks.
(In reply to comment #82) > Thanks for fast response. I see this time line in Comment #80: > 09:32:16 g-ss started > 09:33:27 Idle notice signal detected: 1 > [start gamma fading (10 sec)] > 09:33:28 Idle notice signal detected: 0 > manager not active, performing fade cancellation > > That is, after 60 sec g-ss received idle notice and started gamma > fading, which would take 10 sec. But you interrupted the fading in 1 > sec, so you see no lock, which is expected and desired behavior. I didn't touch the keyboard, mouse, etc., until long after these messages printed. Apparently something other than user activity is interrupting the fading. I repeated the test and got the same results.
Understand, that you did not touch keyboard nor mouse, but someone/ something somewhere told g-ss to stop fading because the user is no longer "idle." Did you see g-ss in action for more than a few sec? From Comment #80 I would guess g-ss kicked in and then went away in 1 sec. Is my guess correct? If so, this is a different bug than this bug505915 (Comment #1), and we should file a new bug to track this new issue. By now bug505915 has many different issues of the same symptoms crammed in and is hard to keep track. If you want to keep this issue on this bug, fine by me, but I am afraid we will bore many on the cc list.
(In reply to comment #85) > Understand, that you did not touch keyboard nor mouse, but someone/ > something somewhere told g-ss to stop fading because the user is no > longer "idle." Did you see g-ss in action for more than a few sec? > From Comment #80 I would guess g-ss kicked in and then went away in 1 > sec. Your understanding is correct. g-ss came and went in the span of about 1 second without any human intervention. > Is my guess correct? If so, this is a different bug than this > bug505915 (Comment #1), and we should file a new bug to track this new > issue. By now bug505915 has many different issues of the same > symptoms crammed in and is hard to keep track. I agree. I'll open a new bug.
(In reply to comment #86) > I agree. I'll open a new bug. See bug591750
Anyone still seeing this issue? If so, please provide info. If not, can we close this bug in two weeks?
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
For the record here is my objection to the resolution "Closed WontFix". It should be "Closed Fixed", since no one sees this issue (or bothers to say so) anymore.