[systemd-devel] [PATCH 3/3] logind: session: Fix not allowing more than one controller

Lennart Poettering lennart at poettering.net
Mon Aug 11 07:52:36 PDT 2014


On Mon, 11.08.14 16:46, Olivier Brunel (jjk at jjacky.com) wrote:

> 
> On 08/11/14 16:34, Lennart Poettering wrote:
> > On Fri, 08.08.14 20:45, Olivier Brunel (jjk at jjacky.com) wrote:
> > 
> >> While a session can only ever have one controller, there can be more than
> >> one session with a controller at a time. However, because of the handling
> >> of SIGUSR1 for handling VT switch, trying to set a controller on a session
> >> while another session had a controller would fail.
> > 
> > I really don't feel comfortable with using SIGUSR1 for this, anyway I
> > must say... SIGUSR1 and SIGUSR2 I think should be left for admins to
> > communicate with the daemon for some simple operations, but using this
> > internally sounds wrong. Now, the VT is so stupid to require a signa
> > handler here, but I think using SIGRTMIN+1 or so might be the better
> > choice here?
> > 
> > Now, what makes we wonder here, shouldn't we just install a single
> > signal event handler for this when logind initializes, and leaving it on
> > until the very end?
> 
> Just to note: the problem is that when the signal is called, there's no
> way of telling which VT it is about. I think it was only intended for
> one process to handle one VT, so there was no question. But if logind
> wants to handle more than one VT, to know on which VT to operate then
> I'm not sure it would actually be doable unless using a different signal
> per VT...

The VT is such a crap. Gah...

Maybe we can iterate through the VTs we have fds for and simply
acknowledge all of them? Wouldn't that work?

With rtsigs we actually have the option to allocate one signal per vt if
we want to.

But anyway, David really shouild comment on this. David?

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list