-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
explicit tty #36
Comments
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. 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) |
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 autovt@.service 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 =)
|
First some information:
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 |
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. |
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... |
See XDG_SEAT here: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers |
Interesting, then where is this getting set when using getty@.target? It's not being done by anything in util-linux. I wonder if systemd has some built in magic... |
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. |
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/#. |
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. |
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. |
So Lennart just pushed a8573ccc35a4efe8900be5d48c6c803670540c2b to the systemd repository. See: 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! |
Any plans for a way to specify a tty at startup?
This is necessary to use a kmscon@.service for systemd's autovt service.
The text was updated successfully, but these errors were encountered: