On Tue, 26 Jan 2021 11:40:31 -0800 Kian Kasad <kian@xxxxxxxxx> wrote: > On 21/01/26 02:06PM, Pekka Paalanen wrote: > > On Tue, 26 Jan 2021 01:43:43 -0800 > > Kian Kasad <kian@xxxxxxxxx> 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
Attachment:
pgpBjCue1XZKo.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
