[systemd-devel] Bug in systemd? Running X without a display manager

[Colin Guthrie]

'Twas brillig, and Alan Stern at 27/08/12 16:53 did gyre and gimble:
> On Mon, 27 Aug 2012, Dave Reisner wrote:
> 
>>>> You'll need to start X on the same VT that you logged in on. If it's
>>>> tty1, then:
>>>>
>>>> startx -- vt01
>>>
>>> That's a reasonable workaround, but it's not a real fix.
>>
>> Why isn't it a real fix? It's simply different semantics from
>> consolekit. If you want this done automatically, it's trivial to write
>> your own ~/.xserverrc which does the VT detection and passes it to X as
>> an argument:
>>
>> https://gist.github.com/3489325
> 
> I meant that it shouldn't be necessary to tell X to run on the same tty
> as the original login session.  X should be able to pick whichever tty
> it wants (or is told), and that information should get propagated to
> systemd.

This has been discussed on this list a while back (I think started by me).

It's not really as simple as that these days. In order to do things
cleanly (and from what I understand the CK way was certainly far from
clean), you really need to use some kind of login agent. Typically this
would be the job of the DM, but as you are not using one, it's obviously
not going to work.

So in theory you need to spawn something that acts as a proper login
agent, has a real PAM conversation and then starts X for you. That's the
only real way to do the proper user registration (for the simply fact
that it's not really possible to start a session from a session.

> The lack of propagation is a bug, and telling X explicitly what tty to
> use doesn't fix it.

The primary problem is that logind doesn't know that your session is
active. As you change vt the session you do have listed in loginctl
becomes inactive and thus various ACLs are removed form you user.

It was my understanding that startx in Fedora was going to be patched to
work. I patched it in Mageia here:
http://svnweb.mageia.org/packages/cauldron/xinit/current/SOURCES/xinit-1.3.2-use-current-vt.patch?revision=229253&view=markup

>>> Fedora 16 uses ConsoleKit, and testing shows that ConsoleKit is aware 
>>> of both the test-mode and X session whereas systemd isn't:
>>
>> That's unfortunate. I doubt anyone on this list cares about CK in any
>> real way. logind is the "way forward".
> ...
>> Presumably, this only works because you launch X with ck-launch-session
>> and pam_ck_connector somewhere in your PAM login stack. I don't know
> 
> Indeed:
> 
> $ grep pam_ck_connector /etc/pam.d/*
> /etc/pam.d/login:-session   optional     pam_ck_connector.so
> 
> And ps says:
> 
> stern     1740  1723  0 10:36 tty1     00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X vt01 -auth /home/stern/.serverauth.1723
> root      1741  1740  7 10:36 ?        00:05:22 /usr/bin/X :0 vt01 -auth /home/stern/.serverauth.1723
> stern     1746  1740  0 10:36 ?        00:00:00 /usr/bin/ck-xinit-session /usr/bin/ssh-agent /home/stern/.Xclients

Yup, console-kit had two ways to "start a session", via the pam
connector or via the ck-launch*/ck-xinit* stuff. Sadly a "consolekit
session" is really quite half-hearted and didn't really track user
processes properly. With systemd's cgroup support user processes are
properly tracked which gives a lot more control, but sadly it comes at
the expense of a ck-launch*/ck-xinit replacement. This means you *have*
to use PAM, which means that a text login session cannot spawn a 2nd
session which, in turn, means the best way is to simply keep the current
session "active" which means reusing the current VT for X.


Looking forward a simple "autologin" system could get around this. e.g.
gdm has autologin support. Say it was modified to take the autologin
user as an argument. You could have a small setuid binary wrapper that
started gdm for you and passes your user as the autologin user when it
execs the main gdm process. This would mean all the proper PAM
conversations happen as expected and everything should be fine.

I only use gdm as an example here as it's got (AFAIUI) good PAM code. A
standalone autologin system that does PAM well would be fine too (tho' I
believe it's quite easy to write bad PAM code...)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/