[systemd-devel] Two questions about logind and seats

[nerdopolis]

On Monday, July 31, 2017 9:41:46 AM EDT Lennart Poettering wrote:
> On Sa, 29.07.17 00:34, nerdopolis (bluescreen_avenger at verizon.net) wrote:
> 
> > Hi
> > 
> > I hope this is the right place to ask this. I have two questions about logind
> > and seats. 
> > 
> > First, when I attach a 2nd graphics card to seat1, it seems CanMultisession is
> > set to 0. Is there a way to change that? or is that only supported on seat0, 
> > that supports the TTYs?
> 
> Yes, this is only supported where VTs are supported, and that is only seat0.
Thanks, It's currently a kernel limitation I assume? I guess I'll worry about 
multiple sessions on non seat0 seats when it _is_ supported.
> 
> > Second, with systemd-run, and maybe a custom '-p PAMName=somepamfile' (if that
> > is required), is there a way to spawn a process on seat1 if it exits?
> > For seat0 sessions, they for instance can be started by specifying
> 
> > -pTTYPath=/dev/ttyX -pStandardOutput=tty -pStandardError=tty
> > --pStandardInput=tty
> 
> Other seats don't have VTs, hence you cannot run anything on any such
> VTs...
Thanks, I will try to figure out how to get around Weston looking for a TTY
when being run on not-seat0.
> 
> To make use of these other seats you need some kind of terminal
> emulator that knows how to draw to DRM directly, and then you can
> connect your service to that.
> 
> > to systemd-run, which I know only seat0 supports ttys...
> > I try to do weston --seat=seat1 and it says that seat1 does not match the 
> > session-seat.
> > Is there a way to start a process with under a specific session-seat?
> 
> Well, I don't know weston that well, but presumably you are invoking
> it from a session that is attached to seat0, and it doesn't like that
> you try to run it on a different seat then, which makes a ton of sense
> to complain about. Contact the weston folks for help on this.
> 
Thanks I figured this one out, I didn't know I could change the session-seat by
exporting XDG_SEAT before calling systemd-run, I wasn't aware that
pam-systemd.so would _read_ the variable too.
> Lennart
> 
> 
Thanks for the assistance!