Red Hat Bugzilla – Bug 181882
desktop locks immediately after changing the system clock
Last modified: 2007-11-30 17:11:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:184.108.40.206) Gecko/20060210 Fedora/220.127.116.11-3 Firefox/18.104.22.168
Description of problem:
This is a really funny bug. I changed my system clock. I accidentally set the flag "system clock uses UTC" and got the wrong time, because I set it up correctly on my FC4 installation on the same system.
After I changed this on my FC 5 Testrelease 2 installation using
and changed the time (from 9 am to 2 pm) the desktop locked because of "inactivity" for a long time.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install FC 5 Testrelease 2
2. set the system clock to use UTC select timezone New York
3. reboot the system on another partition and change the settings to use local time in timezone Europe/Berlin
4. reboot the system with the FC5 partition installed under 1
5. change the time settings to use local time and the timezone to Europe/Berlin
6. adjust the time and press ok
Most likely it is not necessary to change the time in another installation. Probably it is enough to skip steps 3 and 4 and set up the time incorrect in step 1 (so that the clock in your linux box is some hours behind the real clock)
Actual Results: The desktop locks because of inactivity
Expected Results: It should not lock
These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks
Hi, this problem still exists in fc 5 Test 3 (I detected it in FC5 Test 2 and
changed the version info to FC 5 Test 3)
I guess you set a timer and check after this timer fired if there was user
activity since setup of the timer. If it works this way you can probably avoid
this behaviour in a very simple way. Separate your timer period in two periods.
If the first is without activity then set up a second timer (maybe using a
smaller period) if there is also no activity in this period you can switch on
You probably just need to change your logic so that it waits two periods of time.
If you use a "hook" on mouse events and stuff it's similar. If you haven't
received any event during a timer period you also can setup a timer for a "last
call". If the user also doesn't do anything in this period it is pretty save to
switch the screensaver on.
If you can manage to detect clock skews, I would really like to see the
Hi sorry, I changed the status to "NEEDINFO", because I don't know what exactly
"REOPEN" means it looks like probably you haven't recognized that I still have
this problem and added some new info (see above)
*** Bug 186800 has been marked as a duplicate of this bug. ***
Just too funny. I filed it upstream:
This becomes somewhat less amusing with U.K. users entering British Summer Time
therefore clocks have jumped forward one hour.
I am seeing this on a fully updated system under FC5. I have attempted to
disable screen blanking on the power controls (following inactivity) however it
continues to blank every 20 minutes.
Upstream bug has a patch that I'm going to put into glib, we should put that in
our glib package, too.
Fixed in glib-2.12.2-2.fc6