Description of problem: /usr/bin/ck-xinit-session is not executed in /etc/X11/xdm/Xsession. It causes that audio doesn't work in session. Version-Release number of selected component (if applicable): $ rpm -q xorg-x11-xdm xorg-x11-xdm-1.1.6-3.fc9.x86_64 How reproducible: always Steps to Reproduce: 1. $ cat /etc/sysconfig/desktop DISPLAYMANAGER=XDM PREFERRED=/usr/bin/startfluxbox 2. login to X session 3. run xmms (for example) - error (pulseaudio says something about permission denial) Actual results: sound doesn't work Expected results: sound works as expected Additional info: I solved problem with attached patch in my case. I think that ck-xinit-session should be also called on other places in /etc/X11/xdm/Xsession
Changed component to xorg-x11-xinit because /etc/X11/xdm/Xsession is symlink to /etc/X11/xinit/Xsession
Created attachment 309866 [details] patch this patch solves problem in my case
Doesn't it conflict with gnome/kde having already started the session (with failsafe/custom on the command line)? Using something similar than what is done in xinitrc-common for SSH_AGENT by looking if XDG_SESSION_COOKIE is set should certainly do the trick, however. As a side note, could kdm and gdm avoid starting the consolekit session in their code but instead do like xdm? Maybe this is not possible due to fast user switching, but if it is possible it seems better than the existing code which has to find the X device. (of course something has to find the X device, but I think that it is better if it is done at only one place, in consolekit and that consolekit hides the non portable stuff). Also $CK_XINIT_SESSION should be added at all the places where SSH_AGENT is called, such that it works for display manager that call Xsession with an argument (like wdm). It is nice if it works that way, when I looked at this issue I mistakenly thought that one had to be root to start the session which lead to a rather complicated implementation.
(In reply to comment #3) > Doesn't it conflict with gnome/kde having already started the session > (with failsafe/custom on the command line)? I think no. I'm not using kde/gnome > Using something similar than what is done in xinitrc-common > for SSH_AGENT by looking if XDG_SESSION_COOKIE is set should > certainly do the trick, however. > > As a side note, could kdm and gdm avoid starting the consolekit > session in their code but instead do like xdm? I think that gdm/kdm doesn't start code inside. Main difference between gdm/kdm and xdm is that xdm starts session with /etc/X11/xdm/Xsession and kdm/xdm uses /etc/X11/xinit/xinitrc. In xinitrc is consolekit successfully started but in Xsession that command missing. > > Also $CK_XINIT_SESSION should be added at all the places where > SSH_AGENT is called, such that it works for display manager that > call Xsession with an argument (like wdm). You are absolutely right. I used attached patch as example which solves problem for me ;) When you execute ck-list-sessions inside session you have to see active CK session. If not then your audio cannot work.
(In reply to comment #4) > (In reply to comment #3) > > Doesn't it conflict with gnome/kde having already started the session > > (with failsafe/custom on the command line)? > > I think no. I'm not using kde/gnome Unless I am wrong, kdm/gdm starts the consolekit session in their code before running /etc/X11/xinit/Xsession. If custom is used, then, still unless I am wrong, the line you modify in your patch will be used but with the session already started. > > As a side note, could kdm and gdm avoid starting the consolekit > > session in their code but instead do like xdm? > > I think that gdm/kdm doesn't start code inside. They did. the kdm patch is a fedora specific patch, while it is in upstream gdm, if I'm not wrong. > Main difference between gdm/kdm > and xdm is that xdm starts session with /etc/X11/xdm/Xsession and kdm/xdm uses > /etc/X11/xinit/xinitrc. I don't think so. Since /etc/X11/xdm/Xsession is a symlink to /etc/X11/xinit/Xsession, all use that file. > In xinitrc is consolekit successfully started but in Xsession that command missing. Indeed, but it should be done carefully considering that other dm don't necessary do the same nor have the same issues.
Created attachment 311066 [details] run ck-xinit-session for all sessions where the xdg cookie isn't already set I have put a changelog entry to have a ready to use patch, it can be removed. As a side note, it is so easy that it is very strange that it hasn't been done already.
(In reply to comment #6) > Created an attachment (id=311066) [edit] > run ck-xinit-session for all sessions where the xdg cookie isn't already set works fine for me. > As a side note, it is so easy that it is very strange that it > hasn't been done already. I think this is only xdm problem and only few people using it so this problem wasn't discovered
Created attachment 311422 [details] run ck-xinit-session for all sessions where the xdg cookie isn't already set, minor fixes An updated patch that also updates to 1.0.9, otherwise there are update issues. Also other minor issues fixed (versioned obsoletes, license) and also fix Bug 413041.
(In reply to comment #7) > (In reply to comment #6) > > As a side note, it is so easy that it is very strange that it > > hasn't been done already. > > I think this is only xdm problem and only few people using it so this problem > wasn't discovered It is not really strictly xdm issue. This could be used for kdm and gdm too, avoiding having to patch the display manager, keeping modularity and putting platform specific stuff (the device detection) in only one place (consolekit) instead of in the dm which should ignore such thing and use only X. But that's just my opinion and it looks like the design of these dbus stuff is different.
This looks like the wrong solution to me, Xsession doesn't have the information the display manager has, so ConsoleKit will get provided with incomplete information if you do it that way.
What information is missing? The xdmcp information indeed could stay in the dm, but xinit already uses consolekit that way, so if something is missing it will also be missing in xinit. Anyway here is what ck-list-sessions give to me. What is missing? $ ck-list-sessions Session2: uid = '500' realname = 'Patrice Dumas' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2008-07-13T09:58:07.044968Z'
That looks OK (for a local session), but I'm pretty sure it isn't going to work with XDMCP.
(In reply to comment #12) > That looks OK (for a local session), but I'm pretty sure it isn't going > to work with XDMCP. Sure. That part should certainly stay in the dm.
At that point, what do we gain over doing everything in the DM? My plan is to put your version of the KDM patch (the one which uses libck-connector) in Rawhide for testing, and if it works fine, fight for getting it accepted in upstream KDE for 4.2. The licensing objections ossi had should be resolved (there's no GPL code in your version of the patch, the equivalent code is now in libck-connector and that library is X11-licensed like the KDM backend is), so I think it should be mergeable.
(In reply to comment #14) > At that point, what do we gain over doing everything in the DM? A better design. In fact it would have been much better if the consolekit stuff had been done in the framework of existing technologies (pam/X/Xdmcp/whatever) as much as possible, instead of doing it in the framework of gdm only and thinking about integration afterwards or ignoring other possibilities. In my opinion XDMCP integration should have been plannified from the beginning, maybe there are other possibilities than putting it in the dm that are more modular and less specific. > I think it should be mergeable. In my opinion only the xdmcp part should be merged, the device selection is too ugly to be acceptable in a cross-platform software. But I am not the kdm maintainer...
(In reply to comment #15) > > I think it should be mergeable. > > In my opinion only the xdmcp part should be merged, the device selection > is too ugly to be acceptable in a cross-platform software. But I am not > the kdm maintainer... > I think this solution will be the best. One other bug is bug #446143. When you open vnc session CK session is not opened due this bug. We should keep generic things on one place.
*** Bug 446143 has been marked as a duplicate of this bug. ***
Created attachment 316982 [details] run run ck-xinit-session for all sessions where the xdg cookie isn't already set, minor fixes This is rebased. Please have a look at it, I can't control myself and keep on adding packaging fixes...
What should be done to have it applied? It would be nice to have it in F-10, such that xdm/wdm/... work in that release. I have posted a patch more than 2 months ago!
Adding this to F10Blocker because it will be ignored otherwise.
While I disagree in principle with all the Xsession shellscript madness, the last patch looks like it could be applied without any problems.
FWIW, I also think patching the DMs is the better solution. I've been doing that with KDM for a long time now.
(In reply to comment #20) > Adding this to F10Blocker because it will be ignored otherwise. Looks like it got ignored anyway. Now I'm not so sure about making this change at this point in F10's cycle. Can somebody closer to the problem decide if it's safe enough?
It has worked for me for months now, both with xdm and kdm. But since it is broken for more than one year, I am not sure than there is a need to hurry, I guess that I am the only user still using something else than kdm/gdm.
Well this is definitely not a blocker... removing from blocker list.
We run into the same problem with the Sugar livecd which uses slim as login manager.
Patrice, thank you _very much_ for the patch. However I think your comment #24 way underestimates the importance of this issue. It really isn't just xdm/wdm. Since 446143 has been merged, it also covers vnc (and apparently nx). Googling 'vnc ConsoleKit' will show that this is a widespread problem. But even that way under-estimates the issue, because it only picks up people who realise that ConsoleKit is the root cause of their problems with vnc/nx and whatever application. Most will think - as I initially did - that it's Yet Another Selinux Problem (YASP), and probably give up when a relabel doesn't fix it...
I applied patch in rawhide, fixed in xorg-x11-xinit-1.0.9-5.fc11
*** Bug 476402 has been marked as a duplicate of this bug. ***