Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'
On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote: On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote: On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote: Hmm, can you elaborate on this one? libsystemd-login should be mostly This error occurs while building dbus with systemd support like below $ make make all-recursive make[1]: Entering directory `/home/chengwei/Upstream/dbus.git' Making all in dbus make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' make all-am make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' CCLD dbus-test /usr/lib/libsystemd-login.so: undefined reference to `cg_create' collect2: ld returned 1 exit status make[3]: *** [dbus-test] Error 1 make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git' make: *** [all] Error 2 and cg_create referenced by libsystemd-login.so like below $ grep cg_create src/login/ -r Binary file src/login/systemd_logind-logind-session.o matches Binary file src/login/systemd_logind-logind-user.o matches But these files are not linked into libsystemd-login, but only into logind (the daemon)... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Tue, 10.09.13 13:33, Colin Walters (walt...@verbum.org) wrote: On Tue, 2013-09-10 at 18:47 +0200, Lennart Poettering wrote: I'd actually prefer having an explicit blacklist for this, so that we don't have to trust the initrd too much that... But nowadays it's systemd running in the initrd, what's not to trust? Well, might be a different version, might be one without systemd, ... However, I'd really like to see this blacklist be unified somewhere. Maybe a new function in util.c or so called is_os_resource_path() What would the blacklist contain? Just / and /usr? Or would it also have /var? /, /usr, /etc probably. /var is something where we allow that it is mounted at late boot and that it is unmounted at late shutdown (at least in theory). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/7] filesystem targets: disable default dependencies
On 09/10/2013 06:41 PM, Lennart Poettering wrote: On Fri, 23.08.13 15:09, Tom Gundersen (t...@jklm.no) wrote: This means we can use default dependencies on mount units without having to get them automatically ordered before the filesystem targets. Looks good. But before we merge this, Harald, can you comment? Any issue with this? No issues. Looks good! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateNetwork=true conflicts with Type=notify
On Wed, 11.09.13 13:49, Lennart Poettering (lenn...@poettering.net) wrote: On Tue, 10.09.13 19:04, Pierre Schmitz (pie...@archlinux.de) wrote: heya, when trying to disable network access to the PHP-FPM service I noticed that the service was no longer able to call back to systemd using Type=notify. Systemd then kills the service when reaching the timeout. It seems this could be a limitation by design in which case we might want to warn the user when attepmting such setup. Uh, ah. Interesting. So we could actually do something about this, but it would break things elsewhere... So, the notification socket could either be an abstract namespace AF_UNIX socket, or an AF_UNIX socket in the file system. If it is in the file system, then it becomes unavailable as soon as the daemon chroot()s. If it is in the abstract namespace it becomes unavailable as soon as CLONE_NEWNET/PrivateNetworking=yes is used. Due to the chroot() situation we changed a couple of times forth and back between fs/abstract in the past (most recently 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da). I am not sure what is the better choice here... We could of course have two sockets, one in the fs and one in the abstract namespace, and then pass the right one to the process depending on the setting of PrivateNetworking=... But that would not work as soon as the daemon then also decides to chroot()/RootDirectory= is used... Tricky problem... I am a bit out of ideas. Anyone? (for now I have documented this behaviour in the man pages.) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'
On Wed, Sep 11, 2013 at 1:27 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote: On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote: On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote: Hmm, can you elaborate on this one? libsystemd-login should be mostly This error occurs while building dbus with systemd support like below $ make make all-recursive make[1]: Entering directory `/home/chengwei/Upstream/dbus.git' Making all in dbus make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' make all-am make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' CCLD dbus-test /usr/lib/libsystemd-login.so: undefined reference to `cg_create' collect2: ld returned 1 exit status make[3]: *** [dbus-test] Error 1 make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git' make: *** [all] Error 2 and cg_create referenced by libsystemd-login.so like below $ grep cg_create src/login/ -r Binary file src/login/systemd_logind-logind-session.o matches Binary file src/login/systemd_logind-logind-user.o matches But these files are not linked into libsystemd-login, but only into logind (the daemon)... Does this print something when executed in the build tree? $ nm -D .libs/libsystemd-login.so | grep cg Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to implement a demon process by socket activation
Hi I have been aiming to make a demon process by socket activation in systemd. you know that, it was provided for socket activation in systemd homepage like below . http://0pointer.de/blog/projects/socket-activation.html I refered that guide for making a daemon process started using socket activation. I just followed the explanation in that site and tried to make a pair of server/client program on TCP/IP.( I just only added a sd_listen_fds() library fuction in server process using sd-daemon library) But it didn't work when I started server process. those processes include almost same code with following the guide. Is that all to make a daemon process by socket activation in homepage? Thanks, tonyseo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Optimize startswith() to macro
On Fri, 23.08.13 14:09, WANG Chao (chaow...@redhat.com) wrote: - Why not use startswith() instead of first_word()? first_word is not equivalent: there must be a word boundary after the word: Yeah, you're right. I occasionally got carried away at midnight :( And I think a inline static version could be a little faster? Right? Not necessarilly. On today's CPUs often smaller code results in faster execution than avoiding function calls... If we shift this around further we probably should do it properly and play around with benchmarks... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Some thoughts about loop_read/loop_write in util.c
On Wed, 11.09.13 21:50, cee1 (fykc...@gmail.com) wrote: Hi all, loop_read/loop_write: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n2179 In a scenario of pipes, loop_read on read side, if the write side is closed, loop_read will return 0 if do_poll is false(let's assume no data available to read). When do_poll is true, it will return: 1) 0, if write side is closed while loop_read is just doing a read 2) or -EIO when poll returns pollfd.revent with POLLHUP flag set The behavior is not very consistent. IMHO, it's preferred loop_read follows read behavior as much as possible -- returns 0 to indicate end of a file here, e.g. We can try to read 0 bytes when pollfd.revents != POLLIN. EOF and temporarily not being able to read more data is something very different. It might make sense to return EAGAIN if POLLHUP is set though. (But note that POLLHUP has more complex semantics when combined with shutdown() and half-open connections...) The same with loop_write. EOF doesn't exist for loop_write(), so this is even weirder Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to implement a demon process by socket activation
On Wed, 11.09.13 21:33, Tony Seo (tonys...@gmail.com) wrote: Hi I have been aiming to make a demon process by socket activation in systemd. you know that, it was provided for socket activation in systemd homepage like below . http://0pointer.de/blog/projects/socket-activation.html I refered that guide for making a daemon process started using socket activation. I just followed the explanation in that site and tried to make a pair of server/client program on TCP/IP.( I just only added a sd_listen_fds() library fuction in server process using sd-daemon library) But it didn't work when I started server process. those processes include almost same code with following the guide. Is that all to make a daemon process by socket activation in homepage? Yes, usually it is. Note however that some daemons close all open fds during initialization. You need to exclude the socket actviation fds from that. It might be useful to play around with the new systemd-activate tool in order to debug this. See man 8 systemd-activate. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Tue, 10.09.13 19:54, Tom Gundersen (t...@jklm.no) wrote: But it annoys me that we're propagating this hardcoding in the new code too. How about we make systemd inspect /proc/self/mountinfo *very* early on at boot when it starts, and ensure skip unmounting these, under the assumption they'll be taken care of either in the initrd, or by the final kill spree? I'd actually prefer having an explicit blacklist for this, so that we don't have to trust the initrd too much that... Not sure if I get in what sense you mean we need to trust the initrd. What I thought we'd do was to simply notice what filesystems were already mounted when systemd first started in the real root (so whatever caused them to be mounted in the initrd is not important). What gives me the headache there is that initrds are so varied right now. It just gives me headaches leaving it to the numerous initrds implementations to decide what the file systems with OS resources are. I'd much rather define clearly that /etc, / and /usr are OS resources in the systemd context, rather then leave that definition to the inirds/dsitro packagers... This is too close to the core of the OS to leave this undefined and varying between the distributions I'd say... If you meant we'd need to trust the initrd to umount them correctly at shutdown, I guess we could keep doing the umount loop in the real root also for the premounted filesystems (and at least remount them ro), but not complain too much if we can't umount them, as the failure is sort of expected. I'm not too keen on a blacklist. It would work for the simple case of course, but I have seen lots of fancy/complicated stuff being mounted in the initrd for people doing live media/install discs, which I really don't think we can/should cover by using an explicit list. Well, everything that this list would declare is that /, /etc, /usr (and maybe very few others) are the bits that systemd requires to be mounted when the host's systemd is first invoked. Where it is mounted from, and in which order would be up to the distros, but I'd really would like to make it clear that these three dirs *must* be valid when the host systemd initializes. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Wed, 2013-09-11 at 16:31 +0200, Lennart Poettering wrote: Well, everything that this list would declare is that /, /etc, /usr (and maybe very few others) are the bits that systemd requires to be mounted when the host's systemd is first invoked. Where it is mounted from, and in which order would be up to the distros, but I'd really would like to make it clear that these three dirs *must* be valid when the host systemd initializes. That makes total sense! But my concern is more about *unmounting*. So let's say that an initramfs uses some special filesystem for /etc that causes it be a mountpoint; for example, it's backed by a special NVRAM device. I think systemd should just assume that the initramfs will take care of unmounting it, and not attempt to unmount it gracefully by default, i.e. save it until the final kill spree. And more generally for all filesystems that were mounted by the initramfs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] util, utf8: new wellipsize and wellipsize_mem that take into account multi-byte characters
This version counts all multibyte characters as 1 width, not taking into account double width cjk characters and zerowidth characters --- src/shared/util.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/shared/util.c b/src/shared/util.c index b791433..c6375e5 100644 --- a/src/shared/util.c +++ b/src/shared/util.c @@ -3310,14 +3310,14 @@ char *ascii_ellipsize_mem(const char *s, size_t old_length, size_t new_length, u continue; memcpy(r, s, x); -r[x] = '.'; -r[x+1] = '.'; -r[x+2] = '.'; +r[x] = 0xe2; +r[x+1] = 0x80; +r[x+2] = 0xa6; for (j=(x+3);(unsigned char)s[j] 0x80;j++) continue; -memcpy(r + x + 3, +memcpy(r + x + 1, s + old_length - (new_length - j), new_length - j); -- 1.8.4.rc3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util, utf8: recognize wide characters in wellipsize_mem()
Original Message
From: Zbigniew Jędrzejewski-Szmek
To: shawnland...@gmail.com
CC: systemd-devel@lists.freedesktop.org, Shawn Landden
Sent: Tue, Sep 10, 2013, 08:59
Subject: Re: [systemd-devel] [PATCH] util, utf8: recognize wide characters in
wellipsize_mem()
Hi Shawn,
thank you for attacking this, and sorry for the long delay in answering.
I think that the approach of copying working code from elsewhere for this
is right, but I think it should go into its own file, so that two coding
styles are not mixed.The functions come from the same original source however
(same two files in glib) so I think they should go together, perhaps the older
take functions should be transfered back to their original style?
Also, can those new functions replace normal ellipsize and ellipsize_mem,
so that we have support everywhere?renamed old to ascii_*
e = new0(char, new_length*4 old_length ? new_length*4 : old_length);
→ we have a min macro
fixed
There are some compilation warnings:
../src/shared/utf8.c: In function 'unichar_iswide':
../src/shared/utf8.c:435:9: warning: passing argument 1 of 'bsearch' makes
pointer from integer without a cast [enabled by default]
interval_compare))
^
In file included from ../src/shared/utf8.c:51:0:
/usr/include/stdlib.h:754:14: note: expected 'const void *' but argument is of
type 'long int'
extern void *bsearch (const void *__key, const void *__base,
fixed
../src/shared/util.c: In function 'wellipsize_mem':
../src/shared/util.c:3353:9: warning: array subscript has type 'char'
[-Wchar-subscripts]
for (i = (char *)s;k x;i = utf8_next_char(i)) {
^
../src/shared/util.c:3380:17: warning: array subscript has type 'char'
[-Wchar-subscripts]
i = utf8_next_char(i);
^not sure how to fix this,I am iterating over a pointer to char, but i am not
evaluating it (it is a warning about signed vs unsigned char.)
and valgrind finds some leaks:
% valgrind --leak-check=full build/.libs/test-wellipsize
==19953==
==19953== HEAP SUMMARY:
==19953== in use at exit: 1,379 bytes in 6 blocks
==19953== total heap usage: 6 allocs, 0 frees, 1,379 bytes allocated
==19953==
==19953== 81 bytes in 1 blocks are definitely lost in loss record 1 of 6
==19953==at 0x4A08121: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19953==by 0x400F57: ellipsize_mem (util.c:3300)
==19953==by 0x401082: wellipsize_mem (util.c:3336)
==19953==by 0x40122A: wellipsize (util.c:3388)
==19953==by 0x400CFF: test_one (test-wellipsize.c:28)
==19953==by 0x400D4C: main (test-wellipsize.c:37)
...
I think it was just my lazy test, which I fixed, but I am on ARM, so let me
know if this persists on amd64
On Wed, Aug 28, 2013 at 03:58:29PM -0700, Shawn wrote:
here is the test runner I am using, doesn't really make sense to add this
to the tree as it has to be visually inspected
I think it is still useful, since we don't have anything better for now. Anyway,
we have a bunch of tests which can only be run manually. Your test is certainly
good enough for valgrind testing and visual inspection, so it should go in.
ok
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] util: ellipsize_mem: do not print partial utf-8 characters
---
Makefile.am| 7 +++
TODO | 4 --
src/shared/utf8.c | 120 +
src/shared/utf8.h | 100 +
src/shared/util.c | 83 +--
src/shared/util.h | 3 ++
src/test/test-wellipsize.c | 42
7 files changed, 351 insertions(+), 8 deletions(-)
create mode 100644 src/test/test-wellipsize.c
diff --git a/Makefile.am b/Makefile.am
index cdbfdea..8813299 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1124,6 +1124,7 @@ tests += \
test-unit-file \
test-util \
test-date \
+ test-wellipsize \
test-sleep \
test-replace-var \
test-sched-prio \
@@ -1302,6 +1303,12 @@ test_date_SOURCES = \
test_date_LDADD = \
libsystemd-core.la
+test_wellipsize_SOURCES = \
+src/test/test-wellipsize.c
+
+test_wellipsize_LDADD = \
+libsystemd-core.la
+
test_sleep_SOURCES = \
src/test/test-sleep.c
diff --git a/TODO b/TODO
index fe305ec..a77ebe5 100644
--- a/TODO
+++ b/TODO
@@ -19,10 +19,6 @@ Bugfixes:
* properly handle .mount unit state tracking when two mount points are stacked
one on top of another on the exact same mount point.
-* ellipsize_mem must take into account multi-byte unicode characters, and
- - make the resulting line the requested number of *characters*, not *bytes*,
- - avoid truncuating multi-byte sequences in the middle.
-
* When we detect invalid UTF-8, we cant't use it in an error message:
log...(Path is not UTF-8 clean, ignoring assignment: %s, rvalue);
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 655cc77..a9308b5 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -22,6 +22,11 @@
/* This file is based on the GLIB utf8 validation functions. The
* original license text follows. */
+/* gunicode.h - Unicode manipulation functions
+ *
+ * Copyright (C) 1999, 2000 Tom Tromey
+ * Copyright 2000, 2005 Red Hat, Inc.
+ */
/* gutf8.c - Operations on UTF-8 strings.
*
* Copyright (C) 1999 Tom Tromey
@@ -317,3 +322,118 @@ char *utf16_to_utf8(const void *s, size_t length) {
return r;
}
+
+/**
+ * g_utf8_prev_char:
+ * @p: a pointer to a position within a UTF-8 encoded string
+ *
+ * Finds the previous UTF-8 character in the string before @p.
+ *
+ * @p does not have to be at the beginning of a UTF-8 character. No check
+ * is made to see if the character found is actually valid other than
+ * it starts with an appropriate byte. If @p might be the first
+ * character of the string, you must use g_utf8_find_prev_char() instead.
+ *
+ * Return value: a pointer to the found character.
+ **/
+char *
+utf8_prev_char (const char *p)
+{
+ while (1)
+{
+ p--;
+ if ((*p 0xc0) != 0x80)
+ return (char *)p;
+}
+}
+
+/**
+ * g_utf8_get_char:
+ * @p: a pointer to Unicode character encoded as UTF-8
+ *
+ * Converts a sequence of bytes encoded as UTF-8 to a Unicode character.
+ * If @p does not point to a valid UTF-8 encoded character, results are
+ * undefined. If you are not sure that the bytes are complete
+ * valid Unicode characters, you should use g_utf8_get_char_validated()
+ * instead.
+ *
+ * Return value: the resulting character
+ **/
+unichar
+utf8_get_char (const char *p)
+{
+ int i, mask = 0, len;
+ unichar result;
+ unsigned char c = (unsigned char) *p;
+
+ UTF8_COMPUTE (c, mask, len);
+ if (len == -1)
+return (unichar)-1;
+ UTF8_GET (result, p, i, mask, len);
+
+ return result;
+}
+
+struct Interval
+{
+ unichar start, end;
+};
+
+static int
+interval_compare (const void *key, const void *elt)
+{
+ unichar c = (unichar) (long) (key);
+ struct Interval *interval = (struct Interval *)elt;
+
+ if (c interval-start)
+return -1;
+ if (c interval-end)
+return +1;
+
+ return 0;
+}
+
+/*
+ * NOTE:
+ *
+ * The tables for g_unichar_iswide() and g_unichar_iswide_cjk() are
+ * generated from the Unicode Character Database's file
+ * extracted/DerivedEastAsianWidth.txt using the gen-iswide-table.py
+ * in this way:
+ *
+ * ./gen-iswide-table.py path/to/ucd/extracted/DerivedEastAsianWidth.txt |
fmt
+ *
+ * Last update for Unicode 6.0.
+ */
+
+/**
+ * g_unichar_iswide:
+ * @c: a Unicode character
+ *
+ * Determines if a character is typically rendered in a double-width
+ * cell.
+ *
+ * Return value: %TRUE if the character is wide
+ **/
+bool
+unichar_iswide (unichar c)
+{
+ /* See NOTE earlier for how to update this table. */
+ static const struct Interval wide[] = {
+{0x1100, 0x115F}, {0x2329, 0x232A}, {0x2E80, 0x2E99}, {0x2E9B, 0x2EF3},
+{0x2F00, 0x2FD5}, {0x2FF0, 0x2FFB}, {0x3000, 0x303E}, {0x3041, 0x3096},
+{0x3099, 0x30FF}, {0x3105, 0x312D}, {0x3131, 0x318E}, {0x3190, 0x31BA},
+{0x31C0, 0x31E3}, {0x31F0, 0x321E}, {0x3220, 0x3247}, {0x3250, 0x32FE},
+{0x3300, 0x4DBF}, {0x4E00, 0xA48C}, {0xA490, 0xA4C6}, {0xA960, 0xA97C},
+
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Wed, 11.09.13 10:46, Colin Walters (walt...@verbum.org) wrote: Well, everything that this list would declare is that /, /etc, /usr (and maybe very few others) are the bits that systemd requires to be mounted when the host's systemd is first invoked. Where it is mounted from, and in which order would be up to the distros, but I'd really would like to make it clear that these three dirs *must* be valid when the host systemd initializes. That makes total sense! BTW, I started putting this together: http://www.freedesktop.org/wiki/Software/systemd/FileHierarchy/ Which is supposed to document the actual requirements systemd makes. i.e. that subset of the FHS that systemd actually cares about. Suggestions welcome. But my concern is more about *unmounting*. So let's say that an initramfs uses some special filesystem for /etc that causes it be a mountpoint; for example, it's backed by a special NVRAM device. Well, but /etc would be one of those which would be listed in that OS resource dir list... I think systemd should just assume that the initramfs will take care of unmounting it, and not attempt to unmount it gracefully by default, i.e. save it until the final kill spree. And more generally for all filesystems that were mounted by the initramfs. Note that killing spree is done before we jump back into the initramfs... So there's three steps: 1. normal unmounting using mount units 2. killing spree unmounting of left-overs in a tight loop based on /proc/self/mountinfo 3. initrd unmounting of remaining OS resource dirs Where 3 is optional, and done only on initrds which implement this. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
On Mon, 19.08.13 00:15, Tom Gundersen (t...@jklm.no) wrote: The main usecase for this is to make it possible to use cryptsetup in the initrd without it having to include a host-specific /etc/crypttab. Hmm, I contrast to Harald I think adding luks.options= would actually be OK. I don't think we really strictly need something here that can cover everything. I think it is OK if we have a minimal, easy, reduced-functionality way to configure luks disks via the kernel cmdline and a full-blown one with /etc/crypttab. It's a bit weird but I think not totally incomprehensible to users. Hence adding luks.options= and rd.luks.options= sounds like a very simple minimal addition here. If people really want per-device options, then one day we could on top of this just extend the preexisting luks.uuid= syntax to also take a key file and an option string via some ; based syntax (i.e. taking up Harald's idea, but voerloading it into luks.uuid=). Or in other words, have this syntax now: luks.uuid=UUID luks.key=KEY luks.options=OPTIONS (and the allow discards thing would be subsumed under luks.options) And then one day maybe optionally allow this syntax too: luks.uuid=UUID;KEY;OPTIONS Does that make sense? So yeah, Tom, I think you patch looks good and should go in (but please update kernel-command-line(7) too), unless Harald violently opposes? ;-) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] brightness in tmpfiles.d
On Mon, 12.08.13 22:40, Christian Hesse (l...@eworm.de) wrote: Hello everybody, I have a file /etc/tmpfiles.d/brightness.conf containing this line: w /sys/class/backlight/acpi_video0/brightness - - - - 10 This used to set the brightness on boot, but broke lately. The path is correct, so I assume this is a race condition. Any chance to get this work again? Just a quick follow-up on this. systemd git now includes a tiny tool to save/restore the backlight late at shutdown/early at boot, similar to how we handle random seed already. This should make all manual dealing with tmpfiles/udev rules unnecessary, and just make this all work. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Wed, 2013-09-11 at 16:55 +0200, Lennart Poettering wrote: Well, but /etc would be one of those which would be listed in that OS resource dir list... Sure, it makes total sense for systemd to hard require it (and the others) to be mounted; again I'm just more interested in the unmounting. So there's three steps: 1. normal unmounting using mount units Trying to do this with current ostree is causing problems, and similarly with special LiveCD setups, and as danpb said a while ago, container cases where the external system mounts resources for the container. 2. killing spree unmounting of left-overs in a tight loop based on /proc/self/mountinfo This part works fine for me. 3. initrd unmounting of remaining OS resource dirs And I don't need this myself; having to keep the initramfs around just to invoke umount() would be kind of lame when systemd can just do it itself easily enough after all processes other than pid 1 are gone. So step 3 is only needed AIUI for network/daemon-controlled root filesystem (per http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ ) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: Retry indefinitely if tries=0 option has been set.
On Sun, 18.08.13 18:24, Thomas Bächler (tho...@archlinux.org) wrote: When running from initrd, entering a wrong passphrase usually means that you cannot boot. Therefore, we allow trying indefinitely. --- This is useful together with Tom's latest patch. On my system, I use rd.luks.options=allow-discards,tries=0 so unless booting succeeds, I will be prompted for a passphrase indefinitely. Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [REMINDER] Next Week systemd Hackfest in New Orleans! (colocated with LinuxCon/LPC)
Heya! Next week we'll have another two day systemd hackfest, this time in New Orleans, co-located with LinuxCon/Linux Plumbers Conference. https://plus.google.com/u/0/events/ce60f0rq4lldbti9qgg0u4j8rbc You are invited! It starts on monday morning 9am, at the Grand Hyatt, Room Imperial 11. To enter you probably need a LinuxCon registration, please contact Harald Hoyer who might be able to help you if you don't have one. (Would be cool to indicate on the Google+ event if you are coming, so that we have an idea how many people to expect!) Also note that there's going to be a BootInit miniconf at LPC with lots of systemd related topics. On top of that, I'll do a presentation about Resource Management with systemd at LinuxCon. See you in New Orleans! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impact when not loading ipv6 and autofs kernel module ...
On Wed, 14.08.13 16:43, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: For what is systemd using the loopback so that it has to set it up so early? Is there any impact when I'm setting up the loopback later. We are probably in a situation where we need ipv4 for general purposes and ipv6 for only special ones. So we'd like to set up ipv6 later for performance reasons, which concerns especially the module loading. Humm, I doubt that initializing IPv6 early will really slow things down for you. The reason we initialize the loopback device this early is simply that most userspace code simply expects it to be there, and working, and it's absolutely trivial and fast to do, so we just do it by default, so that it just works and is nothing the user can manually configure and where we then have to parse configuraiton files and have another distinct component running late in boot dealing with this and so on... It's really something we want to be quick, and always done and non-configurable and since its a triviality to do we just do it in PID 1... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] Make reboot to support additional command
On Tue, 13.08.13 03:01, WaLyong Cho (fyd0...@gmail.com) wrote:
From: WaLyong Cho walyong@samsung.com
reboot syscall can be performed with additional argument. In some of
system, this functionality can be useful to ask next boot mode to
bootloader.
Hmm, interesting stuff.
@@ -5200,9 +5204,19 @@ static int halt_parse_argv(int argc, char *argv[]) {
}
}
Note that halt is not called during normal shutdown, but is only a
compat fallback for the old sysv halt command. If you want this to
work we probably need to come up with a way to pass the string from
systemctl to the final systemd-shutdown process.
(A bit of background: systemctl normally will just tell PID 1 to
shutdown cleanly, via D-Bus. As last step of that PID 1 will execute the
special systemd-shutdown binary -- which will then also run as PID 1 --
which will do some final shutdown steps and then invoke the reboot()
syscall -- see src/core/shutdown.c for details)
So, before we continue with this, could you point me to some
docs/commits/code which explain a bit how the new reboot() syscall
semantics work? i.e. what the possible params are and such?
One way to implement this could be to add add a new parameter to
systemctl which is written to /run/systemd/reboot-param or so if
specified. systemd-shutdown would then look for that file and pass it to
the reboot() syscall.
-if (optind argc) {
-log_error(Too many arguments.);
-return -EINVAL;
+if (arg_action == ACTION_REBOOT) {
+/* reboot allow just one argument for his command string */
+if (optind+1 == argc)
+arg_reboot = strdup(argv[argc-1]);
+else if (optind+1 argc) {
+log_error(Too many arguments.);
+return -EINVAL;
+}
+} else {
+if (optind argc) {
+log_error(Too many arguments.);
+return -EINVAL;
+}
}
return 1;
@@ -5949,7 +5963,11 @@ static _noreturn_ void halt_now(enum action a) {
case ACTION_REBOOT:
log_info(Rebooting.);
-reboot(RB_AUTOBOOT);
+if (arg_reboot)
+syscall(SYS_reboot, LINUX_REBOOT_MAGIC1,
LINUX_REBOOT_MAGIC2,
+LINUX_REBOOT_CMD_RESTART2, arg_reboot);
+else
+reboot(RB_AUTOBOOT);
break;
default:
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Wed, 11.09.13 12:00, Colin Walters (walt...@verbum.org) wrote: On Wed, 2013-09-11 at 16:55 +0200, Lennart Poettering wrote: Well, but /etc would be one of those which would be listed in that OS resource dir list... Sure, it makes total sense for systemd to hard require it (and the others) to be mounted; again I'm just more interested in the unmounting. So there's three steps: 1. normal unmounting using mount units Trying to do this with current ostree is causing problems, and similarly with special LiveCD setups, and as danpb said a while ago, container cases where the external system mounts resources for the container. Can you elaborate on this? Why wouldn't it suffice to drop in a .mount unit for the mount in question which excludes the mount point from being unmounted with this? 2. killing spree unmounting of left-overs in a tight loop based on /proc/self/mountinfo This part works fine for me. 3. initrd unmounting of remaining OS resource dirs And I don't need this myself; having to keep the initramfs around just to invoke umount() would be kind of lame when systemd can just do it itself easily enough after all processes other than pid 1 are gone. So step 3 is only needed AIUI for network/daemon-controlled root filesystem (per http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ ) Not just that. Also for complex local storage where some block device needs to be dissambled before we power down... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] sd-login: add a public accessor for the VT number
From: Giovanni Campagna gcamp...@redhat.com
The VT number was already part of the DBus API, but was not
exposed in the C API.
---
man/sd_session_is_active.xml | 13 +
src/login/libsystemd-login.sym | 5 +
src/login/sd-login.c | 18 ++
src/systemd/sd-login.h | 3 +++
4 files changed, 39 insertions(+)
diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml
index e89117d..9362fbc 100644
--- a/man/sd_session_is_active.xml
+++ b/man/sd_session_is_active.xml
@@ -52,6 +52,7 @@
refnamesd_session_get_class/refname
refnamesd_session_get_display/refname
refnamesd_session_get_tty/refname
+refnamesd_session_get_vt/refname
refpurposeDetermine state of a specific session/refpurpose
/refnamediv
@@ -111,6 +112,12 @@
paramdefconst char*
parametersession/parameter/paramdef
paramdefchar**
parametertty/parameter/paramdef
/funcprototype
+
+funcprototype
+funcdefint
functionsd_session_get_vt/function/funcdef
+paramdefconst char*
parametersession/parameter/paramdef
+paramdefunsigned*
parametervt/parameter/paramdef
+/funcprototype
/funcsynopsis
/refsynopsisdiv
@@ -202,6 +209,12 @@
citerefentryrefentrytitlefree/refentrytitlemanvolnum3/manvolnum/citerefentry
call after use./para
+parafunctionsd_session_get_vt()/function
+may be used to determine the VT number of the
+session identified by the specified session
+identifier. This function will return an error if
+the seat does not support VTs./para
+
paraIf the varnamesession/varname parameter of
any of these functions is passed as
constantNULL/constant the operation is executed
diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
index 0720704..7512ef5 100644
--- a/src/login/libsystemd-login.sym
+++ b/src/login/libsystemd-login.sym
@@ -80,3 +80,8 @@ LIBSYSTEMD_LOGIN_205 {
global:
sd_pid_get_slice;
} LIBSYSTEMD_LOGIN_203;
+
+LIBSYSTEMD_LOGIN_206 {
+global:
+sd_session_get_vt;
+} LIBSYSTEMD_LOGIN_205;
\ No newline at end of file
diff --git a/src/login/sd-login.c b/src/login/sd-login.c
index 0658792..6a6e04e 100644
--- a/src/login/sd-login.c
+++ b/src/login/sd-login.c
@@ -347,6 +347,24 @@ _public_ int sd_session_get_tty(const char *session, char
**tty) {
return session_get_string(session, TTY, tty);
}
+_public_ int sd_session_get_vt(const char *session, unsigned *vtnr) {
+_cleanup_free_ char *vtnr_string;
+char *end;
+int r;
+unsigned long v;
+
+r = session_get_string(session, VTNr, vtnr_string);
+if (r 0)
+return r;
+
+v = strtoul(vtnr_string, end, 10);
+if (end == vtnr_string || *end)
+return -EINVAL;
+
+*vtnr = v;
+return 0;
+}
+
_public_ int sd_session_get_service(const char *session, char **service) {
return session_get_string(session, SERVICE, service);
}
diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h
index e37aeda..c5837f0 100644
--- a/src/systemd/sd-login.h
+++ b/src/systemd/sd-login.h
@@ -124,6 +124,9 @@ int sd_session_get_display(const char *session, char
**display);
/* Determine the TTY of this session. */
int sd_session_get_tty(const char *session, char **display);
+/* Determine the VT number of this session. */
+int sd_session_get_vt(const char *session, unsigned *vtnr);
+
/* Return active session and user of seat */
int sd_seat_get_active(const char *seat, char **session, uid_t *uid);
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] sd-login: add a public accessor for the VT number
On Wed, 11.09.13 18:48, Giovanni Campagna (scampa.giova...@gmail.com) wrote:
From: Giovanni Campagna gcamp...@redhat.com
The VT number was already part of the DBus API, but was not
exposed in the C API.
Thanks! Applied with minor changes (replaced strtoul with our own
safe_atou() which is a ton easier to use).
---
man/sd_session_is_active.xml | 13 +
src/login/libsystemd-login.sym | 5 +
src/login/sd-login.c | 18 ++
src/systemd/sd-login.h | 3 +++
4 files changed, 39 insertions(+)
diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml
index e89117d..9362fbc 100644
--- a/man/sd_session_is_active.xml
+++ b/man/sd_session_is_active.xml
@@ -52,6 +52,7 @@
refnamesd_session_get_class/refname
refnamesd_session_get_display/refname
refnamesd_session_get_tty/refname
+refnamesd_session_get_vt/refname
refpurposeDetermine state of a specific
session/refpurpose
/refnamediv
@@ -111,6 +112,12 @@
paramdefconst char*
parametersession/parameter/paramdef
paramdefchar**
parametertty/parameter/paramdef
/funcprototype
+
+funcprototype
+funcdefint
functionsd_session_get_vt/function/funcdef
+paramdefconst char*
parametersession/parameter/paramdef
+paramdefunsigned*
parametervt/parameter/paramdef
+/funcprototype
/funcsynopsis
/refsynopsisdiv
@@ -202,6 +209,12 @@
citerefentryrefentrytitlefree/refentrytitlemanvolnum3/manvolnum/citerefentry
call after use./para
+parafunctionsd_session_get_vt()/function
+may be used to determine the VT number of the
+session identified by the specified session
+identifier. This function will return an error if
+the seat does not support VTs./para
+
paraIf the varnamesession/varname parameter of
any of these functions is passed as
constantNULL/constant the operation is executed
diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
index 0720704..7512ef5 100644
--- a/src/login/libsystemd-login.sym
+++ b/src/login/libsystemd-login.sym
@@ -80,3 +80,8 @@ LIBSYSTEMD_LOGIN_205 {
global:
sd_pid_get_slice;
} LIBSYSTEMD_LOGIN_203;
+
+LIBSYSTEMD_LOGIN_206 {
+global:
+sd_session_get_vt;
+} LIBSYSTEMD_LOGIN_205;
\ No newline at end of file
diff --git a/src/login/sd-login.c b/src/login/sd-login.c
index 0658792..6a6e04e 100644
--- a/src/login/sd-login.c
+++ b/src/login/sd-login.c
@@ -347,6 +347,24 @@ _public_ int sd_session_get_tty(const char *session,
char **tty) {
return session_get_string(session, TTY, tty);
}
+_public_ int sd_session_get_vt(const char *session, unsigned *vtnr) {
+_cleanup_free_ char *vtnr_string;
+char *end;
+int r;
+unsigned long v;
+
+r = session_get_string(session, VTNr, vtnr_string);
+if (r 0)
+return r;
+
+v = strtoul(vtnr_string, end, 10);
+if (end == vtnr_string || *end)
+return -EINVAL;
+
+*vtnr = v;
+return 0;
+}
+
_public_ int sd_session_get_service(const char *session, char **service) {
return session_get_string(session, SERVICE, service);
}
diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h
index e37aeda..c5837f0 100644
--- a/src/systemd/sd-login.h
+++ b/src/systemd/sd-login.h
@@ -124,6 +124,9 @@ int sd_session_get_display(const char *session, char
**display);
/* Determine the TTY of this session. */
int sd_session_get_tty(const char *session, char **display);
+/* Determine the VT number of this session. */
+int sd_session_get_vt(const char *session, unsigned *vtnr);
+
/* Return active session and user of seat */
int sd_seat_get_active(const char *seat, char **session, uid_t *uid);
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] stop+start of nspawn scope aborts: 's-state == SCOPE_DEAD'
On Mon, 12.08.13 19:41, Marti Raudsepp (ma...@juffo.org) wrote: Hi list, I hit a bug today in the scope unit support. Reproducible like this: systemd-nspawn -bD /srv/subarch systemctl stop machine-subarch.scope systemctl start machine-subarch.scope I wasn't sure whether start would do anything or not so I gave it a shot, but it turned out to crash the host systemd with: Assertion 's-state == SCOPE_DEAD' failed at src/core/scope.c:246, function scope_start(). Aborting Tested with systemd 206 as well as current git master (206.103.g631c922) on Arch Linux. /srv/subarch is a plain Arch Linux installation created according to: https://wiki.archlinux.org/index.php/Arch_systemd_container OK, I fixed the crash, but this is incomplete as we really should disallow multipl start requests on the same scope. I have added a TODO list item for the latter now. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User journal corrupted or uncleanly shut down, renaming and replacing
On Mon, 12.08.13 14:58, Pedro Francisco (pedrogfranci...@gmail.com) wrote: Hi, Systemd complains frequently about corrupted journal. Do note: I don't have the default mount options. $ dmesg |grep corrupte [ 51.766346] systemd-journald[181]: File /var/log/journal/06fde5edd4974fa9a343215f093f5aae/user-42.journal corrupted or uncleanly shut down, renaming and replacing. $ sudo rpm -qa systemd systemd-204-9.fc19.i686 $ cat /proc/mounts (...) /dev/sda6 / ext4 rw,seclabel,noatime,nobarrier 0 0 (...) In addition, I have an issue related to systemd-journald stopping logging after a while if there are lots of output, as I mentioned on http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/12373 titled Journald stops logging when lots of output . Do you think: a) mount options can affect systemd logging and b) these two issues (the one on this email about corrupted journal and the one on the linked thread about journald crashing when there are lots of output) may be related? Thanks in Advance, My guess is that for some reason the file systems are not properly unmounted during shutdown. Can you maybe try to get shutdown logs as described here? http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 Are you using LVM or something else weird? Are you using Dracut? Does the issue go away if you drop nobarrier from your mount options? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.
On Mon, 12.08.13 01:44, Tony Seo (tonys...@gmail.com) wrote: I sincerely ask you a relationship between device unit and boot time if I remove unnecessary device unit. And also, can I ask you detail process of making device unit by systemd? (I alread read the manual page related with device unit) the kernel creates a directory in /sys for each device popping up. udev then maintains some additional metadata for all those devices. One part of that metadata is a tag that might be on select devices called systemd. If a a device is tagged like that it will also show up as .device unit systemd. By default block devices, ttys and a few others are tagged like that. Some services need to wait for some block devices before they can be run (for example, fsck instances need to wait for their respective block devices to show up before they can be started), and this is implemented via dependencies to these device units. Device units hence are not really something active in themselves, they just reflect as units state of another component of the OS (which is udev/kernel). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Generic unit file to run command on shutdown impossible?
On Sat, 10.08.13 15:59, David Mazieres expires 2013-11-08 PST (mazieres-rq54ugpgb894kkmq2swhjjb...@temporary-address.scs.stanford.edu) wrote: I'm trying to do something that I hope is relatively simple, namely to run a simple kexec -l ... command on system shutdown before the /boot file system is unmounted. I'm trying this on two different machines, both of which are running current versions of arch linux with systemd 204. The machines are configured very similarly, except that one has a serial console and some NFS mounts, while the other does not. Unfortunately, I cannot find a single script that works on both machines. On the machine with a serial console, the following unit file seems to work (in /etc/systemd/system/kexec-load@.service, enabled with systemctl enable kexec-load@linux). This is a slightly modified version of a suggestion on the arch linux wiki: It's usually a better idea to have this as unit that starts at bootup, and stops at shutdown, rather than one that starts at shutdown. This is because of the orderign semantics of start and stop jobs. The general rule here is that if one job is started and one is stopped and there is either After= or Before= defined between their two units, then the Stop= is always run first, and the start second, regardless whether After or Before was used. After/Before= hence only declare the ordering between two start jobs, and the ordering between two stop jobs (where the rule is that it is the inverse of the start order), but not between a start and a stop job. This might be confusing, but not too difficult to grok I guess.. Effectively this means that you should define a RemainAfterExit=yes service with ExecStart=/bin/true and ExecStop= set to what you want to run at shutdown. The requirement to set an ExecStart= is something we will lift soon, but for now it is required. I hope this makes some sense? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv4] tmpfiles, man: Add xattr support to tmpfiles
On Thu, 08.08.13 13:54, Maciej Wereski (m.were...@partner.samsung.com) wrote:
+value = strreplace(tmp, \\\, \);
+if (!value)
+return log_oom();
This looks like a job for cunescape() or so?
+n = strlen(value);
+if (i-type == CREATE_SYMLINK) {
+if (lsetxattr(path, name, value, n+1, 0) 0) {
+log_error(Setting extended attribute %s=%s
on symlink %s failed: %m, name, value, path);
+return -errno;
+}
+}
+else if (setxattr(path, name, value, n+1, 0) 0) {
+log_error(Setting extended attribute %s=%s on %s
failed: %m, name, value, path);
+return -errno;
+}
+}
+return 0;
+#else
+(void)i;
+(void)path;
+log_error(Setting extended attributes requested, but tmpfiles was
compiled without XATTR support!);
+return -ENOTSUP;
If I follow the control flow correctly then this message would be
generated for *all* entries if XATTR support is not compiled in,
regardless whether xattrs shall actually be set... This part should come
after the early-return check whether the xattr list is actually empty...
+xattr = new0(char, strlen(i-argument)+1);
+if (!xattr)
+return log_oom();
+
+tmp = strv_split(i-argument, WHITESPACE);
+if (!tmp)
+return log_oom();
+
+for (n = 0; n strv_length(tmp); ++n) {
strv_length() is relatively expensive (O(n)), please cache the result.
+len = strlen(tmp[n]);
+strncpy(xattr, tmp[n], len+1);
+p = strchr(xattr, '=');
+if (!p) {
+log_error(%s: Attribute has incorrect format.,
i-path);
+return -EBADMSG;
+}
+if (p[1] == '\') {
+while (true) {
+if (!p)
+p = tmp[n];
+else
+p += 2;
+p = strchr(p, '\');
+if (p xattr[p-xattr-1] != '\\')
+break;
+p = NULL;
+++n;
+if (n == strv_length(tmp))
+break;
+len += strlen(tmp[n]) + 1;
+strncat(xattr, , 1);
+strncat(xattr, tmp[n], len);
+}
+}
+strstrip(xattr);
Hmm, this also is a job for split_pair and cunescape, no? Or am I confused?
Otherwise looks fine!
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inconsistencies in the systemd.mount documentation
Am 11.09.2013 17:08, schrieb Lennart Poettering: Using FsckPassNo= as a way to add that dep sucks really, because the ordering it does is stupid and fsck can do the ordering internally anyway these days... So, shouldn't systemd-fstab-generator omit that entirely, too? Instead, every mount with pass!=0 should get the correct fsck dependency. Automatically adding deps to fsck for all mounts is wrong too, since only some block-based file systems need fsck and it would suck having to carry a whitelist for thos in systemd. Fair enough. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v1] crontab-generator: new generator for crontab(5) support
On Thu, 08.08.13 14:50, Shawn (shawnland...@gmail.com) wrote: I am not convinced this is a really good idea. From my perspective at least it appears that we should much rather just convert the crontabs and that's it. Unlike sysv init scripts the number of crontab in use (at least on Fedora) is relatively small, and very rare in third-party packages. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trying to turn off a UPS with home-made service unit
On Sat, 10.08.13 17:02, Roger Price (ro...@rogerprice.org) wrote: I am new to systemd and I am trying to power off a UPS unit using a home-made service unit /lib/systemd/system/ups-delayed-shutdown.service running on openSUSE 12.3. So, it's a really bad idea to turn off UPS from userspace, simply because you will race against the kernel's fs sync() code, and you never know what will finish first: your UPS shutdown timeout or your fs sync(). Doing this from userspace is hence racy. If you want to use a hack like this then at least do it via the /usr/lib/systemd/system-shutdown/ drop-in directory which is called very late during shutdown. It will shorten the race window, but not erase it, since the kernel will flush various buffers only after the reboot() system call is invoked. See systemd-shutdown(8) for details. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inconsistencies in the systemd.mount documentation
On Wed, 11.09.13 20:04, Thomas Bächler (tho...@archlinux.org) wrote: Am 11.09.2013 17:08, schrieb Lennart Poettering: Using FsckPassNo= as a way to add that dep sucks really, because the ordering it does is stupid and fsck can do the ordering internally anyway these days... So, shouldn't systemd-fstab-generator omit that entirely, too? Instead, every mount with pass!=0 should get the correct fsck dependency. Well, in classic fstab passno=0 means no fsck, passno!=0 means fsck. On top of that the value of passno can be used to order things. We honour those rules when we convert from fstab, and for that use FsckPassNo=. That's why it is compat only... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit
On Fri, 09.08.13 16:00, Michal Sekletar (msekl...@redhat.com) wrote:
Heya,
Hmm, so what I don't really like about this patch is that the stop might
have caused the triggering units also to go away via some deps. If we
check the triggers before executing the operations we will never take
that into account. (Note that so far the trigger message is delayed
after the job succeeded in order to make sure we can take the full
a-posteriori state into account).
So not sure, Zbigniew, do you have an opinion on this?
(Also, Michal, what about the other patches from this series, are they
still relevant? I amnot sure if you pulled them back or not, the thread
confused me)
Lennart
From a62d3668fb2513b1ece827520d44d5b7cd560407 Mon Sep 17 00:00:00 2001
From: Michal Sekletar msekl...@redhat.com
Date: Thu, 8 Aug 2013 13:26:56 +0200
Subject: [PATCH 1/3] systemctl: check for triggering units before calling
StopUnit
Rearranging the code in a way that we always check for triggers before
we issue StopUnit D-Bus call. This will make behavior consistent,
because triggers are always checked.
https://bugzilla.redhat.com/show_bug.cgi?id=908690
---
src/systemctl/systemctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 8ec1824..ee47841 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char
**args) {
return log_oom();
}
+/* When stopping units, warn if they can still be triggered by
+ * another active unit (socket, path, timer) */
+if (!arg_quiet streq(method, StopUnit)) {
+if (one_name)
+check_triggering_units(bus, one_name);
+else
+STRV_FOREACH(name, args+1)
+check_triggering_units(bus, *name);
+}
+
if (one_name) {
ret = start_unit_one(bus, method, one_name, mode, error, s);
if (ret 0)
@@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char
**args) {
r = wait_for_jobs(bus, s);
if (r 0)
return r;
-
-/* When stopping units, warn if they can still be triggered
by
- * another active unit (socket, path, timer) */
-if (!arg_quiet streq(method, StopUnit)) {
-if (one_name)
-check_triggering_units(bus, one_name);
-else
-STRV_FOREACH(name, args+1)
-check_triggering_units(bus, *name);
-}
}
return ret;
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journald stops logging when lots of output
On Sat, 03.08.13 23:14, Pedro Francisco (pedrogfranci...@gmail.com) wrote: (question migrated from t...@lists.fedoraproject.org ) On Fedora 19, journald ( systemd-204-9.fc19.i686 ) stops logging. I had enabled lots of iwl3945 debugging ( various messages for each iwl3945 interaction -- modprobe iwl3945 debug=0x47ff ) throughout the night and the last thing `journalctl -b` has is: Ago 03 02:25:45 s2 systemd-journal[29414]: Allowing system journal files to grow to 1.4G. Ago 03 02:25:45 s2 systemd-journal[29414]: Journal started Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process exited, code=exited, status=1/FAILURE Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process exited, code=killed, status=10/USR1 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process exited, code=killed, status=10/USR1 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Ago 03 02:25:45 s2 systemd-journal[29419]: Allowing system journal files to grow to 1.4G. Ago 03 02:25:45 s2 systemd-journal[29419]: Journal started Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process exited, code=exited, status=1/FAILURE Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Ago 03 02:25:45 s2 systemd-journal[29423]: Allowing system journal files to grow to 1.4G. Ago 03 02:25:45 s2 systemd-journal[29423]: Journal started Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process exited, code=exited, status=1/FAILURE Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. It is now 10:35 and while dmesg has (lots) of new info, journalctl -f does not. Any tips on what may be wrong? Is this still a problem? It seems journald dies for you for some reason. Is there a way how you can reproduce the issue? If so, can you strace the journal daemon, then reproduce it, and paste the last 100 strace lines somwhere before the daemon exited? This should give us an indication what might have failed that caused it to exit. (Of course, journald should not exit under any such circumstances, but to find that we first need to track down why it does that currently). Also, if you log using a tool like logger, does that get lost too after the issue happens? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Feature request] A way to native import /proc/cmdline within unit
On Thu, 01.08.13 19:16, Jan Engelhardt (jeng...@inai.de) wrote:
On Tuesday 2013-07-30 02:12, Gerardo Exequiel Pozzi wrote:
In inside systemd unit, I want to avoid shell script if possible, using
units only, doing things in a systemd way. Anyway for complex tasks
where systemd does not fit, scripting seems to be necessary.
The systemd way is not {avoiding shell scripts at all cost},
but avoiding redundant code found in the many sysvinit scripts.
At least, that is how I see it.
Yes. We want to deemphasize shell scripts, and get them out of the
default boot, but shell is incredibly useful otherwise and here to stay.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .automount from user?
On Tue, 30.07.13 01:02, rekt...@voodoowarez.com (rekt...@voodoowarez.com) wrote: Hello. I'm curious, and perhaps maybe lazy: is there any way to do automount units from a user systemd instance? I suppose I could write some silly script that collects automount files out of the user units directories and validates and accepts them, but it would be stellar if systemd had some plan for bestowing my users their ability to use their fuse group membership in a cool rad automounting way. Peace love chicken grease- rektide. This is currently not available to unprivileged processes and is very unlikely to change, because there are all kinds of interesting ways how userspace can deadlock the kernel and that's hard to fix. For priviliged userspace code we can make the best of it and just protect ourselves from running into these deadlocks, but opening this up to unprivileged code would open a can of worms. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] configure.ac Makefile.am src/login units/u...@.service.in
On Wed, Sep 11, 2013 at 12:39 PM, Zbigniew Jędrzejewski-Szmek zbys...@kemper.freedesktop.org wrote: Makefile.am|5 + configure.ac |7 +++ src/login/pam-module.c |4 ++-- src/login/systemd-user |8 units/u...@.service.in |2 +- 5 files changed, 23 insertions(+), 3 deletions(-) New commits: commit 5c390a4ae0d383b2003074ed011d47876c7e630c Author: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Date: Wed Sep 11 14:31:14 2013 -0400 Add pam configuration to allow user sessions to work out of the box systemd-logind will start user@.service. user@.service unit uses PAM with service name 'systemd-user' to perform account and session managment tasks. Previously, the name was 'systemd-shared', it is now changed to 'systemd-user'. Most PAM installations use one common setup for different callers. Based on a quick poll, distributions fall into two camps: those that have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia, Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE). Distributions that have system-auth have just one configuration file that contains auth, password, account, and session blocks, and distributions that have common-auth also have common-session, common-password, and common-account. It is thus impossible to use one configuration file which would work for everybody. systemd-user now refers to system-auth, because it seems that the approach with one file is more popular and also easier, so let's follow that. +1 Thanks for doing this - it'll be good for folks implementing user sessions to have a consistent approach. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: fix description of sysctl.d order
systemd-sysctl gives priority to the latest occurence as of commit 04bf3c1a60d82791e0320381e9268f727708f776, but the manpage hasn't been updated for that. --- man/sysctl.d.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml index 69e96ee..ce5c34f 100644 --- a/man/sysctl.d.xml +++ b/man/sysctl.d.xml @@ -92,7 +92,7 @@ alphabetical order, regardless in which of the directories they reside, to guarantee that a specific configuration file takes precedence over another file -with an alphabetically later name, if both files +with an alphabetically earlier name, if both files contain the same variable setting./para paraIf the administrator wants to disable a -- 1.8.4.242.gbb80ee0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Mantas Mikulėnas at 11/09/13 22:53 did gyre and gimble: systemd-sysctl gives priority to the latest occurence as of commit 04bf3c1a60d82791e0320381e9268f727708f776, but the manpage hasn't been updated for that. Oh jeez... has the ordering flipped again?? I only just rejigged things for the last time this flipped around and now sysctl has decided to buck the trend of the other tools and follow a later file has priority? I think consistency is good here (even if conceptually, a later file overriding an earlier one feels better. Yes, and later-override-earlier is by far the bigger trend. :) The order was previously fixed such that earlier files win for several tools binfmt, tmpfiles These are multi-options lines which cannot really be merged or overwritten with multiple lines. Avoiding conflicting entries seems the best approach here, and the first-one-wins, the later ones complain sounds like the best approach. modules-load This is just all loaded what's in there, no order, no overwrite, doesn't it? and sysctl in fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda back in February. Sysctl really should be able to handle, and always did in the past, conflicting entries, and we should not break that stuff. The old tool just wrote the values multiple times into the kernel. Is there a reason why sysctl.conf cannot just be symlinked as sysctl.d/0-sysctl.conf rather than 99-sysctl.conf and keep the ordering consistent with the other tools? Where is that defined? /etc/sysctl.conf should not exist, in the ideal case. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: allow specifying a custom pam session name
On Fri, 26.07.13 00:28, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:
for distribution now wanting to use systemd-shared
In systemd git this is now renamed to systemd-user. This really should
get a fixed PAM name of its own and shouldn't be configurable.
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
Makefile.am| 1 +
configure.ac | 10 ++
units/u...@.service.in | 2 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index d013dfd..8030c5f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4072,6 +4072,7 @@ substitutions = \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
'|DEBUGTTY=$(DEBUGTTY)|' \
+ '|PAM_NAME=$(PAM_NAME)|' \
'|KILL=$(KILL)|' \
'|KMOD=$(KMOD)|' \
'|MKDIR_P=$(MKDIR_P)|' \
diff --git a/configure.ac b/configure.ac
index 759073a..c1d2dac 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,6 +404,15 @@ AC_SUBST(PAM_LIBS)
AM_CONDITIONAL([HAVE_PAM], [test x$have_pam != xno])
#
--
+AC_ARG_WITH([pam-name],
+AS_HELP_STRING([--with-pam-name=NAME],
+[Specify the PAM session name to set up a session as]),
+[PAM_NAME=$withval],
+[PAM_NAME=systemd-shared])
+
+AC_SUBST(PAM_NAME)
+
+#
--
AC_ARG_ENABLE([acl],
AS_HELP_STRING([--disable-acl],[Disable optional ACL support]),
[case ${enableval} in
@@ -1027,6 +1036,7 @@ AC_MSG_RESULT([
Installation Python: ${PYTHON_BINARY}
firmware path: ${FIRMWARE_PATH}
PAM modules dir: ${with_pamlibdir}
+PAM session name:${with_pam_name}
D-Bus policy dir:${with_dbuspolicydir}
D-Bus session dir: ${with_dbussessionservicedir}
D-Bus system dir:${with_dbussystemservicedir}
diff --git a/units/u...@.service.in b/units/u...@.service.in
index 8f9a3b3..ce53d31 100644
--- a/units/u...@.service.in
+++ b/units/u...@.service.in
@@ -11,7 +11,7 @@ After=systemd-user-sessions.service
[Service]
User=%I
-PAMName=systemd-shared
+PAMName=@PAM_NAME@
Type=notify
ExecStart=-@rootlibexecdir@/systemd --user
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Wed, 2013-09-11 at 19:11 +0200, Lennart Poettering wrote: Can you elaborate on this? Why wouldn't it suffice to drop in a .mount unit for the mount in question which excludes the mount point from being unmounted with this? It doesn't appear possible to remove the default Conflicts= just by creating /etc/systemd/system/var.mount. I tried doing my plan of adding a boolean to mount units if we detect them at coldplug time, and ensuring we pass that from the dracut systemd to the deserialized main pid. But what I hit doing that was from dracut-systemd's perspective it is /sysroot/var, and not /var. Would need to do some sort of device/inode pairing to fix up paths after a potential switch-root. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root
On Wed, 11.09.13 19:48, Colin Walters (walt...@verbum.org) wrote: On Wed, 2013-09-11 at 19:11 +0200, Lennart Poettering wrote: Can you elaborate on this? Why wouldn't it suffice to drop in a .mount unit for the mount in question which excludes the mount point from being unmounted with this? It doesn't appear possible to remove the default Conflicts= just by creating /etc/systemd/system/var.mount. You'd have to set DefaultDependencies=no in order to turn the implicit shutdown.target conflict dep off. I tried doing my plan of adding a boolean to mount units if we detect them at coldplug time, and ensuring we pass that from the dracut systemd to the deserialized main pid. But what I hit doing that was from dracut-systemd's perspective it is /sysroot/var, and not /var. Would need to do some sort of device/inode pairing to fix up paths after a potential switch-root. Still not convinced that we really want to do that. But note that on Linux mounts have a fixed numeric ID, which is the first column in /proc/self/mountinfo. You can also query that ID on many (but not all) file systems via the name_to_handle_at() system call (which is really nasty to use though, we already use it in path-util.c and tmpfiles.c already. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Has systemd booted up command
On Thu, 18.07.13 20:36, Umut Tezduyar (u...@tezduyar.com) wrote:
Hey,
Implementing a tool that catches the dbus signal, like you have said
must be relatively easy. In fact I believe it should be possible to do
it by dbus-monitor but the main problem is, tool itself must be
started by systemd as a service with a Before={target you are booting
to}. Otherwise you cannot be sure if the StartupFinished signal has
been sent before the tool starts.
This won't work. If you run the tool as a service like you suggest then
this service will have a job queued as long as it is running and you
will hence never get StartupFinished since your own tool is still queued.
The other need is coming due to an item in our TODO list which is,
when isolating, try to figure out a way how we implicitly can order
all units we stop before the isolating unit Since the stop jobs
are asynchronous, I would be using following command to make sure that
isolation is fully complete: systemctl is-active MyIsolated.target
systemctl show -pNJobs | grep -q Njobs=0. I do believe, this might
not be a common use case and I can live with parsing the output of
systemctl show -pNJobs.
Note that if two units are ordered against each other (regardles whether
with Before= or After=) and a stop job is queued for one of them, and a
start job is queued for the other, then the stop job will always be
executed first, the start job second. Hence it is sufficient to simply
order all units you want to have finished before or after your isolated
unit and you get what you need.
It's usually safer (and less deadlock-prone) to use systemd's own job
queuing rather than attempting your own on the side...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Some thoughts about loop_read/loop_write in util.c
2013/9/11 Lennart Poettering lenn...@poettering.net:
loop_read/loop_write:
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n2179
In a scenario of pipes, loop_read on read side, if the write side is
closed, loop_read will return 0 if do_poll is false(let's assume no
data available to read). When do_poll is true, it will return:
1) 0, if write side is closed while loop_read is just doing a read
2) or -EIO when poll returns pollfd.revent with POLLHUP flag set
The behavior is not very consistent.
IMHO, it's preferred loop_read follows read behavior as much as
possible -- returns 0 to indicate end of a file here, e.g. We can try
to read 0 bytes when pollfd.revents != POLLIN.
EOF and temporarily not being able to read more data is something very
different.
It might make sense to return EAGAIN if POLLHUP is set though.
(But note that POLLHUP has more complex semantics when combined with
shutdown() and half-open connections...)
The same with loop_write.
EOF doesn't exist for loop_write(), so this is even weirder
Sorry for not make myself clear, I mean EPIPE.
What about the following patch? It simply do read/write again if poll
returns, and let read/write report error if something is wrong.
From 3b83e839ebfc161565db76ce8d0e1dd4da1b0afc Mon Sep 17 00:00:00 2001
From: Chen Jie ch...@lemote.com
Date: Thu, 12 Sep 2013 09:21:41 +0800
Subject: [PATCH] util.c: not check pollfd.revent for loop_read/loop_write
If an error occurred, let read/write report it.
---
src/shared/util.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 1dde8af..e08ec44 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -2206,8 +2206,10 @@ ssize_t loop_read(int fd, void *buf, size_t
nbytes, bool do_poll) {
return n 0 ? n : -errno;
}
+/*
if (pollfd.revents != POLLIN)
return n 0 ? n : -EIO;
+ */
continue;
}
@@ -2254,8 +2256,10 @@ ssize_t loop_write(int fd, const void *buf,
size_t nbytes, bool do_poll) {
return n 0 ? n : -errno;
}
+/*
if (pollfd.revents != POLLOUT)
return n 0 ? n : -EIO;
+ */
continue;
}
--
Regards,
- cee1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'
On Wed, Sep 11, 2013 at 01:27:03PM +0200, Lennart Poettering wrote: On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote: On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote: On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote: Hmm, can you elaborate on this one? libsystemd-login should be mostly This error occurs while building dbus with systemd support like below $ make make all-recursive make[1]: Entering directory `/home/chengwei/Upstream/dbus.git' Making all in dbus make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' make all-am make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' CCLD dbus-test /usr/lib/libsystemd-login.so: undefined reference to `cg_create' collect2: ld returned 1 exit status make[3]: *** [dbus-test] Error 1 make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git' make: *** [all] Error 2 and cg_create referenced by libsystemd-login.so like below $ grep cg_create src/login/ -r Binary file src/login/systemd_logind-logind-session.o matches Binary file src/login/systemd_logind-logind-user.o matches But these files are not linked into libsystemd-login, but only into logind (the daemon)... Yeah, just found that from Makefile.am, it's weird why the above error happen. -- Thanks, Chengwei Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'
On Wed, Sep 11, 2013 at 02:09:58PM +0200, Kay Sievers wrote: On Wed, Sep 11, 2013 at 1:27 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote: On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote: On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote: Hmm, can you elaborate on this one? libsystemd-login should be mostly This error occurs while building dbus with systemd support like below $ make make all-recursive make[1]: Entering directory `/home/chengwei/Upstream/dbus.git' Making all in dbus make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' make all-am make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus' CCLD dbus-test /usr/lib/libsystemd-login.so: undefined reference to `cg_create' collect2: ld returned 1 exit status make[3]: *** [dbus-test] Error 1 make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git' make: *** [all] Error 2 and cg_create referenced by libsystemd-login.so like below $ grep cg_create src/login/ -r Binary file src/login/systemd_logind-logind-session.o matches Binary file src/login/systemd_logind-logind-user.o matches But these files are not linked into libsystemd-login, but only into logind (the daemon)... Does this print something when executed in the build tree? $ nm -D .libs/libsystemd-login.so | grep cg $ nm -D /usr/lib/libsystemd-login.so | grep cg U tcgetattr Seems irrelative with the problem. -- Thanks, Chengwei Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] implies MemoryAccounting=true
On 09/11/2013 08:07 PM, Lennart Poettering wrote: On Wed, 11.09.13 09:18, Gao feng (gaof...@cn.fujitsu.com) wrote: The SYSTEMD.CGROUP(5) said if MemoryLimit=bytes is set for unit, it implies MemeoryAccounting=true for this unit. But seems systemd didn't implement this hint. CPUShares BlockIO have the same problem, this is a shortage? patch needed? The logic for this is in src/core/cgroup.c's cgroup_context_get_mask() call, which will determine to which cgroup controllers to add a unit to. Note that setting MemoryLimit= will not actually propagate to the boolean exposed in MemoryAccounting=, it will just have the same effect as if it was set... Maybe we should also report MemoryAccounting=yes in cgroup_context_dump if we set MemoryLimit. What I don't really like about this is that we allow MemoryLimit to be altered dynamically, which would then need to influence MemoryAccounting= dynamically too. WHich means that we would have to shadow that field so that we can revert to the originally configured value. Also, it would have very weird effects if people then try to dynamically unset MemoryAccounting which would either possibly be a NOP or would have the effect of resseting MemoryLimit... If you follow what I mean. make sense, thanks for your explanation :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie wrote: I only just rejigged things for the last time this flipped around and now sysctl has decided to buck the trend of the other tools and follow a later file has priority? I think consistency is good here (even if conceptually, a later file overriding an earlier one feels better. Yes, and later-override-earlier is by far the bigger trend. :) The order was previously fixed such that earlier files win for several tools binfmt, tmpfiles modules-load Oh, what a mess. Quite a few man pages described pretty much the opposite of what is done, not only in that file this patch fixed. I now hopefully fixed all of the man pages to describe what the code does. Now we have: binfmt - the last entry wins, people are allowed to overwrite earlier stuff tmpfiles - the first entry wins; uniqueness required, everything else an error sysctl - the last entry wins, people are allowed overwrite earlier stuff presets - the first entry wins, the search just stops there modules-load - there is no order, it's just a set of names that gets applied There is no strictly consistent behavior between the different tools, and I think for good reason, the do different things, some assign values, some can't merge entries and require uniqueness, soem are just lists; all seem to have their reason to do it in the way that makes the most sense. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 04:14:24AM +0200, Kay Sievers wrote: On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie wrote: I only just rejigged things for the last time this flipped around and now sysctl has decided to buck the trend of the other tools and follow a later file has priority? I think consistency is good here (even if conceptually, a later file overriding an earlier one feels better. Yes, and later-override-earlier is by far the bigger trend. :) The order was previously fixed such that earlier files win for several tools binfmt, tmpfiles modules-load Oh, what a mess. Quite a few man pages described pretty much the opposite of what is done, not only in that file this patch fixed. I now hopefully fixed all of the man pages to describe what the code does. Now we have: binfmt - the last entry wins, people are allowed to overwrite earlier stuff tmpfiles - the first entry wins; uniqueness required, everything else an error sysctl - the last entry wins, people are allowed overwrite earlier stuff presets - the first entry wins, the search just stops there modules-load - there is no order, it's just a set of names that gets applied Hm, and .service and service.d/*.conf? I think last entry wins also. There is no strictly consistent behavior between the different tools, and I think for good reason, the do different things, some assign values, some can't merge entries and require uniqueness, soem are just lists; all seem to have their reason to do it in the way that makes the most sense. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 4:49 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Sep 12, 2013 at 04:14:24AM +0200, Kay Sievers wrote: On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie wrote: I only just rejigged things for the last time this flipped around and now sysctl has decided to buck the trend of the other tools and follow a later file has priority? I think consistency is good here (even if conceptually, a later file overriding an earlier one feels better. Yes, and later-override-earlier is by far the bigger trend. :) The order was previously fixed such that earlier files win for several tools binfmt, tmpfiles modules-load Oh, what a mess. Quite a few man pages described pretty much the opposite of what is done, not only in that file this patch fixed. I now hopefully fixed all of the man pages to describe what the code does. Now we have: binfmt - the last entry wins, people are allowed to overwrite earlier stuff tmpfiles - the first entry wins; uniqueness required, everything else an error sysctl - the last entry wins, people are allowed overwrite earlier stuff presets - the first entry wins, the search just stops there modules-load - there is no order, it's just a set of names that gets applied Hm, and .service and service.d/*.conf? I think last entry wins also. Right, that's also assignment-style, allows overwriting, like sysctl or shell variable, and the last one wins. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
