Bug#526009: [Pkg-xfce-devel] Bug#526009: Bug#526009: Attempt to summarize
On Fri,07.Aug.09, 00:17:04, Yves-Alexis Perez wrote: it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? Not really sure. Maybe using ck-list-session and polkit-auth. Check just after boot, and later, when it fails, see if it's different. I recently had a similar behavior using startx and I think that was caused by an update of policykit and/or consolekit, because like the kernel, when the policykit and consolekit packages are updated, the system needs to be restarted for the updates to take effect. So, as long as the system is not restarted. reboot and shutdown are broken. Can be related to dbus upgrades, too. System bus restart will break existing sessions until logged out and logged back in. Not sure there's anything we can do about (not on xfce side anyway). Ok, here's my idea: record ck-list-session, polkit-auth output and the aptitude log on every Xfce start and shutdown/restart. For start it's easy, I just use the autostart feature, but how could I do this for shutdown? Is there a specific command that is executed to trigger the shutdown/restart so I can create my own launcher? Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On Thu,16.Jul.09, 08:04:31, Yves-Alexis Perez wrote: Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Mmm, can't reproduce anymore. Maybe something was wrong with libpam-ck-connector and purging/installing it fixed it? Ok, it wasn't my imagination, it showed up again today (with gdm). Unfortunately it was totally unexpected and I don't have the output of list-ck-sessions and polkit-auth. I'll set an hourly cronjob. Hmhm, ok, what's the status on this? Consolekit package has been fixed to work in most cases, and anyway gdm was supposed to work at first. So it looks very weird you still have issues here. Could you update us? Sorry for the late reply, but wanted to gather more data. The shutdown worked for a while, but then it broke again. Unfortunately it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? The interesting thing is that the bug doesn't show up with kdm. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On jeu, 2009-08-06 at 21:27 +0300, Andrei Popescu wrote: Sorry for the late reply, but wanted to gather more data. The shutdown worked for a while, but then it broke again. Unfortunately it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? Not really sure. Maybe using ck-list-session and polkit-auth. Check just after boot, and later, when it fails, see if it's different. The interesting thing is that the bug doesn't show up with kdm. Hmhm, so it might be related to gdm? Or maybe to some other gnome stuff. I wonder if stuff like gnome-screensaver (do you run it?) might deprecate ck tokens after a while. Or gnome-keyring. Not really sure how to help anyway. Atm I'm using gdm on two boxes, which I basically boot on the morning, do some work, and put to hibernation at night. Not sure about their respective uptime, but some days at least, and they both work fine (I can hibernate, at least). So not exactly sure how to debug this. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Bug#526009: Attempt to summarize
On Thu, 06 Aug 2009 20:52:12 +0200 Yves-Alexis Perez cor...@debian.org wrote: On jeu, 2009-08-06 at 21:27 +0300, Andrei Popescu wrote: Sorry for the late reply, but wanted to gather more data. The shutdown worked for a while, but then it broke again. Unfortunately it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? Not really sure. Maybe using ck-list-session and polkit-auth. Check just after boot, and later, when it fails, see if it's different. Hi I recently had a similar behavior using startx and I think that was caused by an update of policykit and/or consolekit, because like the kernel, when the policykit and consolekit packages are updated, the system needs to be restarted for the updates to take effect. So, as long as the system is not restarted. reboot and shutdown are broken. Pascal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526009: [Pkg-xfce-devel] Bug#526009: Bug#526009: Attempt to summarize
On jeu, 2009-08-06 at 17:06 -0400, Pascal Gervais wrote: On Thu, 06 Aug 2009 20:52:12 +0200 Yves-Alexis Perez cor...@debian.org wrote: On jeu, 2009-08-06 at 21:27 +0300, Andrei Popescu wrote: Sorry for the late reply, but wanted to gather more data. The shutdown worked for a while, but then it broke again. Unfortunately it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? Not really sure. Maybe using ck-list-session and polkit-auth. Check just after boot, and later, when it fails, see if it's different. Hi I recently had a similar behavior using startx and I think that was caused by an update of policykit and/or consolekit, because like the kernel, when the policykit and consolekit packages are updated, the system needs to be restarted for the updates to take effect. So, as long as the system is not restarted. reboot and shutdown are broken. Can be related to dbus upgrades, too. System bus restart will break existing sessions until logged out and logged back in. Not sure there's anything we can do about (not on xfce side anyway). Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On dim, 2009-05-03 at 09:17 +0300, Andrei Popescu wrote: On Wed,29.Apr.09, 11:49:24, Andrei Popescu wrote: On Wed,29.Apr.09, 08:35:18, Yves-Alexis Perez wrote: On mer, 2009-04-29 at 09:11 +0300, Andrei Popescu wrote: From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Mmm, can't reproduce anymore. Maybe something was wrong with libpam-ck-connector and purging/installing it fixed it? Ok, it wasn't my imagination, it showed up again today (with gdm). Unfortunately it was totally unexpected and I don't have the output of list-ck-sessions and polkit-auth. I'll set an hourly cronjob. Hmhm, ok, what's the status on this? Consolekit package has been fixed to work in most cases, and anyway gdm was supposed to work at first. So it looks very weird you still have issues here. Could you update us? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#525909: Bug#526009: Attempt to summarize
On Wed,29.Apr.09, 11:49:24, Andrei Popescu wrote: On Wed,29.Apr.09, 08:35:18, Yves-Alexis Perez wrote: On mer, 2009-04-29 at 09:11 +0300, Andrei Popescu wrote: From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Mmm, can't reproduce anymore. Maybe something was wrong with libpam-ck-connector and purging/installing it fixed it? Ok, it wasn't my imagination, it showed up again today (with gdm). Unfortunately it was totally unexpected and I don't have the output of list-ck-sessions and polkit-auth. I'll set an hourly cronjob. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Bug#526009: Attempt to summarize
On Tue,28.Apr.09, 22:29:04, Yves-Alexis Perez wrote: Ok, I've run some tests and asked Julien Cristau about startx behavior. Basically, if we want a “fully loaded” Xfce session, with complete user experience, we need to be able to shutdown through hal, and to mount/umount devices easily. For that, we need access to hal, and so we need policykit permissions, given by consolekit (something like that). Ack To have that, there is two major cases: - login through a display manager - login from the console Ack From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On mer, 2009-04-29 at 09:11 +0300, Andrei Popescu wrote: From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#525909: Bug#526009: Attempt to summarize
On Wed,29.Apr.09, 08:35:18, Yves-Alexis Perez wrote: On mer, 2009-04-29 at 09:11 +0300, Andrei Popescu wrote: From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Mmm, can't reproduce anymore. Maybe something was wrong with libpam-ck-connector and purging/installing it fixed it? Regards, Andrei P.S. CCd to #525909 because it's relevant there too -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Bug#526009: Attempt to summarize
Ok, I've run some tests and asked Julien Cristau about startx behavior. Basically, if we want a “fully loaded” Xfce session, with complete user experience, we need to be able to shutdown through hal, and to mount/umount devices easily. For that, we need access to hal, and so we need policykit permissions, given by consolekit (something like that). To have that, there is two major cases: - login through a display manager - login from the console From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) From the console: - either libpam-ck-connector is installed - either it's not If it's installed, consolekit stuff will be positionned at login, and should be propagated to any desktop run from there. And that's why 90consolekit should _not_ be run, and why the pam module sets a variable to be sure. If it's not installed, the console login won't have consolekit stuff, and if we want a complete desktop experience, we _need_ to use 90consolekit, and so run stuff in /etc/X11/Xsession.d (and still run startxfce4). The only way to do that (that I know) is to put: exec startxfce4 in .xsession, and run: startx (no .xinitrc, no startx /usr/bin/startxfce4 or anything else). So, if we document that in README.Debian, everything should work fine for most user, wether they use a DM (case 1) or not, and have libpam-ck-connector installed (2a) or not (2b). But we have a problem with 2a because in some cases which you exposed in I don't remember which bug, that the ck session on console wasn't propagated to the desktop session. Could you give (on that bug) a summary of how to reproduce this? Cheers, and thanks for working on this issue :) -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: Attempt to summarize
On 04/28/09 14:29, Yves-Alexis Perez wrote: From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) From the console: - either libpam-ck-connector is installed - either it's not If it's installed, consolekit stuff will be positionned at login, and should be propagated to any desktop run from there. And that's why 90consolekit should _not_ be run, and why the pam module sets a variable to be sure. That makes sense, except that the consolekit stuff appears to not be propagated. Perhaps the true cause of these problems is a bug in consolekit? Although from my readings on consolekit, it is not intended to propagate sessions across changing ttys (as in text login tty - xinit tty). If it's not installed, the console login won't have consolekit stuff, and if we want a complete desktop experience, we _need_ to use 90consolekit, and so run stuff in /etc/X11/Xsession.d (and still run startxfce4). The only way to do that (that I know) is to put: exec startxfce4 in .xsession, and run: startx (no .xinitrc, no startx /usr/bin/startxfce4 or anything else). There are other ways (* see below), but that is by far the easiest and cleanest at the moment. So, if we document that in README.Debian, everything should work fine for most user, wether they use a DM (case 1) or not, and have libpam-ck-connector installed (2a) or not (2b). But we have a problem with 2a because in some cases which you exposed in I don't remember which bug, that the ck session on console wasn't propagated to the desktop session. Could you give (on that bug) a summary of how to reproduce this? Reproducing it appears to be straight-forward: 0) remove .xsession, .xinitrc, and other similar X customization files 1) install libpam-ck-connector 2) kill all /sbin/login processes (so login reloads the pam stack) 3) log out and log back in 4) run polkit-auth (all necessary permissions will be present) 5) run startxfce4 6) run polkit-auth from a terminal (most permissions are now missing) Alternatively: 0) - 4) same as above 5) ensure /etc/alternatives/x-session-manager links to xfce4-session 6) run startx 7) run polkit-auth from a terminal, and most permissions are missing I will put this information in the thunar bug as well. * Other ways I have found that work: - symlink /etc/alternatives/x-session-manager to /usr/bin/startxfce4 (but this defeats the true purpose of alternatives in this case) - custom $HOME/.config/xfce4/.xinitrc or $HOME/.xinitrc with ck-launch-session in an appropriate place (but this prevents the user from benefitting from future improvements to the Debian X startup process in /etc) I'm sure there are other ways, but they will probably all be messy and non-Debian-standard. I did have another thought - if there is stuff that startxfce4 does that xfce4 requires, maybe that stuff, or a call to startxfce4 itself, should be integrated somehow into /etc/X11/Xsession.d/*? Something like what is done in /etc/X11/Xsession.d/55gnome-session_gnomerc? Then the alternative just needs to be pointed to xfce4-session, and no .xsession in the home dir is required - seamless for the user. -- Scott Barker sc...@mostlylinux.ca Linux Consultant http://www.mostlylinux.ca/scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On 04/28/09 15:15, Yves-Alexis Perez wrote: On mar, 2009-04-28 at 14:56 -0600, Scott Barker wrote: On 04/28/09 14:29, Yves-Alexis Perez wrote: But we have a problem with 2a because in some cases which you exposed in I don't remember which bug, that the ck session on console wasn't propagated to the desktop session. Could you give (on that bug) a summary of how to reproduce this? Reproducing it appears to be straight-forward: [...] I will put this information in the thunar bug as well. Please don't. It's _really_ messy. Thunar needs a correctly setup consolekit, xfce4-session too. For most Xfce users this will be documented in xfce4-utils:README.Debian and/or xfce4:README.Debian. And this is the bug where we discuss it. Not the other ones, please. Right, sorry, I won't. I mis-interpreted your wording asking for a summary on how to reproduce as asking for it in the other bug report. Yeah, it's been quite some time since I first though of putting all startxfce4 stuff into /etc/X11/Xsession.d and only keep a stub. But I don't really want to divert too much from upstream and other distros. It could be as simple as: BASESTARTUP=`basename $STARTUP | cut -d\ -f1` if [ $BASESTARTUP = xfce4-session -o \ \( $BASESTARTUP = x-session-manager -a \ `readlink /etc/alternatives/x-session-manager` = \ /usr/bin/xfce4-session \) ]; then STARTUP=/usr/bin/startxfce4 fi However, this may be as undesirable as pointing x-session-manager at /usr/bin/startxfce4. Obviously, you and others can make the best decision in this regard. -- Scott Barker sc...@mostlylinux.ca Linux Consultant http://www.mostlylinux.ca/scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On mar, 2009-04-28 at 14:56 -0600, Scott Barker wrote: On 04/28/09 14:29, Yves-Alexis Perez wrote: From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) From the console: - either libpam-ck-connector is installed - either it's not If it's installed, consolekit stuff will be positionned at login, and should be propagated to any desktop run from there. And that's why 90consolekit should _not_ be run, and why the pam module sets a variable to be sure. That makes sense, except that the consolekit stuff appears to not be propagated. Perhaps the true cause of these problems is a bug in consolekit? Although from my readings on consolekit, it is not intended to propagate sessions across changing ttys (as in text login tty - xinit tty). I need more testing on this, but this could definitely bite us :/ But we have a problem with 2a because in some cases which you exposed in I don't remember which bug, that the ck session on console wasn't propagated to the desktop session. Could you give (on that bug) a summary of how to reproduce this? Reproducing it appears to be straight-forward: 0) remove .xsession, .xinitrc, and other similar X customization files 1) install libpam-ck-connector 2) kill all /sbin/login processes (so login reloads the pam stack) 3) log out and log back in 4) run polkit-auth (all necessary permissions will be present) 5) run startxfce4 6) run polkit-auth from a terminal (most permissions are now missing) Ok, thanks, I'll check on that. Alternatively: 0) - 4) same as above 5) ensure /etc/alternatives/x-session-manager links to xfce4-session 6) run startx 7) run polkit-auth from a terminal, and most permissions are missing Yeah, this is the same stuff as just above. I will put this information in the thunar bug as well. Please don't. It's _really_ messy. Thunar needs a correctly setup consolekit, xfce4-session too. For most Xfce users this will be documented in xfce4-utils:README.Debian and/or xfce4:README.Debian. And this is the bug where we discuss it. Not the other ones, please. * Other ways I have found that work: - symlink /etc/alternatives/x-session-manager to /usr/bin/startxfce4 (but this defeats the true purpose of alternatives in this case) - custom $HOME/.config/xfce4/.xinitrc or $HOME/.xinitrc with ck-launch-session in an appropriate place (but this prevents the user from benefitting from future improvements to the Debian X startup process in /etc) I'm sure there are other ways, but they will probably all be messy and non-Debian-standard. Yeah and we definitely won't advertise them :) We'll recommend one way for console users (and the display manager stuff), and other users will do their stuff based on that. I did have another thought - if there is stuff that startxfce4 does that xfce4 requires, maybe that stuff, or a call to startxfce4 itself, should be integrated somehow into /etc/X11/Xsession.d/*? Something like what is done in /etc/X11/Xsession.d/55gnome-session_gnomerc? Then the alternative just needs to be pointed to xfce4-session, and no .xsession in the home dir is required - seamless for the user. Yeah, it's been quite some time since I first though of putting all startxfce4 stuff into /etc/X11/Xsession.d and only keep a stub. But I don't really want to divert too much from upstream and other distros. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On mar, 2009-04-28 at 14:56 -0600, Scott Barker wrote: On 04/28/09 14:29, Yves-Alexis Perez wrote: If it's installed, consolekit stuff will be positionned at login, and should be propagated to any desktop run from there. And that's why 90consolekit should _not_ be run, and why the pam module sets a variable to be sure. That makes sense, except that the consolekit stuff appears to not be propagated. Perhaps the true cause of these problems is a bug in consolekit? Although from my readings on consolekit, it is not intended to propagate sessions across changing ttys (as in text login tty - xinit tty). […] But we have a problem with 2a because in some cases which you exposed in I don't remember which bug, that the ck session on console wasn't propagated to the desktop session. Could you give (on that bug) a summary of how to reproduce this? Reproducing it appears to be straight-forward: 0) remove .xsession, .xinitrc, and other similar X customization files 1) install libpam-ck-connector 2) kill all /sbin/login processes (so login reloads the pam stack) 3) log out and log back in 4) run polkit-auth (all necessary permissions will be present) 5) run startxfce4 6) run polkit-auth from a terminal (most permissions are now missing) Ok. I've tested and we have indeed propagation problems. I'm not sure how it's supposed to be handled, but I think it's a bug in consolekit. I don't exactly know how it should be done, but: - either the authentication propagates from console to X - either the 90consolekit shouldn't prevent ck-launch What do you think? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On 04/28/09 15:47, Yves-Alexis Perez wrote: Ok. I've tested and we have indeed propagation problems. I'm not sure how it's supposed to be handled, but I think it's a bug in consolekit. I don't exactly know how it should be done, but: - either the authentication propagates from console to X - either the 90consolekit shouldn't prevent ck-launch What do you think? I think someone who has more intimate knowledge of consolekit should be consulted to clarify the propagation issue. If, in fact, propagation does not occur, then it may be best to leave libpam-ck-connector uninstalled, unless there is some pressing reason it would be needed in a text terminal-only environment. However, I also found this method to fix the issue: - libpam-ck-connector can be installed or not, doesn't matter - don't use a $HOME/.xsession file - put the following in $HOME/.config/xfce4/xinitrc: #!/bin/sh exec ck-launch-session /etc/xdg/xfce4/xinitrc - chmod +x $HOME/.config/xfce4/xinitrc Now you can start xfce with 'startxfce4' instead of 'startx', and everything works fine, regardless of libpam-ck-connector. This method just over-rides the default exec at the very end of /usr/bin/startxfce4, inserting ck-launch-session before calling /etc/xdg/xfce/xinitrc. I'm sure that the upstream xfce developers will run across this consolekit problem soon (if they haven't already), and may patch /usr/bin/startxfce4 appropriately anyway. So, that makes two fairly simple methods which work fine (one for the 'debian way' and one for the 'xfce way'), but you and the other maintainers will need to determine which is best. -- Scott Barker sc...@mostlylinux.ca Linux Consultant http://www.mostlylinux.ca/scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526009: [Pkg-xfce-devel] Bug#526009: Bug#526009: Attempt to summarize
On Tue, 2009-04-28 at 23:47 +0200, Yves-Alexis Perez wrote: Ok. I've tested and we have indeed propagation problems. I'm not sure how it's supposed to be handled, but I think it's a bug in consolekit. I don't exactly know how it should be done, but: - either the authentication propagates from console to X No, you should end up with two sessions from consolekit's point of view. - either the 90consolekit shouldn't prevent ck-launch This causes other problems. Is startxfce4 called by other things (e.g. GDM), or is it a script that the user is expected to use to launch their session similar to startx? If it's the latter then it should probably be modified to explicitly create a consolekit session for the user session it is creating. That would fix this issue without leading to multiple sessions for each user. Thanks, James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526009: [Pkg-xfce-devel] Bug#526009: Bug#526009: Bug#526009: Attempt to summarize
On mer, 2009-04-29 at 00:50 +0100, James Westby wrote: On Tue, 2009-04-28 at 23:47 +0200, Yves-Alexis Perez wrote: Ok. I've tested and we have indeed propagation problems. I'm not sure how it's supposed to be handled, but I think it's a bug in consolekit. I don't exactly know how it should be done, but: - either the authentication propagates from console to X No, you should end up with two sessions from consolekit's point of view. Fine, so 90consolekit should run. That's exactly the point of Xsessions.d stuff. - either the 90consolekit shouldn't prevent ck-launch This causes other problems. Is startxfce4 called by other things (e.g. GDM), or is it a script that the user is expected to use to launch their session similar to startx? Both. It works fine to use it from GDM, to directly use startxfce4 from console, to run startx /usr/bin/startxfce4, to put it in .xsession and run startx. If it's the latter then it should probably be modified to explicitly create a consolekit session for the user session it is creating. That would fix this issue without leading to multiple sessions for each user. I don't want to divert from upstream, and I don't think that's the role of Xfce initscript to set-up CK. It shouldn't depend on it and that's why I definitely want Xfce/Debian users to use the Xsessions.d scripts, because they are installed by the packages themselves, so it'll automagically work. (except in this case because of the stale CK session problem, but I started discussing it on #526006 and #520720) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
