[systemd-devel] PATCH: fix logind on xen

[Lennart Poettering]

On Fri, 06.01.12 14:59, Frederic Crozat (fcrozat at suse.com) wrote:

> 
> Le mardi 03 janvier 2012 à 21:52 +0100, Lennart Poettering a écrit :
> > On Tue, 03.01.12 21:35, Lennart Poettering (lennart at poettering.net) wrote:
> > 
> > > > > currently, logind was enforcing the presence of /dev/tty0 to start
> > > > > properly. This device is not present on Xen (when using xencons=tty) or
> > > > > S/390.
> > > > 
> > > > Here is a regenerated version against master, since logind was moved to
> > > > its own directory.
> > > 
> > > Thanks for rebasing the patch!
> > > 
> > > I fear the patch is not complete though. seat_read_active_vt() in
> > > login/logind-seat.c needs to guard against the invalid fd in
> > > s->manager->console_active_fd.
> > > 
> > > Also, I assume that if /dev/tty0 doesn't exist /dev/tty1, /dev/tty2 and
> > > so on don't exist either. That means calls like seat_preallocate_vts()
> > > need to be shortcut in this case, too.
> > > 
> > > logind currently implicitly and always creates a seat0, that exists
> > > unconditionally, and that all hw that isn't assigned to anything else
> > > belongs to. That notion is probably nothing we could or should get rid
> > > off that easily, but that means that we need to make sure that a couple
> > > of its operations become NOPs on the systems in question. Besides
> > > seat_preallocate_vts() that's  seat_read_active_vt() and the whole logic
> > > that watches VCSA devices (which should be shortcut, as if n_autovts was
> > > 0, in manager_connect_udev()).
> > 
> > I have now commited a patch which reworks a lot of the logic there and
> > tries to handle the no-VT case as gracefully as possible. We still
> > implicitly create seat0, but we now stop advertising that it was
> > multi-session capable. Hence we still end up with a seat, but only with
> > the minimal properties that we need. This makes most of the other
> > explicit checks unnecessary fortunately.
> 
> Hmm, I've tested this patch (I'm extracted the patche you did for it and
> applied to our v37 package, thanks to git ;) and from what I see,
> "console" login doesn't get any seat attached (but other login, like
> over ssh are getting one), unlike my initial patch. So more work is
> needed somehow.

"console" logins? What exactly is that? Logins on /dev/console? Where
does /dev/console point to? i.e. what is the contents of
/sys/class/tty/console/active if you do that?

Note that we consider serial logins much like ssh logins as "virtual",
i.e. not physical, and hence with no seat assigned.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.