Hi Sorry about the length.
I have a unique thing I am trying to solve, is that if I have a service that calls /sbin/logind under something like tmux, and I set `Environment=XDG_SEAT=seat0` in the service file, upon logging in, pam_systemd fails to create a session, as it's seat0 and it's expecting a valid TTY number, as it's seat0. One of the side effects is that you lose the credential prompt that you usually get if you run a command like `systemctl restart foo.service`, and there could be other things too? On a QEMU multiseat system, if I instead say set `Environment=XDG_SEAT=seat-pci-pci-0000_00_04_0` pam_systemd works, as it's OK for non-seat0 to have a session with a TTY of 0, the (sd_pam) process runs, and privileged systemctl commands do the text mode prompts for authentication. The question is is that most systems are not going to have the hardware to create a second seat, as it seems that the only way to create a second seat is to have a hardware device tagged as master-of-seat in the second seat. Which is probably very rare. If I say set `Environment=XDG_SEAT=virtual` it fails because that seat doesn't exist. Is there a way to create a fake seat to start this service on? Or make an exception somehow to allow that session to not have to be on a 1-63 TTY? Or is it irrelevant as it's mostly for granting permissions to input and output devices? Although with out pam_systemd You do lose the text mode Authentication prompt for some systemctl commands, but I can't think of anything else. (except maybe that if your main session is playing sound, and then you switch and log into a TTY, you can hear the sound play again) ----------------------------------------------------------------------------------------------------- And in case if you need to know why I am asking this, for context, I am doing some experimenting with making a jerry-rigged vt experiment because of https://github.com/systemd/systemd/issues/15387 and https://bugzilla.kernel.org/show_bug.cgi?id=208239 It's just a collection of bash some scripts, and .service files that call an instance of tmux with lots of bindings turned off as root (which calls /sbin/login), grants a restricted system account access to the socket files, and then vte running under cage that runs as that account, and runs a tmux client that connects to the socket, but it's just an experiment. (And obviously needs kernel mode setting, although with those particular problems, I guess it will be irrelevant if you have no mode setting in the first place.) (Maybe I am going at this the wrong way, as both the Display Server session, and the guest session will BOTH need to be active, and that's not possible) Thanks _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
