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] random-seed: break ordering cycle with encrypted tmp partitions
Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. Of course, it would be best to have also confirmation from Michal ;) -- 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] random-seed: break ordering cycle with encrypted tmp partitions
Zitat von Frederic Crozat fcro...@suse.com: Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. I wonder what will happen with this patch if /var/lib/random-seed is missing at startup! timeout? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le vendredi 06 janvier 2012 à 17:17 +0100, Thomas Meyer a écrit : Zitat von Frederic Crozat fcro...@suse.com: Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. I wonder what will happen with this patch if /var/lib/random-seed is missing at startup! timeout? Good question. I'd say it will wait forever for it to appear. Maybe we should ensure this file is create in systemd installation ? -- 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
[systemd-devel] Git repository moved
(see https://bugs.freedesktop.org/show_bug.cgi?id=44427 for background) I've moved the git repository from ssh://git.freedesktop.org/git/systemd.git (or git://git.freedesktop.org/git/systemd.git ) to ssh://git.freedesktop.org/git/system/systemd.git git://git.freedesktop.org/git/systemd/systemd.git Since git doesn't have a way to issue redirects, I've broken the old location and you'll have to just update your git config. (If git had redirects, I could at least have let people see them for a bit.) Sorry about the inconvenience, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ 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
[systemd-devel] [patch] build: do not touch CFLAGS
parent ba1d5596354e3299d5b9b995bb0fa9b3bdd285cc (v37-278-gba1d559) commit 7aee03e8cd7cf1ab9de14dc293c6f994970ce9fa Author: Jan Engelhardt jeng...@medozas.de Date: Fri Jan 6 12:02:55 2012 +0100 build: do not touch CFLAGS Per the automake manual section 3.6 Variables reserved for the user, CFLAGS should _not_ be touched. Right now, one cannot successfully complete `make CFLAGS=-fvisibility=default`, because systemd flags are always appended and thus override the user's wish. Furthermore, it overrides per_target_CFLAGS, which is also undesired. --- configure.ac |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index ef9bfc1..43a8ab6 100644 --- a/configure.ac +++ b/configure.ac @@ -66,6 +66,8 @@ if test -z $GPERF ; then AC_MSG_ERROR([*** gperf not found]) fi +saved_CFLAGS=$CFLAGS +CFLAGS= CC_CHECK_CFLAGS_APPEND([ \ -pipe \ -Wall \ @@ -110,6 +112,9 @@ CC_CHECK_CFLAGS_APPEND([ \ -fdata-sections \ -Wl,--as-needed \ -Wl,--gc-sections]) +AM_CFLAGS=$CFLAGS +CFLAGS=$saved_CFLAGS +AC_SUBST([AM_CFLAGS]) LT_PREREQ(2.2) LT_INIT -- # Created with git-export-patch ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [patch] build: do not touch CFLAGS
On Sat, Jan 7, 2012 at 02:18, Jan Engelhardt jeng...@medozas.de wrote: Per the automake manual section 3.6 Variables reserved for the user, CFLAGS should _not_ be touched. That's right. Right now, one cannot successfully complete `make CFLAGS=-fvisibility=default`, because systemd flags are always appended and thus override the user's wish. That's intentional. We depend on it, and overwriting it breaks stuff. Furthermore, it overrides per_target_CFLAGS, which is also undesired. Guess, we need a cleaner solution, this patch looks even more like a hack. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [patch] build: do not touch CFLAGS
On Saturday 2012-01-07 02:22, Kay Sievers wrote:
Furthermore,
it overrides per_target_CFLAGS, which is also undesired.
Guess, we need a cleaner solution, this patch looks even more like a hack.
From the rather sparse comment I suppose you wanted something like this
instead.
diff --git a/Makefile.am b/Makefile.am
index f5cef3f..7372a12 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -157,6 +157,8 @@ endif
endif
endif
+AM_CFLAGS = ${ac_extra_CFLAGS}
+
rootbin_PROGRAMS = \
systemd \
systemctl \
diff --git a/configure.ac b/configure.ac
index a223b80..03bfb86 100644
--- a/configure.ac
+++ b/configure.ac
@@ -110,6 +110,7 @@ CC_CHECK_CFLAGS_APPEND([ \
-fdata-sections \
-Wl,--as-needed \
-Wl,--gc-sections])
+AC_SUBST([ac_extra_CFLAGS])
LT_PREREQ(2.2)
LT_INIT
diff --git a/m4/attributes.m4 b/m4/attributes.m4
index 9d561c2..bb260d2 100644
--- a/m4/attributes.m4
+++ b/m4/attributes.m4
@@ -71,7 +71,7 @@ AC_DEFUN([CC_CHECK_CFLAG_APPEND], [
)
AS_IF([eval test x$]AS_TR_SH([cc_cv_cflags_$1])[ = xyes],
-[CFLAGS=$CFLAGS $1; DEBUG_CFLAGS=$DEBUG_CFLAGS $1; $2], [$3])
+[ac_extra_CFLAGS=$ac_extra_CFLAGS $1; DEBUG_CFLAGS=$DEBUG_CFLAGS $1;
$2], [$3])
])
dnl CC_CHECK_CFLAGS_APPEND([FLAG1 FLAG2], [action-if-found], [action-if-not])
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [patch] build: do not touch CFLAGS
On Sat, Jan 7, 2012 at 04:34, Jan Engelhardt jeng...@medozas.de wrote: On Saturday 2012-01-07 02:22, Kay Sievers wrote: Furthermore, it overrides per_target_CFLAGS, which is also undesired. Guess, we need a cleaner solution, this patch looks even more like a hack. From the rather sparse comment I suppose you wanted something like this instead. +++ b/m4/attributes.m4 @@ -71,7 +71,7 @@ AC_DEFUN([CC_CHECK_CFLAG_APPEND], [ ) AS_IF([eval test x$]AS_TR_SH([cc_cv_cflags_$1])[ = xyes], - [CFLAGS=$CFLAGS $1; DEBUG_CFLAGS=$DEBUG_CFLAGS $1; $2], [$3]) + [ac_extra_CFLAGS=$ac_extra_CFLAGS $1; DEBUG_CFLAGS=$DEBUG_CFLAGS $1; $2], [$3]) Yeah, something like that. Not mangling CFLAGS= with the build-sys macros sounds much better. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
