VT's in elogind

[dvc94ch]

Elogind does not manage virtual terminals.

What exactly does this mean?

I'm getting logind: session not running on a VT when trying to get weston to work with elogind (on guixsd). The problem seems to be that sd_session_get_vt returns -1 in launcher-elogind.c.

return sd_session_get_vt(sid, out);

Do you have any advice on how to get it working? Would something have to happen on the elogind side? Or do I have to replace the routine in weston with something guixsd compatible?

[Yamakuzure]

This issue should be fixed in the v226.4 release at elogind/elogind, so this issue can be closed.
Further development is done there, so please report at the new repo if this issue still exists.

I have run Plasma on Wayland started by sddm using the new version, so I guess Weston should work fine, too.
But I have not tested it, yet.

[udeved]

I have run Plasma on Wayland started by sddm using the new version, so I guess Weston should work fine, too.

I have successfully started a plasma wayland session with intel free drivers and elogind-226 on manjaro.

Regarding initial question of VT management, I found, that elogind doesn't manage VTs, most obvious with for example qterminal.

Say I run as normal user

 pkexec bash

in gui session. The terminal will login my account. However, this terminal has no command history and so on. I think this is something to do with elogind not managing VT.
Never noticed it with ck2, which managed VT iirc.

Could the new openrc getty service be of any help with elogind?

[Yamakuzure]

Auto-spawning VTs requires systemd in practice. That's why commit 059696a removed that functionality.

Virtual-terminals are basically a combination of input devices and a monitor. They can be accessed via /dev/tty<num> (where <num> is between 1 and 63; the other /dev/ttyXY devices are no VTs!).

VTs are always bound to seat0. So only sessions on this seat can use VTs (which means, classic text-mode is only available on seat0).

Text-mode sessions are special in that they are not spawned by a login-session. systemd-logind spawns /bin/agetty right during boot for each VT (you can configure how many of the 63 possible should be started). agetty is running as system daemon and not in a session! However, it is bound to seat0, obviously. agetty initializes the VT and runs /bin/login. login then writes a greeter to the VT and reads username plus password from it. As you might notice, this is problematic as it accesses devices attached to a seat even though it’s not running in a session. But due to the design of VTs, this cannot be easily avoided.

On systems not running systemd, the init system spawns agetty.
OpenRC, for example, uses /etc/conf.d/agetty and /etc/inittab for the configuration and spawns it through /etc/init.d/agetty.

When agetty has confirmed a login, it looks up the initial process in /etc/passwd (let’s assume it is /bin/bash) and runs it. So bash is the controlling process in this session.

That means, that elogind is completely out of the way and has no control over the whole thing.

Say I run as normal user

pkexec bash

in gui session. The terminal will login my account. However, this terminal has no command history
and so on. I think this is something to do with elogind not managing VT.

No. If I run pkexec bash, I get a root bash with my last history as it was written to ~/.bash_history

[udeved]

No. If I run pkexec bash, I get a root bash with my last history as it was written to ~/.bash_history

Yep, its the case in plasma5, but I notice something strange going on with lxqt and qterminal.

[Yamakuzure]

@udeved : I haven't tried it with lxqt and qterminal, yet, but will do during the next days.

[udeved]

I think that resolved with sddm working properly now.

[Yamakuzure]

Oh, that's great! :-)