Lightweight display manager for xfce?

[Auke Kok]

On 05/28/2011 12:56 AM, Yves-Alexis Perez wrote:
> On ven., 2011-05-27 at 21:37 -0700, Auke Kok wrote:
>> On 05/26/2011 11:07 PM, Yves-Alexis Perez wrote:
>>   >  Note that I've quickly tried uxlaunch on my Debian. It might be related
>>   >  to some integration lacking, but it failed to use consolekit properly.
>>   >
>>   >  When running directly startxfce4 or xfce4-session, it won't start the
>>   >  consolekit daemons.
>>
>> console-kit-daemon needs to be running before uxlaunch starts. It's up
>> to the ConsoleKit packager to assure it's running before uxlaunch starts.
>>
>> of course, systemd should start it on-demand for you if you're lucky
>> enough to use that.
>
> Well, I don't know about systemd (and frankly the first impression I
> have is “scary”). I'm not too sure why consolekit would have to be run
> before uxlaunch though. uxlaunch by itself doesn't need any permissions
> so only stuff launched by it require it. Or am I mistaken?

we're using a minimal design - console-kit-daemon should really be run 
independently of a X11 session so it can manage more than just 1 session 
  (e.g. ssh logins, vc/? logons), so it doesn't make much sense to 
enabled it in uxlaunch.

Perhaps this is a bit confusing, but uxlaunch is really meant as a "do 
everything as the user" type application. While it is started as root, 
it immediately drops privileges before it actually does anything 
significant.

> Right now, if consolekit is launched by uxlaunch before startxfce4, the
> issue is the same as with slim (before patch) and xdm, the session is
> marked as non local.

console-kit-daemon needs to be started as root before uxlaunch runs, and 
you shouldn't use startxfce4, but uxlaunch should run `xfce4-session` 
instead as session program.

I'm figuring this is what messes up: startxfce4 has a ton of shell code 
that starts a new consolekit seat, and so the two that are now created 
conflict, or the current one is modified wrongly.

If someone has some time to debug/document this for debian, I can maybe 
work with them to figure it out how to integrate on debian in the 
"intended" way.

>>   >  When using the (debian specific) /etc/X11/Xsession (which runs scripts
>>   >  in /etc/X11/Xsession.d/ like the consolekit one, then startxfce4),
>>   >  consolekit is started but the session is *not* marked as local (same
>>   >  thing as slim or xdm for example). Note that libpam-ck-connector *is*
>>   >  installed.
>>
>> xsession.d is a rather obsolete (cough, you may disagree) way of
>> starting stuff. In the future, pretty much all shell code will be
>> extinct and with X11 going away in favor of things like wayland, there's
>> really no reason for me to support xsession.d script fu when desktop
>> files are all you need (and even those may just become obsolete...)
>
> Note that, afacit, /etc/X11/Xsession.d is a Debian-specific thing
> anyway. I just noted that as a reference, I'm not too sure how other
> people do, but the point was to start consolekit before Xfce and share
> the environment variables.

yes, that's how uxlaunch internally works:

largely:

- drop privileges after pam login, parse environment variables by 
running a shell
- uxlaunch starts session dbus and initiates a consolekit seat
- start Xorg and session program (/usr/bin/xfce4-session)
- the rest (xdg/autostart)

from there on, all programs are set with the right environment

> systemd might be a solution for you (MeeGo) but the Linux-only thing
> means it will really cause problems for people interested in other stuff
> (wether Debian because of kFreeBSD or Xfce)

well, uxlaunch was not specifically written for systemd at all, 
meego-1.2 still uses sysvinit, which is what we wrote it for initially - 
and should just work just fine if console-kit-daemon is up.

the uxlaunch.log file should give a ton of hints too - feel free to send 
me that+stdout.

Auke


Auke