Description of problem: After suspending (evening) and resuming (morning next day) my laptop, ConsoleKit fails to mark my sessions as active. This results in PackageKit failing while attempting to prompt for authorization to install package updates. Version-Release number of selected component (if applicable): * ConsoleKit-0.4.2-2.fc14.1.x86_64 * PackageKit-0.6.9-4.fc14.x86_64 How reproducible: * Noticed this several times in recent days. Steps to Reproduce: 1. Suspend laptop 2. Resume laptop (unclear whether the time delay between steps#1 and #2 is significant) 3. Attempt to install packages using PackageKit * I gather this could be any operation that requires ConsoleKit Actual results: # ck-list-sessions Session2: unix-user = '3633' realname = '(null)' seat = 'Seat1' session-type = '' active = FALSE <----- NOTE ---> x11-display = ':0' x11-display-device = '/dev/tty1' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2010-10-14T19:10:19.365930Z' login-session-id = '2' Expected results: # ck-list-sessions Session2: unix-user = '3633' realname = '(null)' seat = 'Seat1' session-type = '' active = TRUE <----- NOTE ---> x11-display = ':0' x11-display-device = '/dev/tty1' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2010-10-14T19:10:19.365930Z' login-session-id = '2' Additional info: # ck-history --log | tail 1287083295.613 type=SEAT_ACTIVE_SESSION_CHANGED : seat-id='Seat1' session-id='' 1287083373.674 type=SYSTEM_START : kernel-release='2.6.35.6-43.fc14.x86_64' boot-arguments='ro root=/dev/mapper/luks-37f7e39c-d5eb-4171-8234-269d5ccd30d6 rd_LUKS_UUID=luks-37f7e39c-d5eb-4171-8234-269d5ccd30d6 rd_LVM_LV=vg_flatline/f14_root rd_LVM_LV=vg_flatline/swap rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet' 1287083397.229 type=SEAT_ADDED : seat-id='Seat1' seat-kind=0 1287083397.289 type=SEAT_SESSION_ADDED : seat-id='Seat1' session-id='Session1' session-type='LoginWindow' session-x11-display=':0' session-x11-display-device='/dev/tty1' session-display-device='' session-remote-host-name='' session-is-local=TRUE session-unix-user=42 session-creation-time='2010-10-14T19:09:57.267585Z' 1287083397.301 type=SEAT_ACTIVE_SESSION_CHANGED : seat-id='Seat1' session-id='Session1' 1287083419.214 type=SEAT_SESSION_REMOVED : seat-id='Seat1' session-id='Session1' session-type='LoginWindow' session-x11-display=':0' session-x11-display-device='/dev/tty1' session-display-device='' session-remote-host-name='' session-is-local=TRUE session-unix-user=42 session-creation-time='2010-10-14T19:09:57.267585Z' 1287083419.308 type=SEAT_ACTIVE_SESSION_CHANGED : seat-id='Seat1' session-id='' 1287083419.366 type=SEAT_SESSION_ADDED : seat-id='Seat1' session-id='Session2' session-type='' session-x11-display=':0' session-x11-display-device='/dev/tty1' session-display-device='' session-remote-host-name='' session-is-local=TRUE session-unix-user=3633 session-creation-time='2010-10-14T19:10:19.365930Z' 1287083419.371 type=SEAT_ACTIVE_SESSION_CHANGED : seat-id='Seat1' session-id='Session2' 1287142128.115 type=SEAT_ACTIVE_SESSION_CHANGED : seat-id='Seat1' session-id='' Note the last 2 lines show the session-id no longer attached.
Note, I just resumed my laptop after being suspended for a ~ 19 hours, and the problem didn't occur. # ck-list-sessions | egrep "(active|local)" active = TRUE is-local = TRUE I'm uncertain whether length of time being suspended is the issue, or is another factor is at play. I'll continue to monitor for this issue.
see also: http://forums.fedoraforum.org/showthread.php?t=253221 http://lists.fedoraproject.org/pipermail/test/2010-October/094936.html similar reports. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think I figured it out. The recent CK versions use the new VT_WAITEVENT ioctl() to sleep for VT switches. However, that ioctl is unfixably broken. We'll investigate if somebody can find a workaround in the kernel, but I think I'll eventually have to revert the CK patch.
mwesten confirmed on test.org that changing tty's does work around the issue (see http://lists.fedoraproject.org/pipermail/test/2010-October/095010.html) > On Mon, 2010-10-25 at 21:37 -0400, mwesten wrote: > Yes, a quick CTRL-ALT-F2/CTRL-ALT-F1 does appear to take care of it too.
Workaround with changing tty works for me here too.
This bug has huge impact on F14 system. Once the user hibernate/resume, this is not possible to gain privileges through ConsoleKit so many components does not work: - package updating - software installation - USB devices mounting - running system-config-* applications - possibility to reboot, poweroff, suspend or hibernate the system - and many others... So this bug should gain more priority.
it's a somehow configuration-specific bug, because it doesn't happen to everyone (doesn't happen on the system I'm writing this on, for example). we're aware of the impact, yes. we know what ConsoleKit does. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
My system is evolutionaly updated since F9. No orphans, no problem in dependecies.
I also have this problem: http://forums.fedoraforum.org/showthread.php?t=253772
*** Bug 646113 has been marked as a duplicate of this bug. ***
I have reverted the patch now upstream. Will do a release with that, and then update both F14 and F15.
Also see the reopened bug with the original VT_WAITACTIVE patch: https://bugs.freedesktop.org/show_bug.cgi?id=17720
ConsoleKit-0.4.2-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ConsoleKit-0.4.2-3.fc14
*** Bug 653005 has been marked as a duplicate of this bug. ***
*** Bug 650955 has been marked as a duplicate of this bug. ***
ConsoleKit-0.4.2-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ConsoleKit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ConsoleKit-0.4.2-3.fc14
*** Bug 651096 has been marked as a duplicate of this bug. ***
ConsoleKit-0.4.2-3.fc14 from updates-testing does indeed fix the problems I've been having. Thanks.
The update solved the problem. After hibernate/restore or sleep/restore ck-list-session shows the session as ACTIVE and everything is fine.
Confirming the fix from testing repository.
ConsoleKit-0.4.2-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 654701 has been marked as a duplicate of this bug. ***
This may be a different issue because it is not related to restore but has many of the same symptoms. [root@vsvo-wxp-ws07 ~]# ck-list-sessions Session1: unix-user = '500' realname = 'Roy Rankin' seat = 'Seat2' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = FALSE on-since = '2010-11-23T21:27:38.309557Z' login-session-id = '1' [root@vsvo-wxp-ws07 ~]# rpm -qa |grep Cons ConsoleKit-0.4.2-3.fc14.i686 ConsoleKit-libs-0.4.2-3.fc14.i686 ConsoleKit-x11-0.4.2-3.fc14.i686
Is it reproducible? How?
As this bug is closed, you may want to open another issue. Write down what you done when the problem arice. You may then write new bug ID here.
The problem started either on upgrade to F14 last week or immediately after (no issue in F13). To reproduce use xdm and it is a hard fault. This raises the question is it an xdm or ConsoleKit issue. I because of a long standing bug in gdm where setting disable_user_list to true would not let you login, I found using xdm the least of several evils, but the bug in gdm has finally been resolved and things are now working when using it. I am happy to raise a new bug, but should it be with xdm or ConsoleKit.
Just fill it, the component could be changed later.
New bug 657979 raised