|Summary:||ConsoleKit fails to mark session as active when resuming|
|Product:||[Fedora] Fedora||Reporter:||James Laska <jlaska>|
|Component:||ConsoleKit||Assignee:||Lennart Poettering <lpoetter>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||14||CC:||awilliam, bbartlomiej, diegoliz, ehabkost, fedora-bugs, jturner, lpoetter, matt, milan.kerslager, mildred-bug.redhat, mrlhwliberty, pbonzini, rrankin, sanjay.ankur, theo148, tr-rh, twaugh|
|Fixed In Version:||ConsoleKit-0.4.2-3.fc14||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-11-19 22:35:49 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description James Laska 2010-10-15 12:13:59 UTC
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='220.127.116.11-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.
Comment 1 James Laska 2010-10-18 13:40:06 UTC
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.
Comment 2 Adam Williamson 2010-10-25 21:15:30 UTC
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
Comment 3 Lennart Poettering 2010-10-26 14:49:23 UTC
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.
Comment 4 James Laska 2010-10-26 16:18:27 UTC
mwesten confirmed on firstname.lastname@example.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.
Comment 5 Milan Kerslager 2010-11-07 12:54:32 UTC
Workaround with changing tty works for me here too.
Comment 6 Milan Kerslager 2010-11-08 10:04:37 UTC
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.
Comment 7 Adam Williamson 2010-11-08 23:19:39 UTC
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
Comment 8 Milan Kerslager 2010-11-09 08:53:53 UTC
My system is evolutionaly updated since F9. No orphans, no problem in dependecies.
Comment 9 Howard Ning 2010-11-10 15:53:37 UTC
I also have this problem: http://forums.fedoraforum.org/showthread.php?t=253772
Comment 10 Lennart Poettering 2010-11-17 00:59:02 UTC
*** Bug 646113 has been marked as a duplicate of this bug. ***
Comment 11 Lennart Poettering 2010-11-17 01:00:49 UTC
I have reverted the patch now upstream. Will do a release with that, and then update both F14 and F15.
Comment 12 Lennart Poettering 2010-11-17 01:02:26 UTC
Also see the reopened bug with the original VT_WAITACTIVE patch: https://bugs.freedesktop.org/show_bug.cgi?id=17720
Comment 13 Fedora Update System 2010-11-17 02:35:09 UTC
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
Comment 14 Harald Hoyer 2010-11-17 10:57:05 UTC
*** Bug 653005 has been marked as a duplicate of this bug. ***
Comment 15 Harald Hoyer 2010-11-17 10:57:18 UTC
*** Bug 650955 has been marked as a duplicate of this bug. ***
Comment 16 Fedora Update System 2010-11-17 23:13:49 UTC
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
Comment 17 Matthew Truch 2010-11-19 21:16:25 UTC
*** Bug 651096 has been marked as a duplicate of this bug. ***
Comment 18 Matthew Truch 2010-11-19 21:23:11 UTC
ConsoleKit-0.4.2-3.fc14 from updates-testing does indeed fix the problems I've been having. Thanks.
Comment 19 Bartek Krawczyk 2010-11-19 22:28:33 UTC
The update solved the problem. After hibernate/restore or sleep/restore ck-list-session shows the session as ACTIVE and everything is fine.
Comment 20 Milan Kerslager 2010-11-19 22:31:58 UTC
Confirming the fix from testing repository.
Comment 21 Fedora Update System 2010-11-19 22:35:43 UTC
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.
Comment 22 Tim Waugh 2010-11-20 12:43:57 UTC
*** Bug 654701 has been marked as a duplicate of this bug. ***
Comment 23 Roy Rankin 2010-11-24 05:01:57 UTC
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
Comment 24 Milan Kerslager 2010-11-24 06:08:49 UTC
Is it reproducible? How?
Comment 25 Milan Kerslager 2010-11-24 06:10:03 UTC
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.
Comment 26 Roy Rankin 2010-11-24 23:46:03 UTC
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.
Comment 27 Milan Kerslager 2010-11-25 10:21:02 UTC
Just fill it, the component could be changed later.