Re: [systemd-devel] [PATCH] Add -lresolv to libudev LIBADD
On Fri, Feb 21, 2014 at 4:58 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2014-02-21 pią 16:22, when Lennart Poettering wrote: On Fri, 21.02.14 15:54, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Fix problems with unresolved symbols when building on Ubuntu 12.04 x86_64. --8---cut here---start-8--- ./.libs/libudev.so: undefined reference to `__res_search' ./.libs/libudev.so: undefined reference to `__res_query' collect2: ld returned 1 exit status --8---cut here---end---8--- This doesn't look right. libudev really shouldn't need libresolv. We should figure out how these calls got pulled in... Let me go step-by-step: --8---cut here---start-8--- $ strings ./.libs/libudev.so | grep __res_'\(query\|search\)' __res_query __res_search # libudev needs libsystemd-internal $ strings ./.libs/libsystemd-internal.a | grep __res_'\(query\|search\)' This does not seem to happen here. Are you sure that as-needed is working in your setup? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] build-sys: Also move libsystemd-journal to rootlibdir
On Sat, Feb 22, 2014 at 3:22 PM, Armin K kre...@email.com wrote: --- Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index e25d532..b1f0670 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4479,11 +4479,13 @@ lib_LTLIBRARIES += \ # move lib from $(libdir) to $(rootlibdir) and update devel link, if needed compat-lib-install-hook: libname=libsystemd-login.so $(move-to-rootlibdir) + libname=libsystemd-journal.so $(move-to-rootlibdir) libname=libsystemd-id128.so $(move-to-rootlibdir) libname=libsystemd-daemon.so $(move-to-rootlibdir) Hmm, that is already in the libsystemd section and does not belong in the compat libs section. Please check does not work for you? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] build-sys: Always install compat pkg-config files
On Sat, Feb 22, 2014 at 3:21 PM, Armin K kre...@email.com wrote: Packages are still looking for the old pkg-config files, so until everything has been ported over, install them always, no matter if compat-libs are built or not. So far, we think that compat should stay compat, and not mix with the non-compat stuff. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] build-sys: Also move libsystemd-journal to rootlibdir
On Sat, Feb 22, 2014 at 5:48 PM, Armin K. kre...@email.com wrote:
On 02/22/2014 05:44 PM, Kay Sievers wrote:
On Sat, Feb 22, 2014 at 3:22 PM, Armin K kre...@email.com wrote:
---
Makefile.am | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index e25d532..b1f0670 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4479,11 +4479,13 @@ lib_LTLIBRARIES += \
# move lib from $(libdir) to $(rootlibdir) and update devel link, if needed
compat-lib-install-hook:
libname=libsystemd-login.so $(move-to-rootlibdir)
+ libname=libsystemd-journal.so $(move-to-rootlibdir)
libname=libsystemd-id128.so $(move-to-rootlibdir)
libname=libsystemd-daemon.so $(move-to-rootlibdir)
Hmm, that is already in the libsystemd section and does not belong in
the compat libs section.
Please check does not work for you?
When --enable-compat-libs is used, and rootlibdir != libdir,
libsystemd-{login,id128,daemon}.so.* (versioned libraries) get installed
in rootlibdir, but libsystemd-daemon.so.* remains in libdir. Either
don't move any or move them all, simple as that.
Ah, I mis-read that as libsystemd.so, sorry, simple as that.
Applied.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH/RFC] gudev: add device::get_sysfs_attr_keys() and device::has_sysfs_attr()
On Sat, Feb 22, 2014 at 11:55 AM, Andreas Fuchs andu...@gmail.com wrote: Ok, I'll try my luck with git send-email then. I was unaware of this gmail-oddity. Sorry about that. Any ideas, why lubudev consideres so many things as attributes ? What do you mean with attributes? Attributes are just the files in /sys below a device directory. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] gudev: add device::get_sysfs_attr_keys and device::has_sysfs_attr
On Sat, Feb 22, 2014 at 12:02 PM, Andreas Fuchs andu...@gmail.com wrote: For gudev - gudevdevice: - Add support for get_sysfs_attr_keys() - Add support for has_sysfs_attr() Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix SECCOMP_CFLAGS usage
On Sat, Feb 22, 2014 at 2:54 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: This is broken again... In file included from ./src/core/unit.h:40:0, from src/shared/condition-util.c:35: ./src/core/execute.h:37:21: fatal error: seccomp.h: No such file or directory #include seccomp.h ^ compilation terminated. Added it where needed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] discussions of pkg-config black magic over at gentoo
On Thu, Feb 20, 2014 at 7:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 20.02.14 19:31, Jason A. Donenfeld (ja...@zx2c4.com) wrote: So right now we're considering something like this [2] or [3]. A bit of a bummer to patch the build system like this, but we don't want to rely on IFUNC, and this seems like the cleanest solution. So I thought I'd mention this up here in case folks have opinions and such. Harald found a way to do what we want to do without ifunc. Expect this to be fixed shortly in git. And we are likely going to do another release soon. Maybe today, maybe tomorrow. We now just build the compat libraries from the code and don't use indirect functions. Not nice, but should work fine and not require any magic. Please test systemd git if the compat stuff works for you now. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 5:41 PM, Justin Brown justin.br...@fandingo.org wrote: On Mon, Feb 24, 2014 at 11:59 PM, Kay Sievers k...@vrfy.org wrote: On Tue, Feb 25, 2014 at 4:26 AM, Justin Brown justin.br...@fandingo.org wrote: I've been reading over some of the articles about KDBus and have a question about reclaiming memfds. Let's say that I have a process which is sending out a large amount of data over lots of signals, and there are more than one potential subscriber. Is there (or will there be) any mechanism that these signals can expire after some conditions are met, or will the data just continue to build-up in each subscriber until it frees the memfds? Additionally, would there be a way to automatically expire these signals after a period of time, once a certain number of signals are received, or preferably once a certain amount of data are received? If that is (or will be) possible, any idea how the subscriber would be handle signals expiring. Memfds or other fds cannot be broadcasted, only attached to directed messages. Thanks for the response. In that case, how efficient are signals in comparison to methods with kdbus? I was under the impression that memfds are one of the fundamental reason that kdbus will be suitable for sending large data payloads. There is not real difference, everything is just a message, being a signal or a method. Only signals are limited to pure copied data, disallowing fds; therefore signals will not be suitable for really large data. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 7:25 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 25/02/14 17:30, Kay Sievers wrote: There is not real difference, everything is just a message, being a signal or a method. Only signals are limited to pure copied data, disallowing fds; therefore signals will not be suitable for really large data. D-Bus allows unicast signals (libdbus API: non-NULL destination). Does kdbus distinguish between methods and (broadcast or unicast) signals, or is the distinction actually between unicast (method, signal or reply) messages and broadcast signals? If the distinction is between unicast and broadcast, this seems a good simplification. We only allow sending of fds to a specific connection, it checks: if (msg-dst_id == KDBUS_DST_ID_BROADCAST) return -ENOTUNIQ; The type of message does not matter. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 9:18 PM, Justin Brown justin.br...@fandingo.org wrote: On Tue, Feb 25, 2014 at 12:12 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 25.02.14 10:41, Justin Brown (justin.br...@fandingo.org) wrote: And broadcast signals should never be large datagrams, but only very short. Could you elaborate on this point? One of the major points of emphasis with kdbus seems to be performance. Why is that restricted to method calls? I understand that there would be implementation complexities in multiplexing memfds to all of the signal subscribers, but it seems like a desirable feature. A single source application that sends relatively large amounts of data (a few KB up to possibly several GB) to several third-party sinks seems like a natural use of memfds. Broadcasting complex kernel objects like file descriptors inside the kernel to many connections at the same time is outside of the focus of kdbus. Things get really fragile very fast if we would allow such things. As far as I can tell, the only way to accomplish this with kdbus would be for the source application to have a subscribe() method, so it could send methods to each sink. I apologize for asking such a simplistic question (I don't have my kdbus VM up and running yet.), but if I were to take this route, can the same memfd be used in multiple methods or would a new one need to be created for each subscriber? You can send any kind of file descriptor many times, therefore also memfds can be send many times. Memfds are special that they can be used to carry *payload* of a dbus message, not only be a naked fd. These memfds need to be sealed to get accepted as payload, but they can be used multiple times too. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pcre in daemons
On Wed, Feb 26, 2014 at 10:22 PM, Daniel J Walsh dwa...@redhat.com wrote: On 02/26/2014 03:05 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Feb 26, 2014 at 08:54:34PM +0100, Thomas H.P. Andersen wrote: The todo says: something pulls in pcre as shared object dependency into our daemons such as hostnamed Normal buiild: ldd ./systemd-hostnamed linux-vdso.so.1 = (0x7fff247bc000) libselinux.so.1 = /lib64/libselinux.so.1 (0x7f7ec47f7000) librt.so.1 = /lib64/librt.so.1 (0x7f7ec45ef000) libdl.so.2 = /lib64/libdl.so.2 (0x7f7ec43ea000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f7ec41cd000) libc.so.6 = /lib64/libc.so.6 (0x7f7ec3e0e000) /lib64/ld-linux-x86-64.so.2 (0x7f7ec4a2f000) libpcre.so.1 = /lib64/libpcre.so.1 (0x7f7ec3ba7000) liblzma.so.5 = /lib64/liblzma.so.5 (0x7f7ec3982000) It's a selinux problem (or not, if it actually uses pcre's). ldd /lib64/libselinux.so.1 linux-vdso.so.1 = (0x7fff58bfe000) libpcre.so.1 = /lib64/libpcre.so.1 (0x00380340) liblzma.so.5 = /lib64/liblzma.so.5 (0x0035d680) libdl.so.2 = /lib64/libdl.so.2 (0x0035d2c0) libc.so.6 = /lib64/libc.so.6 (0x0035d200) /lib64/ld-linux-x86-64.so.2 (0x0035d180) libpthread.so.0 = /lib64/libpthread.so.0 (0x0035d280) libselinux and systemd take advantage of pcre for speeding up the handling of reading in the labeling file. Well, it's the crazy _init constructor that libselinux needs that pulls that in as a first-level dependency. People should just not use that insane stuff. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RTC on BeagleBone Black or embedded platforms
On Thu, Feb 27, 2014 at 4:46 PM, Mike bellyac...@gmail.com wrote: My biggest dilemma at this time right now is with the RTC. The BeagleBone Black does have a RTC and it gets assigned to /dev/rtc0. There is however now battery backup for this device. Assuming you meant no? I've added a DS1307 with a battery to allow having a somewhat sane date maintained. Therein lies the dilemma, the code is only setup to access /dev/rtc. I'm sure that I can figure out with a (gasp) shell script or small c program how to set / get the date from the DS1307, it just seems that would be a very crude kludge. Can't you set the kernel config to use the new clock as the system rtc? It's a kernel config option. Can't you write a udev rule that creates /dev/rtc for your new clock? That should be picked up from userspace, but userspace does not do the initial sync from the hardware to the system, we only do that in the kernel so far. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] tmpfiles: implement --transform=rpm
On Sun, Mar 2, 2014 at 3:06 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: +--transform=rpm Create files list suitable for RPM %%files section\n Hmm, can't we maybe come up with something that isn't specific to rpm or dpkg, something that is easily parsed but not bound to the internals of the format of the files? It sounds like the-wrong-way-around to encode packaging formats into high-level systemd tools. In the end, both formats are really a blast from the past, and represent the status quo, but are surely not the future of how packaging of of a modern Linux system should look like, so it might be nicer to make it generic? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus vs. pipe based ipc performance
On Mon, Mar 3, 2014 at 10:35 PM, Stefan Westerfeld ste...@space.twc.de wrote: First of all: I'd really like to see kdbus being used as a general purpose IPC layer; so that developers working on client-/server software will no longer need to create their own homemade IPC by using primitives like sockets or similar. Now kdbus is advertised as high performance IPC solution, and compared to the traditional dbus approach, this may well be true. But are the numbers that $ test-bus-kernel-benchmark chart produces impressive? Or to put it in another way: will developers working on client-/server software happily accept kdbus, because it performs as good as a homemade IPC solution would? Or does kdbus add overhead to a degree that some applications can't accept? To answer this, I wrote a program called ibench which passes messages between a client and a server, but instead of using kdbus to do it, it uses traditional pipes. To simulate main loop integration, it uses poll() in cases where a normal client or server application would go into the main loop, and wait to be woken up by filedescriptor activity. Now here are the results I obtained using - AMD Phenom(tm) 9850 Quad-Core Processor - running Fedora 20 64-bit with systemd+kdbus from git - system booted with kdbus and single kernel arguments *** single cpu performance: . SIZECOPY MEMFD KDBUS-MAX IBENCH SPEEDUP 1 32580 16390 32580 192007 5.89 2 40870 16960 40870 191730 4.69 4 40750 16870 40750 190938 4.69 8 40930 16950 40930 191234 4.67 16 40290 17150 40290 192041 4.77 32 40220 18050 40220 191963 4.77 64 40280 16930 40280 192183 4.77 128 40530 17440 40530 191649 4.73 256 40610 17610 40610 190405 4.69 512 40770 16690 40770 188671 4.63 1024 40670 17840 40670 185819 4.57 2048 40510 17780 40510 181050 4.47 4096 39610 17330 39610 154303 3.90 8192 38000 16540 38000 121710 3.20 16384 35900 15050 35900 80921 2.25 32768 31300 13020 31300 54062 1.73 65536 243009940 24300 27574 1.13 131072 167306820 16730 14886 0.89 26214444204080 44206888 1.56 52428816602040 20402781 1.36 1048576 800 950 9501231 1.30 2097152 310 490 490 475 0.97 4194304 150 240 240 227 0.95 *** dual cpu performance: . SIZECOPY MEMFD KDBUS-MAX IBENCH SPEEDUP 1 31680 14000 31680 104664 3.30 2 34960 14290 34960 104926 3.00 4 34930 14050 34930 104659 3.00 8 24610 13300 24610 104058 4.23 16 33840 14740 33840 103800 3.07 32 33880 14400 33880 103917 3.07 64 34180 14220 34180 103349 3.02 128 34540 14260 34540 102622 2.97 256 37820 14240 37820 102076 2.70 512 37570 14270 37570 99105 2.64 1024 37570 14780 37570 96010 2.56 2048 21640 13330 21640 89602 4.14 4096 23430 13120 23430 73682 3.14 8192 34350 12300 34350 59827 1.74 16384 25180 10560 25180 43808 1.74 32768 202109700 20210 21112 1.04 65536 154407820 15440 10771 0.70 131072 116305670 116305775 0.50 26214440803730 40803012 0.74 52428818302040 20401421 0.70 1048576 810 950 950 631 0.66 2097152 310 490 490 269 0.55 4194304 150 240 240 133 0.55 I ran the tests twice - once using the same cpu for client and server (via cpu affinity) and once using a different cpu for client and server. The SIZE, COPY and MEMFD column are produced by test-bus-kernel-benchmark chart, the KDBUS-MAX column is the maximum of the COPY and MEMFD column. So this is the effective number of roundtrips that kdbus is able to do at that SIZE. The IBENCH column is the effective number of roundtrips that ibench can do at that SIZE. For many relevant cases, ibench outperforms kdbus (a lot). The SPEEDUP factor indicates how much faster ibench is than kdbus. For small to medium array sizes, ibench always wins (sometimes a lot). For instance passing a 4Kb array from client to server and returning back, ibench is 3.90 times faster if client and server live on the same cpu, and 3.14 times faster if client and server live on different cpus. I'm bringing this up now because it would be sad if kdbus became part of the kernel and universally available,
Re: [systemd-devel] kdbus vs. pipe based ipc performance
On Mon, Mar 3, 2014 at 11:06 PM, Kay Sievers k...@vrfy.org wrote: On Mon, Mar 3, 2014 at 10:35 PM, Stefan Westerfeld ste...@space.twc.de wrote: First of all: I'd really like to see kdbus being used as a general purpose IPC layer; so that developers working on client-/server software will no longer need to create their own homemade IPC by using primitives like sockets or similar. Now kdbus is advertised as high performance IPC solution, and compared to the traditional dbus approach, this may well be true. But are the numbers that $ test-bus-kernel-benchmark chart produces impressive? Or to put it in another way: will developers working on client-/server software happily accept kdbus, because it performs as good as a homemade IPC solution would? Or does kdbus add overhead to a degree that some applications can't accept? To answer this, I wrote a program called ibench which passes messages between a client and a server, but instead of using kdbus to do it, it uses traditional pipes. To simulate main loop integration, it uses poll() in cases where a normal client or server application would go into the main loop, and wait to be woken up by filedescriptor activity. Now here are the results I obtained using - AMD Phenom(tm) 9850 Quad-Core Processor - running Fedora 20 64-bit with systemd+kdbus from git - system booted with kdbus and single kernel arguments *** single cpu performance: . SIZECOPY MEMFD KDBUS-MAX IBENCH SPEEDUP 1 32580 16390 32580 192007 5.89 2 40870 16960 40870 191730 4.69 4 40750 16870 40750 190938 4.69 8 40930 16950 40930 191234 4.67 16 40290 17150 40290 192041 4.77 32 40220 18050 40220 191963 4.77 64 40280 16930 40280 192183 4.77 128 40530 17440 40530 191649 4.73 256 40610 17610 40610 190405 4.69 512 40770 16690 40770 188671 4.63 1024 40670 17840 40670 185819 4.57 2048 40510 17780 40510 181050 4.47 4096 39610 17330 39610 154303 3.90 8192 38000 16540 38000 121710 3.20 16384 35900 15050 35900 80921 2.25 32768 31300 13020 31300 54062 1.73 65536 243009940 24300 27574 1.13 131072 167306820 16730 14886 0.89 26214444204080 44206888 1.56 52428816602040 20402781 1.36 1048576 800 950 9501231 1.30 2097152 310 490 490 475 0.97 4194304 150 240 240 227 0.95 *** dual cpu performance: . SIZECOPY MEMFD KDBUS-MAX IBENCH SPEEDUP 1 31680 14000 31680 104664 3.30 2 34960 14290 34960 104926 3.00 4 34930 14050 34930 104659 3.00 8 24610 13300 24610 104058 4.23 16 33840 14740 33840 103800 3.07 32 33880 14400 33880 103917 3.07 64 34180 14220 34180 103349 3.02 128 34540 14260 34540 102622 2.97 256 37820 14240 37820 102076 2.70 512 37570 14270 37570 99105 2.64 1024 37570 14780 37570 96010 2.56 2048 21640 13330 21640 89602 4.14 4096 23430 13120 23430 73682 3.14 8192 34350 12300 34350 59827 1.74 16384 25180 10560 25180 43808 1.74 32768 202109700 20210 21112 1.04 65536 154407820 15440 10771 0.70 131072 116305670 116305775 0.50 26214440803730 40803012 0.74 52428818302040 20401421 0.70 1048576 810 950 950 631 0.66 2097152 310 490 490 269 0.55 4194304 150 240 240 133 0.55 I ran the tests twice - once using the same cpu for client and server (via cpu affinity) and once using a different cpu for client and server. The SIZE, COPY and MEMFD column are produced by test-bus-kernel-benchmark chart, the KDBUS-MAX column is the maximum of the COPY and MEMFD column. So this is the effective number of roundtrips that kdbus is able to do at that SIZE. The IBENCH column is the effective number of roundtrips that ibench can do at that SIZE. For many relevant cases, ibench outperforms kdbus (a lot). The SPEEDUP factor indicates how much faster ibench is than kdbus. For small to medium array sizes, ibench always wins (sometimes a lot). For instance passing a 4Kb array from client to server and returning back, ibench is 3.90 times faster if client and server live on the same cpu, and 3.14 times faster if client and server live on different cpus. I'm bringing this up now because
Re: [systemd-devel] kdbus vs. pipe based ipc performance
On Tue, Mar 4, 2014 at 5:00 AM, Kay Sievers k...@vrfy.org wrote: On Mon, Mar 3, 2014 at 11:06 PM, Kay Sievers k...@vrfy.org wrote: On Mon, Mar 3, 2014 at 10:35 PM, Stefan Westerfeld ste...@space.twc.de wrote: First of all: I'd really like to see kdbus being used as a general purpose IPC layer; so that developers working on client-/server software will no longer need to create their own homemade IPC by using primitives like sockets or similar. Now kdbus is advertised as high performance IPC solution, and compared to the traditional dbus approach, this may well be true. But are the numbers that $ test-bus-kernel-benchmark chart produces impressive? Or to put it in another way: will developers working on client-/server software happily accept kdbus, because it performs as good as a homemade IPC solution would? Or does kdbus add overhead to a degree that some applications can't accept? To answer this, I wrote a program called ibench which passes messages between a client and a server, but instead of using kdbus to do it, it uses traditional pipes. To simulate main loop integration, it uses poll() in cases where a normal client or server application would go into the main loop, and wait to be woken up by filedescriptor activity. Now here are the results I obtained using - AMD Phenom(tm) 9850 Quad-Core Processor - running Fedora 20 64-bit with systemd+kdbus from git - system booted with kdbus and single kernel arguments *** single cpu performance: . SIZECOPY MEMFD KDBUS-MAX IBENCH SPEEDUP 1 32580 16390 32580 192007 5.89 2 40870 16960 40870 191730 4.69 4 40750 16870 40750 190938 4.69 8 40930 16950 40930 191234 4.67 16 40290 17150 40290 192041 4.77 32 40220 18050 40220 191963 4.77 64 40280 16930 40280 192183 4.77 128 40530 17440 40530 191649 4.73 256 40610 17610 40610 190405 4.69 512 40770 16690 40770 188671 4.63 1024 40670 17840 40670 185819 4.57 2048 40510 17780 40510 181050 4.47 4096 39610 17330 39610 154303 3.90 8192 38000 16540 38000 121710 3.20 16384 35900 15050 35900 80921 2.25 32768 31300 13020 31300 54062 1.73 65536 243009940 24300 27574 1.13 131072 167306820 16730 14886 0.89 26214444204080 44206888 1.56 52428816602040 20402781 1.36 1048576 800 950 9501231 1.30 2097152 310 490 490 475 0.97 4194304 150 240 240 227 0.95 *** dual cpu performance: . SIZECOPY MEMFD KDBUS-MAX IBENCH SPEEDUP 1 31680 14000 31680 104664 3.30 2 34960 14290 34960 104926 3.00 4 34930 14050 34930 104659 3.00 8 24610 13300 24610 104058 4.23 16 33840 14740 33840 103800 3.07 32 33880 14400 33880 103917 3.07 64 34180 14220 34180 103349 3.02 128 34540 14260 34540 102622 2.97 256 37820 14240 37820 102076 2.70 512 37570 14270 37570 99105 2.64 1024 37570 14780 37570 96010 2.56 2048 21640 13330 21640 89602 4.14 4096 23430 13120 23430 73682 3.14 8192 34350 12300 34350 59827 1.74 16384 25180 10560 25180 43808 1.74 32768 202109700 20210 21112 1.04 65536 154407820 15440 10771 0.70 131072 116305670 116305775 0.50 26214440803730 40803012 0.74 52428818302040 20401421 0.70 1048576 810 950 950 631 0.66 2097152 310 490 490 269 0.55 4194304 150 240 240 133 0.55 I ran the tests twice - once using the same cpu for client and server (via cpu affinity) and once using a different cpu for client and server. The SIZE, COPY and MEMFD column are produced by test-bus-kernel-benchmark chart, the KDBUS-MAX column is the maximum of the COPY and MEMFD column. So this is the effective number of roundtrips that kdbus is able to do at that SIZE. The IBENCH column is the effective number of roundtrips that ibench can do at that SIZE. For many relevant cases, ibench outperforms kdbus (a lot). The SPEEDUP factor indicates how much faster ibench is than kdbus. For small to medium array sizes, ibench always wins (sometimes a lot). For instance passing a 4Kb array from client to server and returning back, ibench is 3.90 times faster if client and server live on the same cpu, and 3.14 times faster
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Mon, Mar 10, 2014 at 7:34 PM, Goffredo Baroncelli kreij...@libero.it wrote: On 03/07/2014 07:26 PM, Lennart Poettering wrote: Since yesterday systemd in git can now discover root, /home, /srv and swap partitions automatically based on GPT type GUIDs, thus making /etc/fstab unnecessary for simple setups. I have now put together something like a spec describing the logic behind that, and what it is good for: http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ Form the FAQ: CITE [...] What about automatic mounting of btrfs subvolumes to /var, /home and so on? Doing a similar automatic discovery of btrfs subvolumes and mounting them automatically to the appropriate places is certainly desirable. We are waiting for the btrfs designers to add a per-subvolume type UUID to their disk format to make this possible. [...] /CITE Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them. As a general rule: human-readable names should be left to the administrator, provide an identifier for humans, and should not be overloaded with magic machine behavior. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: properly detect reference to unexisting part of PROGRAM's result
On Mon, Feb 24, 2014 at 5:06 PM, Lukas Nykryn lnyk...@redhat.com wrote: --- src/udev/udev-event.c | 2 ++ 1 file changed, 2 insertions(+) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
On Tue, Mar 11, 2014 at 11:42 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote: Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. Hmm, wouldn't it be nicer to just drop the --relative here? Quite honestly, I don't grok the code, neither the old nor the new one... The output of tree after the patch with the split-usr mode looks fine here. Applied it. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][v3.13][v3.14][Regression] kthread:makekthread_create()killable
On Wed, Mar 19, 2014 at 4:54 PM, Joseph Salisbury joseph.salisb...@canonical.com wrote: A kernel bug report was opened against Ubuntu[0]. We performed a kernel bisect, and found that a change introduced by upstream linux kernel commit 786235eeb introduced the bug as of v3.13-rc1. The bug indicates an issue with the SAS controller during initialization, which prevents the system from booting. There has been an on-going discussion on LKML[1] regarding this issue. It was found that this bug can be avoiding by increasing systemd-udevd's 30 seconds timeout. We were hoping to get some feedback from the systemd maintainers to see if it possible to increase the timeout to 120 seconds, or if there would be any possible complications with doing that? Kernel modules should never take more than 30 seconds during loading. The modprobe task is for *linking-in* modules into the kernel, not to *run* unpredictable device initialization tasks; they should run asynchronously, and modprobe should return as soon as the driver itself is initialized, not the devices it drives. You migh be able to work around the timeout with udev rules and OPTIONS+=event_timeout=120, but that code was maybe never used or tested, so it might not work correctly. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Building systemd from git
On Thu, Mar 20, 2014 at 3:02 PM, Kevin Wilson wkev...@gmail.com wrote: Thanks, Zbyszek. --prefix etc. I assume you mean: --prefix /etc and not prefix /etc is it so ? No. Just check out git and run ./autogen.sh, it will tell you what to do. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh tho...@t-8ch.de wrote: While trying to use the discovereable partitions stuff I ran into the following: Running systemd-efi-boot-generator on my machine results in: Failed to read ESP partition UUID: Input/output error The cause for this is that, the efi variable LoaderDevicePartUUID which is supposed to hold an UUID only contains the literal string ESP, which can't be parsed by systemd. What does this say on your box? $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh tho...@t-8ch.de wrote: On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh tho...@t-8ch.de wrote: While trying to use the discovereable partitions stuff I ran into the following: Running systemd-efi-boot-generator on my machine results in: Failed to read ESP partition UUID: Input/output error The cause for this is that, the efi variable LoaderDevicePartUUID which is supposed to hold an UUID only contains the literal string ESP, which can't be parsed by systemd. What does this say on your box? $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) Your setup uses the *type* UUID for the EFI system partition as the *object* UUID of the partition? If that's the case, this cannot really work, object UUIDs need to be unique, created from randomness, not pre-defined. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 6:24 PM, Thomas Weißschuh tho...@t-8ch.de wrote: On Fri, Mar 21, 2014 at 06:04:24PM +0100, Kay Sievers wrote: On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh tho...@t-8ch.de wrote: On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh tho...@t-8ch.de wrote: While trying to use the discovereable partitions stuff I ran into the following: Running systemd-efi-boot-generator on my machine results in: Failed to read ESP partition UUID: Input/output error The cause for this is that, the efi variable LoaderDevicePartUUID which is supposed to hold an UUID only contains the literal string ESP, which can't be parsed by systemd. What does this say on your box? $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) Your setup uses the *type* UUID for the EFI system partition as the *object* UUID of the partition? If that's the case, this cannot really work, object UUIDs need to be unique, created from randomness, not pre-defined. This did also seem wrong to me. So it is definitevely a broken system and no configuration error on my part? Whatever tool created the EFI system partition in the GPT table did it wrong. That the well-known UUIDs are translated to a string is a gnuefi lib stupidity. You would need to change the GPT entry to have a random object UUID, then all should work on gummiboot + systemd side. But be careful, if you have Windows installed, it might (I don't know) have trouble when the UUID is changed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] README: Correct EFI requirements
On Sat, Mar 22, 2014 at 1:41 AM, Thomas Bächler tho...@archlinux.org wrote: systemd does not need or use CONFIG_EFI_VARS anywhere, this should be CONFIG_EFIVAR_FS instead. --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Fri, Mar 21, 2014 at 12:35 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Mar 20, 2014 at 10:58:21AM +0100, Daniel Mack wrote:
/* link into parent domain */
if (parent) {
What if 'parent' was already unrefed at this point? That can happen any
time as soon we give up the lock.
Ok yes, but in that case what about the first 'parent' check at line
259 ? we can also race against it? I thought that since we are at this
point, we are sure that the parent won't be unrefed!
The caller should be the parent itself, and as long as the caller has
a file (handle.c) open, the domain of the caller should be pinned into
memory.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack dan...@zonque.org wrote: On 03/21/2014 12:35 PM, Djalal Harouni wrote: I've two questions: 1) Can we improve it in ordre to reduce the lock hold time ? We don't consider that a very frequent operation, so we never thought about optimizing this code path. What use case do you have in mind so that performance would matter much? currently creating a domain will make create/disconnect/open... buses and endpoints on the parent of that domain block, these are separated operations on different domains. I don't quite follow. Can you elaborate? Creating domains and buses are relatively expensive system operations, they involve udev, device node creation, sysfs/driver-core interaction. If you think it's worth, please try it, we just took the easy road so far, not sure how much we can really optimize here. Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. I'll add a few more disconnected checks before we link into the parent objects. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Sat, Mar 22, 2014 at 7:56 PM, Djalal Harouni tix...@opendz.org wrote: On Sat, Mar 22, 2014 at 07:37:38PM +0100, Kay Sievers wrote: On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack dan...@zonque.org wrote: Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. Yes I was thinking of applications that create domains, they wont work if they are inside a container domain! Domain creation at the moment is limited to privileged processes, because we have no limits for accounting or other safeguards in place. Domains are a conceptually bit closer to an OS container, applications should see a custom endpoint or can create their own private buses in the domain they run in. 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. I'll add a few more disconnected checks before we link into the parent objects. Yes, I've located some sites, and I'm trying to do more tests... I'll get back to you, Thanks Daniel, Kay! I've committed a few more guards which check for disconnected, right before we try to link into the parent object. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] endpoint: free the policy_db on error path
On Sun, Mar 23, 2014 at 11:06 PM, Djalal Harouni tix...@opendz.org wrote: Signed-off-by: Djalal Harouni tix...@opendz.org --- endpoint.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] test-kdbus: rename check bus and domain functions
On Sun, Mar 23, 2014 at 11:06 PM, Djalal Harouni tix...@opendz.org wrote: Signed-off-by: Djalal Harouni tix...@opendz.org --- test/test-kdbus.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 212
into the kernel. sd-bus gained support for creating monitoring connections that can eavesdrop into all bus communication for debugging purposes. * Timestamps may now be specified in seconds since the UNIX epoch Jan 1st, 1970 by specifying @ followed by the value in seconds. * Native tcpwrap support in systemd has been removed. tcpwrap is old code, not really maintained anymore and has serious shortcomings, and better options such as firewalls exist. For setups that require tcpwrap usage, please consider invoking your socket-activated service via tcpd, like on traditional inetd. * A new system.conf configuration option DefaultTimerAccuracySec= has been added that controls the default AccuracySec= setting of .timer units. * Timer units gained a new WakeSystem= switch. If enabled timers configured this way will cause the system to resume from system suspend (if the system supports that, which most do these days). * Timer units gained a new Persistent= switch. If enabled timers configured this way will save to disk when they have been last triggered. This information is then used on next reboot to possible execute overdue timer events, that couldn't take place because the system was powered off. This enables simple anacron-like behaviour for timer units. * systemctl's list-timers will now also list the time a timer unit was last triggered in addition to the next time it will be triggered. * systemd-networkd will now assign predictable IPv4LL addresses to its local interfaces. Contributions from: Brandon Philips, Daniel Buch, Daniel Mack, Dave Reisner, David Herrmann, Gerd Hoffmann, Greg Kroah-Hartman, Hendrik Brueckner, Jason St. John, Josh Triplett, Kay Sievers, Lennart Poettering, Marc-Antoine Perennou, Michael Marineau, Michael Olbrich, Miklos Vajna, Patrik Flykt, poma, Sebastian Thorarensen, Thomas Bächler, Thomas Hindoe Paaboel Andersen, Tomasz Torcz, Tom Gundersen, Umut Tezduyar Lindskog, Wieland Hoffmann, Zbigniew Jędrzejewski-Szmek -- Berlin, 2014-03-25 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 212
On Wed, Mar 26, 2014 at 1:45 AM, Stephan Raue mailingli...@openelec.tv wrote: systemd-212 breaks if we run autoreconf before configuring and building with: autoreconf: running: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake --add-missing --copy --force-missing Makefile.am:36: warning: user target '.PRECIOUS' defined here ... /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/share/automake-1.14/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/gudev/Makefile.am:98: 'docs/gtk-doc.make' included from here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/libudev/Makefile.am:92: 'docs/gtk-doc.make' included from here autoreconf: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake failed with exit status: 1 Have you tried passing --disable-gtk-doc to configure? Check ./configure --help. even if there is no change in docs/gtk-doc.make between 211 and 212 the files differs in the tarball. using this patch: https://github.com/OpenELEC/OpenELEC.tv/blob/ae1cb224141c8e7b179619285333fc0dc741b0ac/packages/sysutils/systemd/patches/systemd-212-GTK_DOC.patch This file in not in git, and cannot be patched upstream, it is added by gtk-doc itself. fixes the problem here. (note, we dont build with gtk support and dont have any gtk devel packages installed) It's just a common html doc generator, used for libudev's and gudev's docs, there is no gtk code in systemd. http://www.freedesktop.org/software/systemd/libudev/index.html Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 212
On Wed, Mar 26, 2014 at 2:37 AM, Stephan Raue mailingli...@openelec.tv wrote: Am 26.03.2014 02:16, schrieb Kay Sievers: On Wed, Mar 26, 2014 at 1:45 AM, Stephan Raue mailingli...@openelec.tv wrote: systemd-212 breaks if we run autoreconf before configuring and building with: autoreconf: running: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake --add-missing --copy --force-missing Makefile.am:36: warning: user target '.PRECIOUS' defined here ... /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/share/automake-1.14/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/gudev/Makefile.am:98: 'docs/gtk-doc.make' included from here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/libudev/Makefile.am:92: 'docs/gtk-doc.make' included from here autoreconf: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake failed with exit status: 1 Have you tried passing --disable-gtk-doc to configure? Check ./configure --help. yes we are building with --disable-gtk-doc see: https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/sysutils/systemd/package.mk#L41 but the problem is not at configure time, we do a autoreconf before configuring for every package even if there is no change in docs/gtk-doc.make between 211 and 212 the files differs in the tarball. using this patch: https://github.com/OpenELEC/OpenELEC.tv/blob/ae1cb224141c8e7b179619285333fc0dc741b0ac/packages/sysutils/systemd/patches/systemd-212-GTK_DOC.patch This file in not in git, and cannot be patched upstream, it is added by gtk-doc itself. yes but its part of the tarball, and it seems to be wrong (HAVE_GTK_DOC vs. ENABLE_GTK_DOC) - at least if we compare the file from 211 with the one from 212. It might be a change in upstream gtk-doc, I don't know, I built the tarball with: gtk-doc-1.20-1.fc21.noarch installed, maybe something has change there, we need to find out ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] core: Move user generator directories to XDG_RUNTIME_DIR
On Fri, Mar 28, 2014 at 6:38 PM, Hristo Venev hri...@venev.name wrote: Predictable names and more consistent. --- src/core/manager.c | 48 +++- 1 file changed, 11 insertions(+), 37 deletions(-) diff --git a/src/core/manager.c b/src/core/manager.c -p = strjoin(s, /systemd/, name, NULL); +p = strjoin(/tmp/systemd-, name, .XX, NULL); /tmp is a shared namespace, and no place systemd should use for its own data. That makes not much sense to me. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] core: Put transient user units in XDG_RUNTIME_DIR instead of XDG_CONFIG_HOME.
On Fri, Mar 28, 2014 at 6:38 PM, Hristo Venev hri...@venev.name wrote: They are temporary and should not clutter the configuration directory. --- src/core/unit.c | 32 +++- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/src/core/unit.c b/src/core/unit.c +c = strappend(getenv(XDG_RUNTIME_DIR), /systemd/user); Nesting function calls without error checking should be avoided for systemd code. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] core: Move user generator directories to XDG_RUNTIME_DIR
On Fri, Mar 28, 2014 at 7:41 PM, Hristo Venev hri...@venev.name wrote: On Fri, 2014-03-28 at 19:00 +0100, Kay Sievers wrote: On Fri, Mar 28, 2014 at 6:38 PM, Hristo Venev hri...@venev.name wrote: Predictable names and more consistent. --- src/core/manager.c | 48 +++- 1 file changed, 11 insertions(+), 37 deletions(-) diff --git a/src/core/manager.c b/src/core/manager.c -p = strjoin(s, /systemd/, name, NULL); +p = strjoin(/tmp/systemd-, name, .XX, NULL); /tmp is a shared namespace, and no place systemd should use for its own data. That makes not much sense to me. Kay This line was added in b7def684 by Lennart Poettering in August 2012. Don't blame me that diff is being stupid. Oops, sorry, did not realize that. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Some useful patches
On Fri, Mar 28, 2014 at 7:38 PM, Hristo Venev hri...@venev.name wrote: On Fri, 2014-03-28 at 19:06 +0100, Kay Sievers wrote: On Fri, Mar 28, 2014 at 6:38 PM, Hristo Venev hri...@venev.name wrote: The first patch moves the user generator directories to XDG_RUNTIME_DIR. This way the path for the generator directories is always under the manager's runtime prefix. Consistency and code size. The second patch moves the transient user units to XDG_RUNTIME_DIR. This way they are deleted on reboot just like the system transient units and do not take space in XDG_CONFIG_HOME. The third patch lets transient units set EnvironmentFiles. It can be used in systemd-run like this: systemd-run -p EnvirontmentFiles=fileA fileB fileC Drop-in files for this are not yet implemented. Please include any *why*, along with the *what* in the commit log itself. The commit subject really does not help to explain why something is changed, and that is what matters, in the end; the patch itself usually explains pretty well what is done, but not why. First patch: Consistency and code size. Predictability of the location of the generator directories = easier debugging. Second patch: I DO NOT WANT TRANSIENT UNIT LEFTOVERS IN MY XDG_CONFIG_HOME! Third patch: Isn't it obvious that it's a (very small) new feature? I meant, the *why* you added here, should be in the *commits* themselves, not in the *announce* of them. We want the *why* in the git history, but the announce mail will not be there. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] core: Put transient user units in XDG_RUNTIME_DIR instead of XDG_CONFIG_HOME.
On Fri, Mar 28, 2014 at 7:43 PM, Hristo Venev hri...@venev.name wrote: On Fri, 2014-03-28 at 19:02 +0100, Kay Sievers wrote: On Fri, Mar 28, 2014 at 6:38 PM, Hristo Venev hri...@venev.name wrote: They are temporary and should not clutter the configuration directory. --- src/core/unit.c | 32 +++- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/src/core/unit.c b/src/core/unit.c +c = strappend(getenv(XDG_RUNTIME_DIR), /systemd/user); Nesting function calls without error checking should be avoided for systemd code. Kay This is executed only if the manager is running as user. In case XDG_RUNTIME_DIR isn't set, systemd would fail to start. It should still go into its own variable if you want to skip the check. We should not rely on the behaviour of external functions like that. Even when it is not likely to ever fail, or never even to be called as PID1, it's still the coding pattern that matters, and PID1 code has stricter rules than usual user code. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] kdbus: Check for bloom parameter in make bus command
On Sat, Mar 29, 2014 at 5:54 PM, Ingo van Lil ing...@gmx.de wrote: When handling a KDBUS_CMD_BUS_MAKE command the kernel must make sure that the message contains a bloom parameter item to avoid a null- pointer dereference. Signed-off-by: Ingo van Lil ing...@gmx.de --- bus.c | 2 +- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] endpoint: protect the idr tree on release
On Mon, Mar 31, 2014 at 2:41 AM, Djalal Harouni tix...@opendz.org wrote: endpoint.c | 2 ++ Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] connection: unref ep and bus and free match_db on error path
On Mon, Mar 31, 2014 at 2:41 AM, Djalal Harouni tix...@opendz.org wrote: connection.c | 2 +- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] handle: change return value from -EFAULT to -EPERM
On Mon, Mar 31, 2014 at 2:41 AM, Djalal Harouni tix...@opendz.org wrote: Return -EPERM if current does not have the appropriate privileges to create custom endpoints. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] kdbus: use kdbus_conn_find_peer() where appropriate
On Mon, Mar 31, 2014 at 2:43 AM, Djalal Harouni tix...@opendz.org wrote: connection.c | 7 ++- match.c | 14 ++ names.c | 5 + Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pci.ids confusion
On Sun, Apr 13, 2014 at 6:58 AM, Jerome Leclanche adys...@gmail.com wrote: This is a followup of a chat on #systemd. The pciids-devel list is dead and someone recommended I post here instead. While browsing some debug logs, I came accross a confusing message: systemd[1]: Found device M4A785TD Motherboard. I was even more confused since I don't actually have a M4A785TD but a P7P55D-E DELUXE. Turns out this is one of my two ethernet adapters. Specifically, in hwdata/pci.ids, 1019 8168 RTL8111/8168 PCI Express Gigabit Ethernet controller. Out of curiousity I started digging in the pci.ids file (10ec Realtek Semiconductor Co., Ltd. around line 9120). I'm trying to understand the format but it's looking like motherboards are a subsystem of their own ethernet adapter. This is further confirmed with lspci: 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard I'd love to submit a fix but this is very counter-intuitive. Can anyone shed some light on it? The PCI database contains a lot of wrong, mindlessly added, and inconsistent data; some strings just do not make much sense, and there seems to be not much effort to correct it. I pushed a change to show the primary string too; it is all not pretty, but should be less confusing that what you see today: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d060b62fcb4746d3758c567e9379c6728a035b66 Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
On Mon, Apr 14, 2014 at 9:22 AM, Francis Moreau francis.m...@gmail.com wrote: On 04/14/2014 06:16 PM, Lennart Poettering wrote: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). Does UEFI allow firmware to write to ESP ? If so that would indeed prevent ESP to be on soft RAID. Sure, it does. You can just start an EFI Shell and edit any file in the ESP. The only safe (at least in theory) thing is to have a bios raid driver included in the EFI firmware itself, which sets up the ESP to be the mirrored disks. With that, writes from the firmware will end up on both disks without any operating system involved. Setting up the ESP as a raid without explicit firmware support does not sound like a good idea. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Mon, Apr 14, 2014 at 9:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Not really, because the API relies on the queue tracking data. But for the queue tracking logic to not break current setups, it would need to be updated/rewritten to handle holes in the sequence numbers; with current kernels it is just broken whenever namespaces are involved. We just did not notice, because we do not use settle with systemd. I'm not volunteering to rewrite the logic to handle holes. Instead I'm suggesting that we keep the current (as of before this commit) logic, to cater to people who use it successfully when no namespaces are involved. I don't think it is worth to try to make the specific queue tracking logic work again, it is not a useful API and it makes promises we cannot hold. I'm not suggesting that. But maybe keeping the partially broken logic around for a while might be more useful for some people than outright removal. It is currently broken for our own setups, unit files use namespaces in default setups. We cannot just keep the status quo and pretend it works, things are broken now and need to be fixed. We would need to rewrite the logic behind the API, or get rid of it; I decided for removal, because the assumptions the API makes are not valid anymore. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Mon, Apr 14, 2014 at 10:03 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:51:08AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 9:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Not really, because the API relies on the queue tracking data. But for the queue tracking logic to not break current setups, it would need to be updated/rewritten to handle holes in the sequence numbers; with current kernels it is just broken whenever namespaces are involved. We just did not notice, because we do not use settle with systemd. I'm not volunteering to rewrite the logic to handle holes. Instead I'm suggesting that we keep the current (as of before this commit) logic, to cater to people who use it successfully when no namespaces are involved. I don't think it is worth to try to make the specific queue tracking logic work again, it is not a useful API and it makes promises we cannot hold. I'm not suggesting that. But maybe keeping the partially broken logic around for a while might be more useful for some people than outright removal. It is currently broken for our own setups, unit files use namespaces in default setups. I know. We cannot just keep the status quo and pretend it works, things are broken now and need to be fixed. Yes. We would need to rewrite the logic behind the API, or get rid of it; I decided for removal, because the assumptions the API makes are not valid anymore. Yes, but udev is also used in different setups... Documenting things as deprecated is one thing, but replacing implementation by stub functions is another. People who use this functionality would probably prefer to have some time to move off it. It is not a stub, things will just block for any/all events now, ignoring the specific sequence numbers given in the API. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Handle Unix domain socket connections from outside our namespace
On Thu, Apr 17, 2014 at 4:24 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Apr 16, 2014 at 06:39:07PM +0200, Eelco Dolstra wrote: NixOS uses Unix domain sockets for certain host - container interaction; i.e. the host connects to a socket visible in the container's directory tree, where the container uses a .socket unit to spawn the handler program on demand. This worked in systemd 203, but in 212 fails with foo.socket failed to queue service startup job (Maybe the service file is missing or not a template unit?): No data available. The reason is that getpeercred() now returns ENODATA if it can't get the PID of the client, which happens in this case because the client is not in the same PID namespace. Since getpeercred() is only used to generate the instance name, this patch simply handles ENODATA by creating an instance name nr-unknown. Applied, but I changed the order of clauses in the if, because the thin 'return k' between the two asprintfs was bother me :) PID1 crashes with this code, I have reverted the commit for now. Please have a look. systemd[1]: Code should not be reached 'Unhandled socket type.' at src/core/socket.c:684, function instance_from_socket(). Aborting. systemd[1]: Caught ABRT, dumped core as pid 336. systemd[1]: Freezing execution. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Handle Unix domain socket connections from outside our namespace
On Sun, Apr 20, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: PID1 crashes with this code, I have reverted the commit for now. Please have a look. systemd[1]: Code should not be reached 'Unhandled socket type.' at src/core/socket.c:684, function instance_from_socket(). Aborting. systemd[1]: Caught ABRT, dumped core as pid 336. systemd[1]: Freezing execution. Yikes. I admit I didn't boot the machine with it... sorry. When you tweaked my commit you dropped the break; line, which probably explains the crash :-) Pushed (with the break) again. Works for me. Seems to work fine here too. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Hi Kay, it seems that handles are not crucial, and the simplified version below works too. Is there something I'm missing? The name_to_handle API works properly with bind mounts, it's the more reliable API. It also was intentional to support any filesystem with the prefix devtmpfs*, like devtmpfs2 or whatever it might be named in the future. What actual problem are we trying to solve here with not requiring a common kernel config option? We want/need it in other places too, and the current fallback logic to figure out the mount point is really not that great with bind mounts. We just need the fallback for filesystems which do not support the API, but most common and tmpfs/devtmpfs do. I don't necessarily see the point in supporting the idea of the kernel's uber-configurability and the massive pain it causes for tools to make things work. Looking into the not-to-far future, we will hard-require a specific kernel version to provide us with the new cgroups logic and kdbus functionality to boot up properly; I think we should just document and explain what we need, and fail to boot with a proper error, and not try to work around insufficient kernel configs and compiled-out features we rely on. We should turn the current failure into a real error message though, instead of patching things back to less reliable APIs. Btw, the same applies to the !cgroups config, that code should just be removed and we error out with a proper explanation, instead of booting (or even segfault at the moment) a half-working system and pretend systemd would magically find a way to make it work without cgroups. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/libsystemd src/network src/udev
On Sun, Apr 20, 2014 at 10:48 PM, Tom Gundersen t...@jklm.no wrote:
On Sun, Apr 20, 2014 at 3:16 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sun, Apr 20, 2014 at 05:45:18AM -0700, Tom Gundersen wrote:
commit 6190b9f9d2574428d560458a99f2838041cfdaac
Author: Tom Gundersen t...@jklm.no
Date: Sun Apr 20 07:51:28 2014 +0200
sd-rtnl: log when queues are exhausted
diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c
b/src/libsystemd/sd-rtnl/sd-rtnl.c
index 8650f55..543bad9 100644
--- a/src/libsystemd/sd-rtnl/sd-rtnl.c
+++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
@@ -203,8 +203,10 @@ int sd_rtnl_send(sd_rtnl *nl,
}
} else {
/* append to queue */
-if (nl-wqueue_size = RTNL_WQUEUE_MAX)
+if (nl-wqueue_size = RTNL_WQUEUE_MAX) {
+log_debug(rtnl: exhausted the write queue size
(%d), RTNL_WQUEUE_MAX);
return -ENOBUFS;
+}
Is there a risk of this condition happenning often? Maybe this should be
protected
by a condition to be printed just once, and then it could be at warning
level?
This is extremely unlikely to happen, and if it does surely very bad
things will result from it (best case the program would fail
gracefully I suppose). I added this here simply to easily rule out
this as a source of bugs when debugging similar/related issues.
The reason I didn't make this a higher priority log message is that we
so far only ever use log_debug from libraries. I don't know if we want
to start making exceptions to that? Kay, Lennart?
No, we do not want to log from libs, we should still just properly
propagate such errors back from the lib and log from the caller.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Sun, Apr 20, 2014 at 8:08 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sun, Apr 20, 2014 at 03:53:05PM +0200, Kay Sievers wrote:
On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
Hi Kay,
it seems that handles are not crucial, and the simplified version below
works too. Is there something I'm missing?
The name_to_handle API works properly with bind mounts, it's the more
reliable API.
It also was intentional to support any filesystem with the prefix
devtmpfs*, like devtmpfs2 or whatever it might be named in the
future.
What actual problem are we trying to solve here with not requiring a
common kernel config option? We want/need it in other places too, and
the current fallback logic to figure out the mount point is really not
that great with bind mounts. We just need the fallback for filesystems
which do not support the API, but most common and tmpfs/devtmpfs do.
I don't necessarily see the point in supporting the idea of the
kernel's uber-configurability and the massive pain it causes for tools
to make things work.
Yeah, I'm just trying to reduce the confusion that people experience
on kernels without CONFIG_FHANDLE.
What about this:
8-
Subject: [PATCH] udev: assume /dev is devtmpfs if name_to_handle_at is not
implemented
We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. This raises the possibility of a
false positive when running on a kernel without CONFIG_FHANDLE but in a
container. Nevertheless, this caes should be easier to diagnose than
the opposite of running on bare metal with the same kernel.
I really don't see the problem with hard-requiring a commonly
available kernel feature, especially if it involves returning results
which might be incorrect.
+log_warning(name_to_handle_at syscall failed,
assuming /dev is volatile.);
Libraries should never log for normal operation, only debugging is ok.
+return true;
+}
+return false;
+}
f = fopen(/proc/self/mountinfo, re);
if (!f)
@@ -139,8 +146,7 @@ static bool udev_has_devtmpfs(struct udev *udev) {
continue;
/* accept any name that starts with the currently expected
type */
-if (startswith(e + 3, devtmpfs))
-return true;
+return startswith(e + 3, devtmpfs);
}
If we really wanted that kind of fallback, we should falling back to
parsing mountinfo for devtmpfs and ignoring the mount_id in this
loop. But since we need that syscall not only here, I don't think we
should do that. We should just explain what we need and simply refuse
to bootup, just like we should refuse to bootup without cgroups
available.
Supporting less reliable operation modes for something that just needs
to be configured in the kernel seems the wrong approach, especially
when it involves filesystem operations on user data like tmpfiles
does, we just depend on CONFIG_FHANDLE.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] names: take the registry write lock in kdbus_name_release()
On Fri, Apr 18, 2014 at 9:55 PM, David Herrmann dh.herrm...@gmail.com wrote: On Fri, Apr 18, 2014 at 3:16 AM, Djalal Harouni tix...@opendz.org wrote: Take the write lock in kdbus_name_release() instead of kdbus_cmd_name_release() in order to reduce the lock hold time. This change permits to convert the kdbus_bus_find_conn_by_id() call to kdbus_conn_find_peer() since the bus lock will also be taken later in kdbus_name_release(). Another advantage is that now kdbus_cmd_name_release() and kdbus_name_release() have the same semantic of kdbus_cmd_name_acquire() and kdbus_name_acquire() Signed-off-by: Djalal Harouni tix...@opendz.org Looks good to me. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Thu, Apr 24, 2014 at 7:35 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 24.04.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Have you checked that EOPNOTSUPP is really the error that is returned by name_to_handle_at() if the kernel has the entire syscall disabled? Note that there are two different cases to distuingish here: a file system not supporting the operation, and the kernel not supporting the syscal... It's warning on everything except EOPNOTSUPP. My reasoning is: EOPNOTSUPP - syscall supported, but wrong fs type, - return false ENOSYS - syscall not supported - warn and return false any other error - memory error or other major screw-up - warn and return false Looks good to me then, Kay? Sure, looks all fine. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd-work: ressize 1024 too short
On Tue, Mar 25, 2014 at 1:36 PM, Robert Milasan rmila...@suse.com wrote:
Hello, seems that under some conditions in udev_rules_apply_to_event
(@TK_M_PROGRAM) the fact that result is 1024 bytes creates problems if
the output of the running command/app is bigger then 1024 bytes.
+++ b/src/udev/udev-rules.c
@@ -2027,7 +2027,7 @@ int udev_rules_apply_to_event(struct udev_rules
*rules, struct udev_event *event case TK_M_PROGRAM: {
char program[UTIL_PATH_SIZE];
char **envp;
-char result[UTIL_PATH_SIZE];
+char result[UTIL_LINE_SIZE];
Applied.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Set default polling interval on removable devices as well
On Sat, Apr 26, 2014 at 4:46 PM, Martin Pitt martin.p...@ubuntu.com wrote: udev's 60-persistent-storage.rules enables in-kernel polling if block is built as a module. But that doesn't work if it is built into the kernel, as done by Debian and Ubuntu (for efficiency, as pretty much everyone will need it). This causes CD drive eject buttons to not work (see the linked bugs). SUBSYSTEM==module is not so much about *loadable* modules, but about module *parameters*, which also apply to built-in modules. block is never a module. The uevents for all directories in /sys/modules/ are still coldplugged during bootup, and should apply the settings, it is done by: udevadm trigger --type=subsystems Is the value not applied at all, can you check the file? Is it only missing for some devices which might be created before the setting is applied? Are the module parameter rules included in the initramfs? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kvm modules don't load any more with kernel = 3.11
On Mon, Apr 28, 2014 at 12:09 PM, Martin Pitt martin.p...@ubuntu.com wrote: Hello all, a while ago we got a report (https://launchpad.net/bugs/1207705) that with kernel = 3.11 the kvm modules (in particular, kvm_intel) don't get autoloaded any more. Andy (CC'ed) fixed that back then with the attached patch to 80-drivers.rules. Yesterday on the Debian systemd sprint this was confirmed by someone else who runs pure systemd on Debian with the Debian kernel, so it doesn't seem to be an unique quirk of either the Ubuntu kernel or the previous Ubuntu systemd modifications. I just confirmed that on linux 3.13, kmod 16, and systemd 204 (I know, old, but the corresponding udev rules didn't change since then). Is that something which ought to be in 80-drivers.rules, or is that a kernel regression? Andy's description suggests the former, and he can hopefully chime in. http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf7f800f2b3e93ccd1229d4717166f3a4d3af72f ? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for TuxOnIce hibernation
On Tue, Apr 29, 2014 at 1:16 PM, Julien Muchembled j...@jmuchemb.eu wrote:
Homepage: http://tuxonice.net/
---
src/shared/sleep-config.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/shared/sleep-config.c b/src/shared/sleep-config.c
index cf1cd40..d1f7fb1 100644
--- a/src/shared/sleep-config.c
+++ b/src/shared/sleep-config.c
@@ -224,6 +224,12 @@ static bool enough_memory_for_hibernation(void) {
size_t size = 0, used = 0;
int r;
+/* TuxOnIce is an alternate implementation for hibernation.
+ * It can be configured to compress the image to a file or an
inactive
+ * swap partition, so there's nothing more we can do here. */
+if (access(/sys/power/tuxonice, F_OK) == 0)
Is this available in the upstream kernel, or planned to to be merged?
Systemd does not support any unmerged kernel features, unless there a
very strong strategic reason to do that.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for TuxOnIce hibernation
On Tue, Apr 29, 2014 at 2:36 PM, Julien Muchembled j...@jmuchemb.eu wrote: Le 04/29/14 13:39, Kay Sievers a écrit : Is this available in the upstream kernel, or planned to to be merged? It's not available in vanilla. I don't know if it's planned to be merged. Systemd does not support any unmerged kernel features, unless there a very strong strategic reason to do that. I use Debian, which has just packaged version 208, and hibernate key stopped working after upgrading from 204. Rebuilding systemd with this patch is the only option. I am the maintainer a TOI user interface for Debian[1] and I recently added systemd support to it[2] This patch could be a Debian patch to systemd package but it would help all dists that support TOI if it was merged upstream. I use TOI since 2006 and given its quality, I hope you will accept such a small and simple patch. No, it is not about the size of a patch; systemd just does not support non-mainline kernel features. If Debian supports it, please add this patch to Debian. If it is some day merged into the upstream kernel, we would add support in systemd upstream too, not the other way around. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Fri, May 9, 2014 at 11:31 PM, Sage Weil s...@inktank.com wrote: The Ceph OSD initialization relies on identifying GPT partitions by type in order to mount data volumes and start daemons. Currently we ship this rule separately, but it is awkward to duplicate the conditional logic that precedes this block and it would be much simpler if it were simply included in the upstream rules. Types are by definition not unique. The symlinks in /dev/disk/by-*/ are *expected* to be unique. We handle duplicated labels, but they are specified by humans, multiple partitions with the same GPT types are just normal expected behavior; and they would have no order or priority, they just overwrite each other depending on probing order. We should not add such things, the logic to find these volumes at bootup are better handled by a specific program like systemd's systemd-gpt-auto-generator, without putting unreliable and unpredictable content into /dev. http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Sat, May 10, 2014 at 12:00 AM, Sage Weil s...@inktank.com wrote:
On Fri, 9 May 2014, Kay Sievers wrote:
On Fri, May 9, 2014 at 11:31 PM, Sage Weil s...@inktank.com wrote:
The Ceph OSD initialization relies on identifying GPT partitions by type
in order to mount data volumes and start daemons. Currently we ship this
rule separately, but it is awkward to duplicate the conditional logic that
precedes this block and it would be much simpler if it were simply included
in the upstream rules.
Types are by definition not unique. The symlinks in /dev/disk/by-*/
are *expected* to be unique.
We handle duplicated labels, but they are specified by humans,
multiple partitions with the same GPT types are just normal expected
behavior; and they would have no order or priority, they just
overwrite each other depending on probing order.
This is why the label has both the type (fixed, to identify this as a ceph
partition) and the label (random):
/dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID}
We should not add such things, the logic to find these volumes at
bootup are better handled by a specific program like systemd's
systemd-gpt-auto-generator, without putting unreliable and
unpredictable content into /dev.
I think this is what we're trying to accomplish with the ceph-disk tool,
which relies on these (reliable and predictable) symlinks. The labels
alone (by-partuuid) aren't sufficient since we want to be able to scan for
partitions of a given type without re-running blkid on every volume.
/dev is an API which should by default not contain custom links which
are not generally useful, and these links are not useful for other
tools.
These links are not even recognizable by type without doing readdir()
over it and string match operations to find the types, we really
should not add such stuff to the default rules set. We have to be
careful here, it seems like the wrong approach to put that in the
public visible /dev API.
Tools can get all this information programatically out of the udev
database, there is no create symlinks or to run blkid.
Ultimately, there is nothing wrong with tools shipping their own
rules, but please do not use generic names like
/dev/disk/by-parttypeuuid/. The name does even sound misleading
because it combines two different things in one name, with a '.' as a
separator.
Why don't you just use a leading directory for the type instead of
stuffing that into one name?
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] connection: fix kernel oop when conn_name not set
On Mon, May 12, 2014 at 3:24 PM, Jacek Janczyk j.janc...@samsung.com wrote: kernel oops when connection name (kdbus_conn.name) not set via HELLO message but requested with attach flags KDBUS_ATTACH_CONN_NAME. Hmm, here does it crash? Seems the code that attaches the string checks for the string being set: if ((mask KDBUS_ATTACH_CONN_NAME) conn conn-name) As conn.name is defined as for debug purposes I find it more convenient to return generic name than to strip the field from requested metadata or raise an error on request. I prefer if we just return nothing when we miss non-essential data. The kernel and its magic strings, which which can also just be supplied by users like the (deleted) for file names, are generally not a good idea. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Sat, May 10, 2014 at 12:34 AM, Sage Weil s...@inktank.com wrote:
On Sat, 10 May 2014, Kay Sievers wrote:
On Sat, May 10, 2014 at 12:00 AM, Sage Weil s...@inktank.com wrote:
On Fri, 9 May 2014, Kay Sievers wrote:
On Fri, May 9, 2014 at 11:31 PM, Sage Weil s...@inktank.com wrote:
The Ceph OSD initialization relies on identifying GPT partitions by type
in order to mount data volumes and start daemons. Currently we ship
this
rule separately, but it is awkward to duplicate the conditional logic
that
precedes this block and it would be much simpler if it were simply
included
in the upstream rules.
Types are by definition not unique. The symlinks in /dev/disk/by-*/
are *expected* to be unique.
We handle duplicated labels, but they are specified by humans,
multiple partitions with the same GPT types are just normal expected
behavior; and they would have no order or priority, they just
overwrite each other depending on probing order.
This is why the label has both the type (fixed, to identify this as a ceph
partition) and the label (random):
/dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID}
We should not add such things, the logic to find these volumes at
bootup are better handled by a specific program like systemd's
systemd-gpt-auto-generator, without putting unreliable and
unpredictable content into /dev.
I think this is what we're trying to accomplish with the ceph-disk tool,
which relies on these (reliable and predictable) symlinks. The labels
alone (by-partuuid) aren't sufficient since we want to be able to scan for
partitions of a given type without re-running blkid on every volume.
/dev is an API which should by default not contain custom links which
are not generally useful, and these links are not useful for other
tools.
FWIW I was surprised that there wasn't already a way to find partitions by
type in /dev, but I assume you know better than I how other tools are
using udev. It seems at least as useful as by-partuuid to me.
These links are not even recognizable by type without doing readdir()
over it and string match operations to find the types, we really
should not add such stuff to the default rules set. We have to be
careful here, it seems like the wrong approach to put that in the
public visible /dev API.
Tools can get all this information programatically out of the udev
database, there is no create symlinks or to run blkid.
I just looked up libudev and it looks like there is even a pyudev wrapper,
so that could indeed work better. I take it that queries via
udev_enumerate for (say) ID_PART_ENTRY_TYPE=x are efficient?
Sure, filter for block devices and this or other GPT properties. The
libudev API will just find the devices is /sys and read the database
files in tmpfs /run and, it will not talk to any devices, so it should
perform pretty well.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, May 15, 2014 at 2:30 AM, Andy Kittner andy.kitt...@gmail.com wrote: On 14/05/14 18:33, Lennart Poettering wrote: On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created Thats the first one I find a bit fishy, but it doesn't sound fatal either... This really looks as if you built the DM userspace stuff without udev support. File a bug against you distro. That should not be the case, the udev useflag is enabled across the board and I just double-checked cryptsetup, libdevmapper and dmsetup with ldd; all are linked against libudev. Is there anything else I could/should check? Are you running an initrd without udev, and/or tools that mess around with mknod in /dev? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid
On Thu, May 15, 2014 at 10:57 PM, Goffredo Baroncelli kreij...@libero.it wrote: On 05/15/2014 08:16 PM, Lennart Poettering wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: [...] So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? In what this should be different than the normal RAID system ? In both case there are two timeout: the first one is for waiting the full system, the second one is for the minimal set of disks to a degraded mode. If even the second timeout is passed, then we should consider the filesystem not build-able. How it is handle for the RAID system ? Knowing that we should consider to apply the same strategies fro btrfs (may be we need some userspace tool to do that) RAID is not handled by systemd, it is handled by other tools or not at all. Initrds have some logic here, but nothing convincing, and it is just the same mess as this. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid
On Thu, May 15, 2014 at 10:57 PM, Chris Murphy li...@colorremedies.com wrote: On May 15, 2014, at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: Two device Btrfs volume, with one device missing (simulated) will not boot, even with rootflags=degraded set which is currently required to enable Btrfs degraded mounts. Upon reaching a dracut shell after basic.target fails with time out, I can mount -o subvol=root,degraded and exit and continue boot normally with just the single device. The problem seems to be that systemd (udev?) is not finding the volume by uuid for some reason, and therefore not attempting to mount it. But I don't know why it can't find it, or even how the find by uuid mechanism works this early in boot. So I'm not sure if this is a systemd or udev bug, or a dracut, or kernel bug. The problem happens with systemd 208-9.fc20 with kernel 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel 3.15.0-0.rc5.git0.1.fc21. As soon as btrfs reports that a file system is ready, systemd will pick it up. This is handled with the btrfs udev built-in, and invoked via /usr/lib/udev/rules.d/64-btrfs.rules. rootflags has no influence on that, as at that point it is not clear whether the block device will be the once that carries the root file system, or any other file system. Not sure what we should be doing about this. Maybe introduce a new btrfs=degraded switch that acts globally, and influences the udev built-in? Kay? So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? I mean, just having a catchall switch to boot in degraded mode is really dangerous if people have more than one array and we might end up mounting an fs in degraded mode that actually is fully available if we just waited 50ms longer... I mean this is even the problem with just one array: if you have redundancy of 3 disks, when do you start mounting the thing when degraded mode is requested on the kernel command line? as soon as degrdaded mounting is possible (thus fucking up possible all 3 disks that happened to show up last), or later? I have no idea how this all should work really, it's a giant mess. There probably needs to be some btrfs userspace daemon thing that watches btrfs arrays and does some magic if they timeout. But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do… Is it that the existing udev rule either doesn't know, or doesn't have a way of knowing, that rootflags=degraded should enable only the root=UUID device to bypass the ready rule? Does udev expect a different readiness state to attempt a mount, than a manual mount from dracut shell? I'm confused why the Btrfs volume is not ready for systemd which then doesn't even attempt to mount it; and yet at a dracut shell it is ready when I do the mount manually. That seems like two readiness states. The btrfs kernel state has only one state, and that is what udev reacts to. I'd say it's not udev's responsibility, but rather Btrfs kernel code, to make sure things don't get worse with the file system, regardless of what devices it's presented with. At the time it tries to do the mount, it has its own logic for normal and degraded mounts whether the minimum number of devices are present or not and if not it fails. The degraded mount is also per volume, not global. For example if I remove a device, and boot degraded and work for a few hours making lots of changes (even doing a system update, which is probably insane to do), I can later reboot with the stale device attached and Btrfs figures it out, passively. That means it figures out if there's a newer copy when a file is read, and forwards the newest copy to user space, and fixes the stale copy on the previously missing device. A manual balance ensures all new files also have redundancy. I think it's intended eventually to have a smarter balance catch up filter that can also run automatically in such a case. In any case the file system isn't trashed. The problem is when to actively force to degrade things when devices do not show up in time. That is nothing the kernel can know, it would need to be userspace making that decision. But udev does not really have that information at that level, it would need to try until the kernel is satisfied mounting a volume degraded. This all is probably not a job for udev or systemd, but for a specialized storage daemon which has explicit configuration/policy in which way to mess around with the user's data. This is not an area where we should try to be smart; falling back
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, May 15, 2014 at 11:15 PM, Andy Kittner andy.kitt...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 18:27, Lennart Poettering wrote: Well, something appears to create your device nodes, and it shouldn't do that... On a udev system userspace never creates any device nodes, that's done on its own by the kernel via devtmpfs, udev then just creates symlinks on top, or changes access rights. It appears that your LVM/DM installation for some reason created device nodes anyway, and you need to figure out why it did that, and turn this off. It might be in your initrd... Hah, progress: I think I pinpointed the culprit. libdm checks whether udev is running and falls back to non-udev code otherwise. When the boot fails, this is what I get: | May 15 22:06:46 pinky systemd-udevd[1361]: starting version 212 | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:06:46 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:06:46 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:06:46 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:06:46 pinky systemd-cryptsetup[2436]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/57d30bae-878a-4931-bc39-10cc18b92486. | May 15 22:06:46 pinky systemd-cryptsetup[2434]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/ee5e92a6-18b6-4247-a1d8-8379b01928fb. | May 15 22:06:46 pinky systemd-cryptsetup[2433]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/b1c029d2-515b-47a1-becf-59c1f5191e43. | May 15 22:06:46 pinky systemd-cryptsetup[2435]: Set cipher twofish, mode xts-essiv:rmd256, key size 512 bits for device /dev/disk/by-uuid/72c01d1e-ac93-4263-93d7-fb293dfe49c0. | May 15 22:06:46 pinky systemd[1]: Started Create Static Device Nodes in /dev. | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Device Manager... | May 15 22:06:46 pinky systemd-udevd[2485]: starting version 212 | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: open_queue_file failed with errno 2 | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG libdm:_check_udev_is_running: Udev is not running. Not using udev synchronisation code. So the udev queue file does not yet exist, libdm thinks the system is not running udev and things go wrong... I also was lucky enough to get one of the rare good boots right after I put in my debug prints (I was fearing a Heisenbug here for a minute) So here it is for comparison: | May 15 22:02:10 pinky systemd-udevd[1362]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:02:10 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:02:10 pinky systemd[1]: Starting File System Check on Root Device... | May 15 22:02:10 pinky systemd-udevd[2464]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting Create Static Device Nodes in /dev... | May 15 22:02:10 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:02:10 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:02:10 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:02:10 pinky systemd[1]: Mounted Lock Directory. |
Re: [systemd-devel] [PATCH 1/1] build-sys: build gummiboot executable only if HAVE_BLKID
On Wed, May 14, 2014 at 11:10 AM, Kang Hu hukangu...@gmail.com wrote: src/setup/setup.c depends on blkid library. so build gummiboot binary only if blkid library is available. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-kdbus: fixed unterminated string
On Mon, May 12, 2014 at 3:35 PM, Jacek Janczyk j.janc...@samsung.com wrote: Unterminated string array is used to populate random bus name in check_prepare_env(). Added proper termination. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: --disable-networkd --enable-timesyncd should throw error
On Fri, May 16, 2014 at 1:20 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 15.05.14 19:02, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
El 15/05/14 18:34, Lennart Poettering escribió:
On Thu, 15.05.14 18:23, Cristian Rodríguez
(crrodrig...@opensuse.org) wrote:
timesyncd requires networkd running.
It doesn't really Should work either way...
I tried that a few hours ago..
r = manager_network_monitor_listen(m);
if (r 0) {
log_error(Failed to listen to networkd events: %s,
strerror(-r));
goto out;
}
then it exits with failure.
What's the precise error?
Seems to work fine on my laptop that still has NetworkManager...
But networkd runs on your machine and exports state.
We need to make timesyncd gracefully accepting that no networkd
around, or we should just make it depend on it.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Fri, May 16, 2014 at 12:30 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 07.05.14 08:54, Emil Sjölin (emil.sjo...@axis.com) wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut
-d '.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 |
cut -d '.' -f 2`
Isn't head -n 1 more correct?
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8
-a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed
s:ln:$srcdir\/tools\/lnr.sh:)
Shouldn't this be sed -e?
+fi
+fi
Hmm, if we ship this anyway, why not always use it? Otherwise it would
too easily bitrot...
THis would also allow removing much of the shell pipeline in the
configure script for this. I mean, these commands have changed all the
time in the past, for example sed quite a bit...
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
No shebang?
+# This script makes the 'ln --relative' command work as expected on a
system where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see
man page
+# for the 'ln' command for the different forms).
+#
+
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string =
$relop_2 ]; then
Why not -o instead of ] || [?
I'd really prefer if somebody who's a true shell guru could look over
this. Harald? (Or Zbigniew?)
I do not think we should do such hacks in upstream systemd.
It is a commonly available feature since quite some years, and
building without chroot on old systems is a bit too exotic to justify
carrying this rather large work around upstream.
We do not accept distro-specific, not commonly needed things in the
upstream code base because we do not want to maintain them, the same
seems to apply to this.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] gudev: avoid using export-symbols-regex
On Wed, Apr 23, 2014 at 11:43 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: There is no need for this hackery, just hide the internal functions using glib 's G_GNUC_INTERNAL macro. Hmm, why is that a hack? Explicitly exporting functions with a well-defined prefix sounds more robust than exporting everything that isn't explicitly hidden, or do I miss something? Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bulid: linking order is irrelevant
On Thu, May 22, 2014 at 9:53 AM, Jan Engelhardt jeng...@inai.de wrote: Linking order is not a problem with .la files, as .la files track their dependencies -- just like .so files. It is a generally a problem that the build system tools do not solve. We rely on gc-sections, platforms without support for it fail to build without the explicily specified right order. Without this fix we fail to build on ARM: http://cgit.freedesktop.org/systemd/systemd/commit/?id=2fa495c8a4ea25cb96daebb8aa0d146b74353016 If libsystemd-network.la is relying on that udev function, it ought to specify libudev(-internal).la in libsystemd_network_la_LIBADD. Yeah, I moved that around. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On Thu, May 29, 2014 at 4:42 PM, Camilo Aguilar camilo.agui...@gmail.com wrote: gah, the link for 2 is https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8 instead 2. The network interface says that it needs broadcast Do you see that layer2 file in /sys on the machine that does not work? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
On Sat, May 31, 2014 at 7:45 PM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 31/05/14 13:00, Samuli Suominen escribió: A proper git formatted patch for inclusion. IN my opinion, we should just make KMOD a mandatory dependency, drop all ifdefs, error out if not found. Sound fine to me, it really is a core functionality with very little overhead. The same rule as for other things: if people want to optimize-out basic functionality we should not make it harder than needed, but we should also not go crazy trying to support that with upstream options. That means: git-is-your-friend for weird porting or supporting exotic features. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udevd: add --event-timeout commandline option
On Mon, Jun 2, 2014 at 4:47 PM, Hannes Reinecke h...@suse.de wrote: On large configurations some events take longer than the default 30 seconds. Killing those events will leave the machine halfway configured. So add a commandline option '--event-timeout' to handle these cases. Why are they taking do long? Is device mapper involved? :) Are you sure that the concurrency doesn't need to be limited instead? And there is already an OPTIONS+=event_timeout= which is done from rules, which might better fit than a global switch to add to the daemon config? Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Split keymap conversion functions to separate library
On Tue, Jun 3, 2014 at 10:58 AM, Michal Sekletar msekl...@redhat.com wrote: Currently systemd-localed does conversions from X11 keymap to VConsole keymap and vice-versa. There was a request coming from Anaconda installer team at Red Hat which was about splitting this functionality to separate library. I am curious if other people would be interested in such library and if systemd upstream is good place for it. No, we are not really interested in extending the support of the legacy kernel console keymaps or fonts handling. The facility is too broken, buggy, limited and unreliable to be supported. It is a nice debugging tool, but not the technology we need today. All this will move to userspace and the insufficient kernel consoles will just go away. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] domain: fix a BUG_ON() when kdbus_domain_new() fails
On Mon, Jun 2, 2014 at 5:57 PM, Djalal Harouni tix...@opendz.org wrote: Currently just running: test/test-kdbus will trigger the BUG_ON() appended at the bottom. This is due to the test in check_domain_make() where we try to register the same domain twice line: 297, hence kdbus_domain_new() fails with -EEXIST at line domain.c:289 Later on error path we clear the non-finalized domain: kdbus_domain_unref() = __kdbus_domain_free() = BUG_ON(!domain-disconnected) Oh, hmm, I should probably run our own tests from time to time, not just the full system as a test. :) After a closer look, it seems we will hit this BUG_ON() on every time kdbus_domain_new() fails. domain was not finalized so kdbus_domain_disconnect() is never called, and domain-disconnect can't be true. To fix this, I just set 'domain-disconnect = true' at the beginning which is perfectly true since that domain is not finalized hence not connected, and before we return success set it again to 'false' in other words: connected. I just took this path since it seems logic, and having a single exit node kdbus_domain_unref() on success/errors wich passes all these BUG_ON() makes the code robust. In other places: bus, endpoints we do not follow this and we duplicate the unref() logic, for endpoints it would be easy to convert! I'll probably follow with patches for that. It was that way earlier, it will probably not work out for the others. We needed to open-code it because the objects were not fully initialized and the rollback was not possible without doing weird things. I actually think adding the needed 3 free() calls here, like for the other objects, is shorter, needs no explanation and is easier to follow. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] connection: pin the subjective cred for KDBUS_POLICY_OWN
On Sat, May 31, 2014 at 10:23 PM, Djalal Harouni tix...@opendz.org wrote: Make sure that the credentials of the connection at creation time will last so the kdbus_policy_check_own_access() will work as expected. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] domain: rework kdbus_domain_new() error path to fix a BUG_ON()
On Tue, Jun 3, 2014 at 5:31 PM, Djalal Harouni tix...@opendz.org wrote: Currently just running: test/test-kdbus will trigger the BUG_ON() appended at the bottom. This is due to the test in check_domain_make() where we try to register the same domain twice line: 297, hence kdbus_domain_new() fails with -EEXIST at line domain.c:289 Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] commit 235c6e628199221b7885f159367614b7105547cf is incorrect
On Thu, Jun 5, 2014 at 12:06 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: Commit 235c6e628199221b7885f159367614b7105547cf build-sys: accommodate gcc-4.9.0 link-time optimization (LTO) changes systemd fails to build (symbols not found/resolved during cgls link step) under gcc-4.9.0 due to link-time optimization (lto) changes, in particular from gcc-4.9.0/NEWS: This is wrong, the bug is not in systemd, gcc or anything else, it is a bug in libtool, I successfully compile with gcc 4.9 every day and will work for as long you export NM=gcc-nm ... export RANLIB=gcc-ranlib.. Yeah, it's not our fault, but asking gcc to keep (like older ones did) putting-in the data that the ordinary tools need, and not explicitly requiring the ones using the linker plugins sounded fine to me; only for as long as the real problem is fixed and we can remove this again. If you think this causes actual problems, please explain. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
On Mon, Jun 9, 2014 at 4:31 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
09.06.2014 20:11, Kay Sievers wrote:
On Mon, Jun 9, 2014 at 4:02 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
09.06.2014 19:26, Kai Krakow wrote:
Alexander E. Patrakov patra...@gmail.com schrieb:
I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
the same regression here: zram swap space does not get activated. It
looks like systemd tries to activate swap before the RUN+=mkswap part
of
the udev rule finishes.
Here are the relevant lines from my configuration files. Are they
indeed
supposed to work, or were working only by pure luck?
I switched to zswap because of this. This also looks more appropriate
for
my
workload. Maybe that's an option? At least if you do have a physical
swap
device (and in that cased I'd prefer zswap over zram).
Please don't persuade me to hide or tolerate bugs. Even if zswap is more
appropriate, I would like to get a comment on my zram issue from systemd
maintainers.
I don't know of anybody working on systemd, using this
horrible-to-configure facility.
I have no idea how stuff should work, but it *might* need some
ENV{SYSTEMD_READY}=0 fiddling.
Let's decompose the question then. Maybe you know how at least one of the
steps should work.
1. Is it correct that swap units created from /etc/fstab have dependencies
on the devices mentioned in the first column? What kind of dependencies?
2. At what point in time (just after getting the uevent, after setting sysfs
attributes, after running the RUN programs) is the dependency on the device
node considered satisfied?
Just guessing around after looking at the rules you pasted, the devices
seem to be created unconditionally, and only later, after manual
configuration of the same devices be useful to the system. There is no
way for systemd to find that out, so systemd's dependencies on
configuration + devices + original uevents will unlikely work as
expected.
Module parameters to configure devices, sysfs attributes to
re-configure pre-created dead devices, ...; given the fact, that it
is relatively recent technology, such terribly outdated and
have-always-been-broken concepts should never have been merged into
the kernel.
A valid observation, but still - the semantics need to be documented (even
if the document says undefined) in systemd.device(5) or elsewhere WRT
dependencies and ordering.
It looks like the same model as device-mapper, MD, loop; systemd has
no native idea about them and when to bring up devices. Original
device events are suppressed with SYSTEMD_READY=0, and new events
later re-triggered when the devices are usable for systemd to pick
them up.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] udev: really exclude device-mapper from block device ownership event locking
On Tue, Jun 10, 2014 at 3:51 PM, Christian Hesse m...@eworm.de wrote: Arguments were wrong order, no? Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: check the return value from udev_enumerate_scan_devices
On Wed, Jun 4, 2014 at 11:40 PM, Thomas H.P. Andersen pho...@gmail.com wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com The return value from udev_enumerate_scan_devices was stored but never used. I assume this was meant to be checked. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] log: honour the kernel's quiet cmdline argument
On Tue, Jun 3, 2014 at 7:44 PM, Ronny Chevalier chevalier.ro...@gmail.com wrote: It was forgotten in b1e90ec515408aec2702522f6f68c4920b56375b See https://bugs.freedesktop.org/show_bug.cgi?id=79582 Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
On Wed, Jun 11, 2014 at 8:49 PM, Alexander E. Patrakov patra...@gmail.com wrote: 11.06.2014 23:00, Lennart Poettering wrote: CHANGES WITH 214: * As an experimental feature, udev now tries to lock the disk device node (flock(LOCK_SH|LOCK_NB)) while it executes events for the disk or any of its partitions. Applications like partitioning programs can lock the disk device node (flock(LOCK_EX)) and claim temporary device ownership that way; udev will entirely skip all event handling for this disk and its partitions. If the disk was opened for writing, the close will trigger a partition table rescan in udev's watch facility, and if needed synthesize change events for the disk and all its partitions. This is now unconditionally enabled, if it turns out to cause major problems, we might turn it on only for specific devices, or might need to disable it entirely. Device-mapper devices are excluded from this logic. If we have one exception, I think it is safe to ask another: all block devices starting with zram. The reason is documented at http://lists.freedesktop.org/archives/systemd-devel/2014-June/019838.html : it breaks a (mis-?)documented way to integrate zram swap and systemd. Not so fast, the issue needs to be investigated and explained first. It is known why device-mapper cannot work with devices which are open()ed. By looking at the kernel code, I cannot immediately see why zram's static devices would have an issue with udev opening the device. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] connection: fix cpu stall by checking kdbus item alignment
On Wed, Jun 11, 2014 at 6:27 PM, Djalal Harouni tix...@opendz.org wrote: Fix the following stall triggered by a policy holder hello: call test/kdbus-util.c:kdbus_hello_registrar() and pass KDBUS_HELLO_POLICY_HOLDER as a flag. While we are it make sure that kdbus_cmd_conn_update() also checks for proper 8 byte alignment. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] kdbus-test: fix kdbus item alignment in kdbus_hello_registrar()
On Wed, Jun 11, 2014 at 6:27 PM, Djalal Harouni tix...@opendz.org wrote: Currently running the test-kdbus-activator test will fail with -EINVAL To fix this, remove the redundant offsetof() macros since it is already handled. The KDBUS_ITEM_SIZE() will expand into KDBUS_ITEM_HEADER_SIZE() which expands into an offsetof() one. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util.h: KDBUS_ITEM_VALID fixed
On Tue, Jun 17, 2014 at 12:38 PM, Jacek Janczyk j.janc...@samsung.com wrote: Missing character leading to wrong variable name restored. Signed-off-by: Jacek Janczyk j.janc...@samsung.com --- util.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd: skip cd/dvd devices in synthesize_change
On Wed, Jun 18, 2014 at 8:17 PM, Robert Milasan rmila...@suse.com wrote: If we are running udevd from a LiveCD or ISO image, it can happen that udevd wont find the cd/dvd in time, causing a failure. I've attached the patch which seems to fix the issue. Change events are triggered when some tool has opened the device for writing and closes the file descriptor. That sounds pretty strange with a Live CD on /dev/sr0. All we do in the code you patch here is to look for possible partitions. Are you sure that this is really the problem? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd stops
On Mon, Jun 23, 2014 at 12:28 PM, Jay D Bhatt jay.bh...@igate.com wrote: My systemd stops indefinitely at this point: [ OK ] Reached target Login Prompts. As Lennart suggested, I looked at my kernel version which is 3.0.35, which is = 3.0, so should not give problem for systemd initialization. Then I tried bit of debugging and taking logs. I put systemd.log_level=debug systemd.log_target=console in my kernel parameters and took the log. The log is attached,it is detailed one but I am not able to find the point why it stops there. I also put systemd.unit=rescue.target in kernel parameters and removed initially put systemd.log_level and systemd.log_target parameters. It asked me to enter the password, on entering password I got prompt. Then I tried to run systemd and check it out. Below what output when I ran systemd in rescue mode. My default service is Weston.service. bash-4.2# systemd Failed to make us a subreaper: Invalid argument Perhaps the kernel version is too old ( 3.4?) This is the systemd --user mode, the PR_SET_CHILD_SUBREAPER should not be needed in the PID1 mode. But none of us ever tries such old kernels, it might still fail with other features later. weston.service: main process exited, code=exited, status=1/FAILURE Unit weston.service entered failed state. I am not able to find reason for not completing systemd operation. Could anybody let me know the might-be problems? Just the usual suspects: check if CONFIG_FHANDLE, CONFIG_DEVTMPFS, CONFIG_TMPFS are set in your kernel config. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev: unable to flock(/dev/sda), skipping event
On Tue, Jun 24, 2014 at 11:58 AM, Robert Milasan rmila...@suse.com wrote: On Tue, 24 Jun 2014 11:38:17 +0200 Robert Milasan rmila...@suse.com wrote: Hi, we are getting this error on one of our machines. The machine is a xen host running systemd/udev 210. First, systemd 210 has no locking logic at all. Please specify what exactly you patched into 210. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev: unable to flock(/dev/sda), skipping event
On Tue, Jun 24, 2014 at 12:41 PM, Robert Milasan rmila...@suse.com wrote: On Tue, 24 Jun 2014 12:22:35 +0200 Kay Sievers k...@vrfy.org wrote: On Tue, Jun 24, 2014 at 11:58 AM, Robert Milasan rmila...@suse.com wrote: On Tue, 24 Jun 2014 11:38:17 +0200 Robert Milasan rmila...@suse.com wrote: Hi, we are getting this error on one of our machines. The machine is a xen host running systemd/udev 210. First, systemd 210 has no locking logic at all. Please specify what exactly you patched into 210. Commit: 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d This is only one and incomplete patch of a series of patches in that area. Please do not backport random cherry-picked patches to old systemd versions and report errors about them, but try with the latest version of systemd which contains all the known fixes. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev: unable to flock(/dev/sda), skipping event
On Tue, Jun 24, 2014 at 12:46 PM, Kay Sievers k...@vrfy.org wrote: On Tue, Jun 24, 2014 at 12:41 PM, Robert Milasan rmila...@suse.com wrote: On Tue, 24 Jun 2014 12:22:35 +0200 Kay Sievers k...@vrfy.org wrote: On Tue, Jun 24, 2014 at 11:58 AM, Robert Milasan rmila...@suse.com wrote: On Tue, 24 Jun 2014 11:38:17 +0200 Robert Milasan rmila...@suse.com wrote: Hi, we are getting this error on one of our machines. The machine is a xen host running systemd/udev 210. First, systemd 210 has no locking logic at all. Please specify what exactly you patched into 210. Commit: 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d This is only one and incomplete patch of a series of patches in that area. Please do not backport random cherry-picked patches to old systemd versions and report errors about them, but try with the latest version of systemd which contains all the known fixes. You have this? http://cgit.freedesktop.org/systemd/systemd/commit/?id=c343be283b7152554bac0c02493a4e1759c163f7 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 5/8] HACK1: optimize copy operations in kdbus_conn_queue_alloc()
On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro takahiro.aka...@linaro.org wrote: This function copies the reply message directly into receiver's buffer (pool slice). Looking into the implementation closely, however, there are multiple occurrences of copy operations, kdbus_pool_slice_copy(), which then executes costly prolog/epilog functions, say set_fs() and write_begin/write_end(), on each entry/exit. This patch uses a temporary buffer on the stack to compose a message and replace a costly function, kdbus_pool_slice_copy(), to memcpy() wherever possible, although I have to further confirm that this change is actually safe. +#if KDBUS_HACK1 + tmp = kmalloc(vec_data, GFP_KERNEL); You meant a malloced temporary buffer, not one allocated on the stack, right? We need to handle larger vectors than kmalloc can handle, that's why we copy directly to the receiver, and to avoid 2 copies. Did you find out what exactly in the call chain of our open-coded write shows up as expensive here? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 6/8] HACK2: blocking ioctl(CMD_MSG_RECV)
On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro takahiro.aka...@linaro.org wrote: In the current implementation, ioctl(CMD_MSG_RECV) returns immediately if no message has been queued, and so a service process has to wait by explicitly calling poll() system call. If such a process needs to wait only on a single connection, we can eliminate poll() system call by adding a synchronous attribute in receiving a message. Why is this useful in general? The peer can call RECV in a loop until EAGAIN without ever needing to call poll() as long as data is available. When there is no more message to handle, poll() is used to suspend the process, and only when it is idle anyway. Busy processes, the use-case we would optimize for, should not see a real benefit here? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] connection: use the already cached metadata if KDBUS_HELLO_CACHE_META is set
On Fri, Jun 27, 2014 at 12:32 PM, Djalal Harouni tix...@opendz.org wrote: For connections with the KDBUS_HELLO_CACHE_META flag dup the metadata/credentials from handle or from the HELLO cmd, and use it to construct kdbus kmsg object, this improves benchmark by ~50% The KDBUS_HELLO_CACHE_META flag is only for privileged bus users, others will fail with -EPERM. Privileged bus users can do what ever they want. Metadata contains timestamps, global message sequence numbers, PIDs, none of that should be cached or faked, I think. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: don't enable usb pm for Avocent devices
On Wed, Jun 25, 2014 at 1:57 PM, Tom Hirst tom.hi...@ipe-systems.co.uk wrote: The Avocent KVM over IP devices doesn't work correctly with USB power management enabled. --- rules/42-usb-hid-pm.rules | 4 1 file changed, 4 deletions(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 8:38 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: +varlistentry +termfilename/usr/lib/filename/term +listitemparaSystem libraries and +package-specific +data./para/listitem +/varlistentry + +varlistentry +termfilename/usr/lib64/filename/term +listitemparaSecondary library +directory for placing 64bit versions +of system libraries in, if the primary +architecture of the system is +32bit. This directory should not be +used for package-specific data, unless +this data requires 64bit-specific +versions, too./para/listitem +/varlistentry So far systemd was agnostic to the details of this split. This makes this official, and conflicts with the Debian/Ubuntu camp. The multiarch layout is more flexible, so this seems backwards. It sounds like, yes. We should not specify the content of the lib64 directory. All we would need to run an ABI compliant x86_64 system is /lib64 - usr/lib/x86_64-linux-gnu/. What a mess, Fedora should just sort out its backwards and outdated lib64/ and libexec/ rules and everybody would benefit. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
