I think upgrade of xfce-base/xfce4-session-4.8.3-r1 to xfce-base/xfce4-session-4.10.0 broke my system. I cannot downgrade just this package but I use xdm and it stopped working for me. I get the following: $ cat ~/.xsession-errors XDM authorization key matches an existing client!xfce4-session: Cannot open display: . Type 'xfce4-session --help' for usage. $ It seems it is same as http://mail.xfce.org/pipermail/xfce-bugs/2012-May/005451.html https://bugzilla.xfce.org/show_bug.cgi?id=8841
No, the patch attached to the xfce.org bug does not help to fix this. :( However, it DOES help to get an error message printed when I intentionally screw up /etc/conf.d/xdm XDM variable to point to "xdmx" instead of "xdm": # /etc/init.d/xdm stop * Caching service dependencies [ ok ] * Stopping xdm [ ok ] # /etc/init.d/xdm start ERROR: Your XDM value is invalid. No xdmx executable could be found on your system. * Setting up xdm [ ok ] # That's bad such errors aren't caught anymore.
(In reply to comment #1) > No, the patch attached to the xfce.org bug does not help to fix this. :( I patched this file. Hope that was the correct place. # equery files xfce4-session | grep xinit /etc/xdg/xfce4/xinitrc #
Created attachment 315495 [details, diff] Patch: Move dbus launch back before xfce4-session start
Created attachment 315497 [details, diff] Ebuild diff
The patch from the xfce bug tracker works fine here.
Your patches did not help me by themselves but in the need I am running up now fine with them. After patching I reinstalled (same versions, no upgrades) of pam, pambase, xinit and after I saw einfo() from xinit about /etc/env.d/X90session and had a look what I have there. I had "Gnome" set. Setting it to "Xfce4" fixed my problem. I did not lookup file timestamps before saving it so I wonder: 1. why did previous version of xfce4-session did work even with "Gnome" in that file. 2. the current xfce4-session for sure respected my ~/.xsession and that was how I could switch temporarily from xfce4 to fvwm2 temporarily. So, I do not understand what is the issue. For a long while I believe I had xfce4 set through ~/.xsession and wonder whether portage overwrote my /etc/env.d/Xsession setting to some default? I see I have USE=-gnome in make.conf and neither xinit nor xdm bother with IUSE=gnome ... Should some scripts be smarter and realize broken/forbidden /etc/env.d/X90session value and force some other default? But provided upon xdm login my ~/.xsession is respected I fear I don't understand the culprit.
(In reply to comment #6) > Your patches did not help me by themselves but in the need I am running up > now fine with them. After patching I reinstalled (same versions, no > upgrades) of pam, pambase, xinit and after I saw einfo() from xinit about > /etc/env.d/X90session and had a look what I have there. I had "Gnome" set. > Setting it to "Xfce4" fixed my problem. Pretty much what I expected since I've tested Xfce 4.10 with every Display Manager in Portage *and* ConsoleKit (dbus, polkit) with every one of them and the DBUS_SESSION_BUS_ADDRESS have always been passed correctly along. Closing then if there are no longer prob
startx and x11-apps/xdm usage with USE="consolekit" enabled: XSESSION="Xfce" or XSESSION="Xfce4" (both will work, because of a symlink in /etc/X11/Sessions/) No ~/.xsession (!) ~/.xinitrc can contain 'exec startxfce4 --with-ck-launch' as documented in Gentoo's Xfce documentation for `startx` runs. This won't conflict with XDM. Other files should not be touched. If you want to add some extra setup on top of this, you need to do it in a way it doesn't get away of the formentioned setup.
(In reply to comment #6) > 2. the current xfce4-session for sure respected my ~/.xsession and that was > how I could switch temporarily from xfce4 to fvwm2 temporarily. xfce4-session doesn't do anything with ~/.xsession, but XDM might indeed read it and use it instead of XSESSION="" if present if you do this, it must contain the correct content. one wrong placement of dbus-launch, ck-launch-session, wrong USE setting of consolekit, /etc/pam.d/system-login setup for pam_ck_connector.so, etc. ton of issues can get a way and mess the whole setup up. (i'm tired of people doing this, so please just follow Comment #8)
Well for me it does not work without the patch. I have set XSESSION="Xfce4" in /etc/env.d/90xsession.
xfce4-session-4.10.0 has code in xfce4-session/main.c (search for xfsm_dbus_init() function) to launch a dbus session on it's own the proposed patch is incorrect, and the current location is correct since it's only purpose is to provide a fallback in case xfce4-session failed to run it's own session moving it on top would intervene main.c from doing it's thing so instead of touching xinitrc at all, try to figure out why xfce4-session's code doesn't already run it for you, or if something is crashing etc.
(In reply to comment #9) > (In reply to comment #6) > > 2. the current xfce4-session for sure respected my ~/.xsession and that was > > how I could switch temporarily from xfce4 to fvwm2 temporarily. > > xfce4-session doesn't do anything with ~/.xsession, but XDM might indeed > read it and use it instead of XSESSION="" if present > if you do this, it must contain the correct content. one wrong placement of I do not use consolekit so I have in the file: $ cat ~/.xsession xfce4-session #fvwm #awesome $ It works and has always worked. would you improve some of the error messages so that "xinit?" do not leak so far and exits earlier? See the original bug report. Seems when it cannot setup a session it dies much later awith a folling message claiming of an existing client. Probably, it should have complained that the value was not set at all and maybe that an old value s left in from a previous session? > dbus-launch, ck-launch-session, wrong USE setting of consolekit, > /etc/pam.d/system-login setup for pam_ck_connector.so, etc. ton of issues > can get a way and mess the whole setup up. > (i'm tired of people doing this, so please just follow Comment #8) I believe without consolekit I am fine withouit the 'ck-launch-session' calls.
*** Bug 423485 has been marked as a duplicate of this bug. ***
