[systemd-devel] What exactly is multi-seat? -- questions about logind

Pekka Paalanen ppaalanen at gmail.com
Wed Jan 27 08:30:25 UTC 2021


On Tue, 26 Jan 2021 11:40:31 -0800
Kian Kasad <kian at kasad.com> wrote:

> On 21/01/26 02:06PM, Pekka Paalanen wrote:
> > On Tue, 26 Jan 2021 01:43:43 -0800
> > Kian Kasad <kian at kasad.com> wrote:
> >   
> > > Hi all,
> > > 
> > > After reading the documentation on logind and multi-seat (specifically
> > > sd-login(3) and "Multi-Seat on Linux"), I still have some questions.
> > > 
> > > First of all, what exactly is multi-seat? Does it just mean allowing
> > > multiple sessions to be running at once, like for multiple users to be
> > > logged into the same desktop, even though only one will be in use at a
> > > time?
> > > 
> > > Second, why is logind needed for this? Is it not possible to do without
> > > logind? I've run Xorg perfectly fine on systems without logind/systemd,
> > > so is logind only needed for multiple sessions at once? Is it just to
> > > handle the graphical device(s)?
> > > 
> > > Third, is multi-seat possible at all without logind? 
> > > 
> > > Most of these questions arose because my main OS, Artix Linux, requires
> > > logind (in the form of elogind) for Xorg, but I know that Xorg runs just
> > > fine on Alpine Linux, which does not use logind at all.  
> > 
> > Hi,
> > 
> > I've heard good words of https://sr.ht/~kennylevinsen/seatd/ although I
> > haven't tried to use it myself. One more way to handle multiseat - to
> > bind them all.  
> 
> I'll write this one down. I'm not looking for alternatives currently, I
> was just confused about the purpose.
> 
> > IOW, there are many ways to achieve coordination between multiple
> > sessions and one or multiple physical seats, like the Linux virtual
> > terminal system that requires root permissions, ioctl and signal magic
> > to let things cooperate (and if things do not explicitly cooperate
> > correctly, it fails horribly) and does not support multiseat. But if
> > you want your program to not need root permissions, have a graceful
> > failure if it crashes, not accidentally hijack the seat by mistake, or
> > just support multiseat, you kind of need to have a system daemon
> > orchestrating things.
> > 
> > Logind is one of those possible system daemons. It tells your program
> > when it is active. It grants access to graphics and input devices
> > without your program needing root permissions. It also takes graphics
> > and input devices away from your program when deactivated, so you can't
> > e.g. spy on other programs' input. It takes care of the arcane magic of
> > setting up the VT and tty and restoring them. And more.
> > 
> > "Your program" here is Xorg, for instance. Or one of the Wayland
> > compositors.  
> 
> Thank you! This is exactly the explanation I was looking for. I didn't
> get why a daemon was needed if programs (like Xorg) can handle the
> devices on their own, but now I see it's to allow multiple Xorg/Wayland
> sessions to run, all without needing SUID.

I would like to underline the crash handling too. Getting the VT
switching dance right is really tricky and depends on *both* programs,
the one switching out and the one switching in. If something goes wrong
with the VT switching dance, or the program currently active on the
default seat crashes, the chances are really high that the user is
staring at a frozen screen with his keyboard doing seemingly nothing.
The realistic end user options at that point are pressing the power
button or logging in via ssh to reboot the machine.

If all the tricky things are delegated to a system daemon that is
shared by all VT using sessions, getting the VT magic right is both
easier and needs to be implemented in just one place. The daemon can
also restore the VT in case the program using the VT crashes, or it can
switch to the graphical login manager *successfully*. The kernel does
not automatically restore the VT so that the user could regain control
of his machine.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210127/574f8b0d/attachment-0002.sig>


More information about the systemd-devel mailing list