explicit tty about kmscon

[dvdhrm]

I pushed bf18799 which introduces --vt= on the command-line. Please note that this does only affect seat0! You should pass --seats=seat0 if you want kmscon to run on a single-seat only. Otherwise, a single kmscon process services all seats.
So if you write [email protected], you really must pass --seats=seat0
VTs are always only used on seat0. If you have no idea what seats are, simply pass --seats=seat0 here and kmscon will behave as expected.

I would also be very interested in this service file. I already ship one in ./docs/kmscon.service but it is meant to service all seats. I'd like to ship your file within kmscon, too.

(also feel free to extend the build-files to install systemd-service files if requested)

[mmonaco]

Ok, so this worked, but I actually had agetty running on /dev/tty1 / vt1 (I don't know the relationship between tty# and vt#), I passed -vt 1 expecting it to fail, but kmscon just masked what was already there.

Also, systemd's [email protected] expects the parameter to be tty1, tty2, etc, not just the number. Is there a difference between binding to vt2 and tty2?

I thought --seats=seat0 was the default, but anyway, I passed it and loginctl doesn't show any seat for the login on kmscon... don't know where the breakage is, but agetty and kmscon are both calling /bin/login, thus using the same pam config.

Here's some nice output for you =)

$ loginctl list-sessions
   SESSION        UID USER             SEAT            
         2       1000 matt             seat0           
        23       1000 matt                             

2 sessions listed.

$ loginctl show-session 23
Id=23
Timestamp=Sat, 29 Sep 2012 04:37:20 -0600
TimestampMonotonic=7482459481
DefaultControlGroup=name=systemd:/user/matt/23
VTNr=0
TTY=pts/2
Remote=no
Service=login
Leader=521
Audit=23
Type=tty
Class=user
Active=yes
State=active
KillProcesses=no
IdleHint=no
IdleSinceHint=1348915061098155
IdleSinceHintMonotonic=7502564798
Name=matt

$ sd status kmscon.service
kmscon.service - kmscon
      Loaded: loaded (/etc/systemd/system/kmscon.service; disabled)
      Active: active (running) since Sat, 29 Sep 2012 04:37:13 -0600; 1min 2s ago
    Main PID: 518 (kmscon)
      CGroup: name=systemd:/system/kmscon.service
          └ 518 /usr/bin/kmscon -l --font-engine=pango --font-size=10 --seats=seat0 --vt 2 -- /bin/login

Sep 29 04:37:13 sunflower systemd[1]: Starting kmscon...
Sep 29 04:37:13 sunflower systemd[1]: Started kmscon.
Sep 29 04:37:13 sunflower kmscon[518]: [0000.000000] NOTICE: kmscon Build #1 Sep 29 2012 04:21:43
Sep 29 04:37:13 sunflower kmscon[518]: [0000.010348] NOTICE: vt: using tty /dev/tty2
Sep 29 04:37:13 sunflower kmscon[518]: [0000.046132] WARNING: video_drm: your GL implementation does not support GL_EXT_unpack_subimage, rendering may be slower than usual
Sep 29 04:37:15 sunflower kmscon[518]: [0001.432545] WARNING: text_gltex: your GL implementation does not support GL_EXT_unpack_subimage, glyph-rendering may be slower than usual
Sep 29 04:37:15 sunflower kmscon[518]: [0002.156426] WARNING: text_gltex: your GL implementation does not support GL_EXT_unpack_subimage, glyph-rendering may be slower than usual
Sep 29 04:37:20 sunflower login[521]: pam_unix(login:session): session opened for user matt by matt(uid=0)

[dvdhrm]

First some information:

• Running kmscon with "--debug" produces much more verbose output, just so you know.
• There is no /dev/vtXY, there is only /dev/ttyXY. Every VT does expose a tty interface to userspace so think of TTYs as a subset of what a VT provides. TTYs are actually used by many other subsystems. But we are talking about VTs here so I chose --vt
• every normal desktop currently does only have seat0, more seats have to be created manually (or via udev rules or whatever)
• kmscon does not create seats. Instead it attaches to every running or "hotplugged" seat and displays a new independent console on it

So "loginctl doesn't show any seat for the login on kmscon" doesn't make any sense. Or did you mean "session"? kmscon does not do seat- or session-management. This is done by login/pam or other system tools. There is really no reason to do this in kmscon.

You were probably saying that --list-sessions does not show the /bin/login session in kmscon? On my machine it works. If I use "./kmson -l /bin/login" and then I login with a normal user. Then "list-sessions" shows the new session. Maybe you did not login? I don't know. Could you check again? Also note that there is probably a limit of one session per VT. So if you spawn kmscon on the same VT as getty, the session might not show up. I am no PAM developer so you might ask there for help. Sorry, but this is not really related to kmscon and I have no idea how that internally works.

If getty is already running on a VT, I don't know of any reliable way to find that out from inside of kmscon. Also I don't know why you pass --vt=1 if getty is already running there? You should add a "conflicts" line to kmscon/agetty. They cannot run on the same VT simultaneously.

So I will try making it parse "tty1" as 1. But specifying the option explicitly will still be possible.

Thanks for your testing
David

[mmonaco]

Ok, to clarify, what I meant was the session that was started under kmscon, did not show an associated seat. See how session 2 has seat0 in the loginctl output? I see "seat0" in that column for logins from the display manager and logins from the agetty, but not kmscon. So I was wondering what the difference is. The session management is done by pam_systemd.so, which is in /etc/pam.d/login, so I am just trying to figure out why the sessions don't have similar parameters.

Similarly, the output of ps shows the "controlling terminal" of an agetty login as tty1, for example. However, for kmscon it's pts/1.

I passed with --vt=1 with agetty already running on tty1 to test the behavior. I expected it to fail. But that might be misguided because it looks like running two agettys on the same tty just corrupts them both...

I know kmscon isn't the same thing as agetty, but if it behaves like it, then it's much easier as a drop-in replacement. Ideally I'd like to use kmscon exclusively; I don't know who wouldn't.

[dvdhrm]

I just checked systemd/src/logind-dbus.c and the create_session() call gets as argument a seat-name. If it is empty, no seat is attached, otherwise, the seat-name is looked up and the session is attached to the seat.

So either pam_systemd is passing an invalid seat-name or no seat-name at all. I might have to check pam now...

[dvdhrm]

See XDG_SEAT here: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers
I actually need to pass this information to pam. I am just checking with systemd people in #systemd whether a "setenv()" is sufficient.

[mmonaco]

Interesting, then where is this getting set when using [email protected]? It's not being done by anything in util-linux. I wonder if systemd has some built in magic...

[dvdhrm]

Hehe, it has. If an application is running on a VT, you automatically know that it is on seat0. kmscon is running on a VT, but the applications in it are not. Therefore, they are not automatically assigned to seat0.

It's weekend and there seems nobody be active in #systemd. I might have to wait until Monday to talk about it with them. I want to be sure how that variable is supposed to be set before implementing it.

[mmonaco]

Ah, ok. The magic is in pam-module.c:get_seat_from_display().

I guess what I don't get is: the kmscon notice output says it's using /dev/tty#, for example, but most tools show pts/#.

[dvdhrm]

You mix up TTYs with VTs. You have to understand that each program you start runs in a terminal and has one attached TTY. (programs can run without attached TTY if they explicitly request this, for instance daemons do this).

Every terminal emulator you run, creates a TTY that applications can attach to. Virtual terminals (like kmscon, xterm, ...) create these terminals as /dev/pts/#. The kernel console creates so called VTs. VTs provide more than a simple terminal, but we can ignore it here.

So if you start your getty on a VT, then getty spawns a new session on this VT. However, if you start kmscon on this VT, then kmscon itself is the running session on this VT. But kmscon does also create another TTY for the application running inside of kmscon. This is pts/#.

So when kmscon reports that it uses /dev/tty#, then you can switch to kmscon via ctrl+alt+F5. However, kmscon itself can run multiple clients, so for instance we could implement switching between them via alt+tab. Then each client of kmscon gets a tty known as pts/#. So /dev/tty# is the TTY of kmscon on seat0 (on other seats it does not attach to terminals). But pts/# is the TTY of all the clients of kmscon.

[dvdhrm]

The --tty option should now support everything you want. Relative paths via ./path/to/dev, absolute paths via /path/to/dev, legacy paths relative to /dev with path/to/tty and tty numbers with 7.

The seat stuff still needs to be figured out. I will leave this open until I have committed a fix.

[dvdhrm]

So Lennart just pushed a8573ccc35a4efe8900be5d48c6c803670540c2b to the systemd repository. See:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=a8573ccc35a4efe8900be5d48c6c803670540c2b

This allows us to set XDG_SEAT from kmscon. I will push a fix for this tomorrow. But note that you might have to wait for systemd-194 until it works.

Thanks for the reports!
David