Re: [systemd-devel] PATCH: fix logind on xen
Le samedi 07 janvier 2012 à 00:21 +0100, Lennart Poettering a écrit : On Fri, 06.01.12 23:17, Jan Engelhardt (jeng...@medozas.de) wrote: Where does /dev/console point to? i.e. what is the contents of /sys/class/tty/console/active if you do that? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 Hmm? So it claims tty0 in that file, bug actually no /dev/tty0 device exists? That souinds like a kernel bug to me. 1. xencons=hvc (the modern variant) creates: /dev/hvc0 implied defaults: console=hvc0 sysfs/active: tty0 hvc0 Judging by this the implied default is actually console=tty0 console=hvc0. /dev/tty0..63 exist. 2. xencons=xvc creates: /dev/xvc0 implied defaults: console=tty0 (!) sysfs/active: xvc-1 tty0 (bug?) /dev/tty0..63 exist. Judging by this the implied default is actually console=xvc-1 console=tty0. I do wonder where the -1 comes from, is there an actual device called /dev/xvc-1? 3. xencons=tty creates: nothing new implied defaults: console=tty1 sysfs/active: tty-1 tty0 (bug) /dev/tty1..63 exist (!), no tty0. Judging by this the implied default is actually console=tty-1 console=tty0. What's this supposed to mean anyway? That Xen emulates a traditional VC of some kind? It's doing a very bad job in that if /dev/tty0 isn't there... And what is tty-1 supposed to be? Is there an actual device called /dev/tty-1? 4. xencons=ttyS creates: /dev/ttyS0 implied defaults: console=tty0 sysfs/active: ttyS-1 tty0 (bug...) /dev/tty0..63 exist. Judging by this the implied default is actually console=ttyS-1 console=tty0. Thinking a bit about this my guess is Xen stores -1 as a number for the device somewhere and the code that formats the active string is a bit confused about that. While it probably means that no such console is configured the kernel just formats it as-is. Kay, you wrote that code, say something! And the 3rd setup apparently shows an additional bug. Both these issues are clearly kernel bugs, and should be fixed in the kernel. Somebody who cares about this should file bugs against the kernel. I'll ask our Xen folks if they can have a look at it. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
Le mardi 03 janvier 2012 à 21:52 +0100, Lennart Poettering a écrit : On Tue, 03.01.12 21:35, Lennart Poettering (lenn...@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. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
On Fri, 06.01.12 14:59, Frederic Crozat (fcro...@suse.com) wrote: Le mardi 03 janvier 2012 à 21:52 +0100, Lennart Poettering a écrit : On Tue, 03.01.12 21:35, Lennart Poettering (lenn...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
Le vendredi 06 janvier 2012 à 18:16 +0100, Lennart Poettering a écrit : On Fri, 06.01.12 14:59, Frederic Crozat (fcro...@suse.com) wrote: Le mardi 03 janvier 2012 à 21:52 +0100, Lennart Poettering a écrit : On Tue, 03.01.12 21:35, Lennart Poettering (lenn...@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? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 With your patch, no session is assigned to this particular login. Note that we consider serial logins much like ssh logins as virtual, i.e. not physical, and hence with no seat assigned. Wrong choice of word on my side, I was meaning : ssh login are seen as sessions without seats in systemd-loginctl. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
On Fri, 06.01.12 18:33, Frederic Crozat (fcro...@suse.com) wrote: 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? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 Hmm? So it claims tty0 in that file, bug actually no /dev/tty0 device exists? That souinds like a kernel bug to me. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
On Friday 2012-01-06 18:37, Lennart Poettering wrote: console logins? What exactly is that? Logins on /dev/console? In /etc/inittab: cons:12345:respawn:/sbin/smart_agetty -L 38400 console (Solaris 8 did something similar, as it does not have a tty multiplex on console like Linux by default.) The reason to use this - with sysvinit-based systems - is that, if I would specify hvc:12345:respawn:/sbin/smart_agetty -L 38400 hvc0 instead, spawning the getty on hvc0 could repeatedly fail if the particular xen guest image used xencons=tty instead of xencons=hvc0. In case of systemd, that is all a no-brainer, because systemd spawns gettys on the console= device automatically and one does not have to think about it. Where does /dev/console point to? i.e. what is the contents of /sys/class/tty/console/active if you do that? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 Hmm? So it claims tty0 in that file, bug actually no /dev/tty0 device exists? That souinds like a kernel bug to me. 1. xencons=hvc (the modern variant) creates: /dev/hvc0 implied defaults: console=hvc0 sysfs/active: tty0 hvc0 /dev/tty0..63 exist. 2. xencons=xvc creates: /dev/xvc0 implied defaults: console=tty0 (!) sysfs/active: xvc-1 tty0 (bug?) /dev/tty0..63 exist. 3. xencons=tty creates: nothing new implied defaults: console=tty1 sysfs/active: tty-1 tty0 (bug) /dev/tty1..63 exist (!), no tty0. 4. xencons=ttyS creates: /dev/ttyS0 implied defaults: console=tty0 sysfs/active: ttyS-1 tty0 (bug...) /dev/tty0..63 exist. What a mess... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
On Fri, 06.01.12 23:17, Jan Engelhardt (jeng...@medozas.de) wrote: Where does /dev/console point to? i.e. what is the contents of /sys/class/tty/console/active if you do that? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 Hmm? So it claims tty0 in that file, bug actually no /dev/tty0 device exists? That souinds like a kernel bug to me. 1. xencons=hvc (the modern variant) creates: /dev/hvc0 implied defaults: console=hvc0 sysfs/active: tty0 hvc0 Judging by this the implied default is actually console=tty0 console=hvc0. /dev/tty0..63 exist. 2. xencons=xvc creates: /dev/xvc0 implied defaults: console=tty0 (!) sysfs/active: xvc-1 tty0 (bug?) /dev/tty0..63 exist. Judging by this the implied default is actually console=xvc-1 console=tty0. I do wonder where the -1 comes from, is there an actual device called /dev/xvc-1? 3. xencons=tty creates: nothing new implied defaults: console=tty1 sysfs/active: tty-1 tty0 (bug) /dev/tty1..63 exist (!), no tty0. Judging by this the implied default is actually console=tty-1 console=tty0. What's this supposed to mean anyway? That Xen emulates a traditional VC of some kind? It's doing a very bad job in that if /dev/tty0 isn't there... And what is tty-1 supposed to be? Is there an actual device called /dev/tty-1? 4. xencons=ttyS creates: /dev/ttyS0 implied defaults: console=tty0 sysfs/active: ttyS-1 tty0 (bug...) /dev/tty0..63 exist. Judging by this the implied default is actually console=ttyS-1 console=tty0. Thinking a bit about this my guess is Xen stores -1 as a number for the device somewhere and the code that formats the active string is a bit confused about that. While it probably means that no such console is configured the kernel just formats it as-is. Kay, you wrote that code, say something! And the 3rd setup apparently shows an additional bug. Both these issues are clearly kernel bugs, and should be fixed in the kernel. Somebody who cares about this should file bugs against the kernel. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
On Tue, 03.01.12 14:27, Frederic Crozat (fcro...@suse.com) wrote: Le lundi 19 décembre 2011 à 17:23 +0100, Frederic Crozat a écrit : Hi, 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()). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
On Tue, 03.01.12 21:35, Lennart Poettering (lenn...@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. I haven't tested this since I don't have S390 nor Xen. Would be cool if you could test this. (though right now is not the ideal point in time, because systemd git is a bit borked. please wait a few days in order not to burn your fingers on it.) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix logind on xen
Hi,
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.
Attached patch fixes this issue.
--
Frederic Crozat fcro...@suse.com
SUSE
From b40e075944c72a3fc45796c1d059673cef7c7db8 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Mon, 19 Dec 2011 17:17:09 +0100
Subject: [PATCH] logind: do not abort if /dev/tty0 doesn't exist
Xen or S/390 might not have /dev/tty0, logind should cope with it.
---
src/logind.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/logind.c b/src/logind.c
index 4633a5e..f491cee 100644
--- a/src/logind.c
+++ b/src/logind.c
@@ -906,6 +906,8 @@ static int manager_connect_console(Manager *m) {
m-console_active_fd = open(/sys/class/tty/tty0/active, O_RDONLY|O_NOCTTY|O_CLOEXEC);
if (m-console_active_fd 0) {
+if (errno == ENOENT)
+ return 0;
log_error(Failed to open /sys/class/tty/tty0/active: %m);
return -errno;
}
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
