Re: [systemd-devel] Hackfest at Linux Plumbers Conference?
On 09/10/2013 06:46 AM, David Strauss wrote: On Wed, Aug 14, 2013 at 11:11 PM, Harald Hoyer harald.ho...@gmail.com wrote: Linux Foundation is looking into it. Right now they don't have space, but they are trying to find something for us. We should know early/mid next week. Any word on this? They reserved the room Imperial 11 for us (takes up to 95 people :-)). If you are attending the systemd Hackfest and if you are not registered to LinuxCon/CloudOpen, please contact me!! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
Hi, On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: I was choosing the interface described above since according to my observation this seems closest to how interfaces were constructed in this area before. I am open to suggestions though for better interfaces if someone comes up with one. Additionally I was not sure whether the no option is practically useful but since it doesn't seem completely out of place for me I included it for completeness. Hmm, if I get this right, then you'd set this for your images unconditionally? In that case it probably shouldn't be a kernel cmdline parameter but rather some kind of configuration file setting somewhere... Yes, that's what I had in mind first but then didn't find something similar in related code and thought the idea might not be the style it is typically done in systemd code. But now that you say that's the way you would go I am happy to get back to this idea. We generally try to empty out the kernel cmdline, so that it doesn't need any params by default, and is solely used for one-time overrides by the admin. Sounds perfectly resonable to me. Before systemd, was there any way to trigger this behaviour via configuration (be it kernel cmdline or configuration file)? Well, in our old proprietary boot scripts we had that hard coded but with the introduction of systemd I wanted to move away from this hard coded stuff. One possibility might be to add a new extended mount option (i.e. as listed in fstab's fourth column) that systemd would interpret. i.e. x-systemd.yesfsck or so. That sounds much nicer, since it would be naturally persistent, and per-mount point. Yes, that sounds good to me. I am just not sure how the proper information flow should be implemented in systemd. If my understanding of your idea is correct the setting would go into the mount service file and thus could be read by the code for the mount service. The mount service needed to forward this information to the automatically created fsck service though. Is there a way to forward this information or how would the fsck service get access to that? If you had a pointer to some documentation how to do this that would be great. Alternatively if you know of another service that is doing similar information forwarding a pointer to that one would be also good, such that I could implement this in a similar fashion. Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl -x considered harmful
On Tue, Sep 10, 2013 at 02:34:41AM +0200, Lennart Poettering wrote: On Fri, 06.09.13 14:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Hi, I think we should remove all recommendations to use -x for bug reports. Generic explanations are not useful one you know the bug messages, and those addtional like make the text much harder to read. Users may continue to use -x while reading logs, of course. For bug *reports* adding -x certainly doesn't make sense. Do we have documented that somewhere? I've seen it requested on bug reports, I think, but not in any official documentation. I'll add a note to the journalctl man page not to use it in bug reports. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tuesday 2013-09-10 02:41, Lennart Poettering wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: One possibility might be to add a new extended mount option (i.e. as listed in fstab's fourth column) that systemd would interpret. i.e. x-systemd.yesfsck or so. That sounds much nicer, since it would be naturally persistent, and per-mount point. Opinions? Loosely related: Mount options are a problem with mount helpers. If you have, for example, a FUSE mount marked with nofail so that your boot phase does not get interrupted if it fails, attempting to manually mount it later on always fails, because the FUSE program knows nothing about the systemd-specific nofail or x-*. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, Sep 10, 2013 at 01:40:32PM +0200, Jan Engelhardt wrote: On Tuesday 2013-09-10 02:41, Lennart Poettering wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: One possibility might be to add a new extended mount option (i.e. as listed in fstab's fourth column) that systemd would interpret. i.e. x-systemd.yesfsck or so. That sounds much nicer, since it would be naturally persistent, and per-mount point. Opinions? Loosely related: Mount options are a problem with mount helpers. If you have, for example, a FUSE mount marked with nofail so that your boot phase does not get interrupted if it fails, attempting to manually mount it later on always fails, because the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, Sep 10, 2013 at 1:52 PM, Dave Reisner d...@falconindy.com wrote: On Tue, Sep 10, 2013 at 01:40:32PM +0200, Jan Engelhardt wrote: On Tuesday 2013-09-10 02:41, Lennart Poettering wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: One possibility might be to add a new extended mount option (i.e. as listed in fstab's fourth column) that systemd would interpret. i.e. x-systemd.yesfsck or so. That sounds much nicer, since it would be naturally persistent, and per-mount point. Opinions? Loosely related: Mount options are a problem with mount helpers. If you have, for example, a FUSE mount marked with nofail so that your boot phase does not get interrupted if it fails, attempting to manually mount it later on always fails, because the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. Right, and nofail and x-* are proper mount(8) options, and are not systemd specific at all. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. If it were so that mount stripped them, I would not be reporting it, would I. Or maybe that is a feature of a future util-linux? # grep /mnt /etc/fstab /srv/www /mnt fuse.bindfs auto,nofail,group=company,perms=g+rw,create-for-group=www,create-with-perms=g+r:go-w 0 0 # mount /mnt fuse: unknown option `nofail' # rpm -q util-linux util-linux-2.21.2-10.2.1.x86_64 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Remove device and its relatives when action is offlined
On Mon, 9 Sep 2013 23:45:01 +0200,
Kay Sievers k...@vrfy.org wrote:
On Mon, Sep 9, 2013 at 11:23 PM, MUNEDA Takahiro
muneda.takah...@jp.fujitsu.com wrote:
Ok, I found out another problem.
Even if I have a following udev rules and 'remove' event happens, no
systemd service will be called.
ACTION==add|remove, TAG+=systemd, ENV{SYSTEMD_WANTS}=muneda@.service
My final goal is to invoke my systemd service which calls programs
that needs a bit long time when I do add/online or remove/offline my
device. udev provided this feature before it's merged into systemd.
Udev still does all what did before systemd. It was never really able
to run or start long-running tasks. Udev can only reliably handle
synchronously started and very short-living programs, and that was
always the case.
Ahh, you are correct.
But, we used to use a 'trick' to call long-running task by adding ''
to kill the relationship between udev and task. However, current
implementation does not allow to do that, because even if we call a
such task by adding '', all processes are under same cgroup and all
process will be killed.
So, my understanding is that we don't have such tricks anymore.
My previous patch let 'offline' event to remove device information
from systemd (probably, remove from udev database?), but systemd does
not call service as I expected.
Systemd provides service *activation*, services and jobs can lazily
get started when a device appears. It's usually the responsibility of
the service itself to handle more events than the first one that
activated it.
Systemd is not really meant to be generic a job engine for device events.
Things that run for an unpredictable amount of time should probably be
handled by a proper running service on its own, activated by systemd
and listening to udev events, and not just plugged into udev events,
or run as a one-shot systemd service.
Thank you for the advise.
I wanted to use pre-existing tools as much as possible, but it seems
it doesn't exist. So I'll check other way.
Thanks,
Takahiro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Remove device and its relatives when action is offlined
On Tue, 10 Sep 2013 02:25:19 +0200,
Lennart Poettering lenn...@poettering.net wrote:
On Mon, 09.09.13 17:23, MUNEDA Takahiro (muneda.takah...@jp.fujitsu.com) wrote:
Ok, I found out another problem.
Even if I have a following udev rules and 'remove' event happens, no
systemd service will be called.
ACTION==add|remove, TAG+=systemd, ENV{SYSTEMD_WANTS}=muneda@.service
My final goal is to invoke my systemd service which calls programs
that needs a bit long time when I do add/online or remove/offline my
device. udev provided this feature before it's merged into systemd.
My previous patch let 'offline' event to remove device information
from systemd (probably, remove from udev database?), but systemd does
not call service as I expected.
systemd only cares for add and remove events, nothing else, and will do
so only for devices tagged with the systemd udev tag. It will
activate devices when add is sent, and deactivate them when remove
is sent. You can pull in arbitrary services via SYSTEMD_WANTS (which
causes a Wants type dependency from the device unit be created to the
specified service unit. And you can bind units back to the device unit
via BindsTo= in the service unit.
Yeah, this is an answer what I wanted to know. I mis-understood what
'SYSTEMD_WANTS' means.
The udev rule above will not work, as you are can only add dependencies
to to instantiated unit names. Try
ENV{SYSTEMD_WANTS}=muneda@%k.service or suchlike, instead. Also,
My bad. I made a mistake while copy and paste.
ACTION=remove doesn't make much sense for this...
Yes, it makes sense to me with your explanation.
Thanks,
Takahiro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Remove device and its relatives when action is offlined
On Tue, Sep 10, 2013 at 3:14 PM, MUNEDA Takahiro muneda.takah...@jp.fujitsu.com wrote: Udev still does all what did before systemd. It was never really able to run or start long-running tasks. Udev can only reliably handle synchronously started and very short-living programs, and that was always the case. Ahh, you are correct. But, we used to use a 'trick' to call long-running task by adding '' to kill the relationship between udev and task. Ah, you mean you wrapped it in /bin/sh and added there? Udev never supported any sort of detaching. It's really fragile to do that, because unlike systemd, udev will fork the same thing over and over with every event, which can easily cause problems. However, current implementation does not allow to do that, because even if we call a such task by adding '', all processes are under same cgroup and all process will be killed. So, my understanding is that we don't have such tricks anymore. If you need to do that, which we really do not recommend to ever do, you need to move out of udev's own cgroup, otherwise udev will rightfully clean up the mess you left behind. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, 10.09.13 12:23, Robert Schiele (rschi...@gmail.com) wrote: Hi, On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote: I was choosing the interface described above since according to my observation this seems closest to how interfaces were constructed in this area before. I am open to suggestions though for better interfaces if someone comes up with one. Additionally I was not sure whether the no option is practically useful but since it doesn't seem completely out of place for me I included it for completeness. Hmm, if I get this right, then you'd set this for your images unconditionally? In that case it probably shouldn't be a kernel cmdline parameter but rather some kind of configuration file setting somewhere... Yes, that's what I had in mind first but then didn't find something similar in related code and thought the idea might not be the style it is typically done in systemd code. But now that you say that's the way you would go I am happy to get back to this idea. We generally try to empty out the kernel cmdline, so that it doesn't need any params by default, and is solely used for one-time overrides by the admin. Sounds perfectly resonable to me. Before systemd, was there any way to trigger this behaviour via configuration (be it kernel cmdline or configuration file)? Well, in our old proprietary boot scripts we had that hard coded but with the introduction of systemd I wanted to move away from this hard coded stuff. One possibility might be to add a new extended mount option (i.e. as listed in fstab's fourth column) that systemd would interpret. i.e. x-systemd.yesfsck or so. That sounds much nicer, since it would be naturally persistent, and per-mount point. Yes, that sounds good to me. I am just not sure how the proper information flow should be implemented in systemd. If my understanding of your idea is correct the setting would go into the mount service file and thus could be read by the code for the mount service. The mount service needed to forward this information to the automatically created fsck service though. Is there a way to forward this information or how would the fsck service get access to that? Well, there is a way to pass that information on, but it is admittedly not pretty. Look how the fsck passno is currently passed fromt he mount point to the fsck. See mount_add_device_links() in src/core/mount.c. There we copy the passno into a newly loaded fsck unit. And we we probablöy should have a new bool for the fsckyes thingy here that is copied over at the same place... 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] service: remove pidfile after exit of a service
On Wed, 28.08.13 19:27, Lukas Nykryn (lnyk...@redhat.com) wrote: Applied! Thanks! (Added a longer comment though) --- TODO | 2 -- src/core/service.c | 4 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/TODO b/TODO index fe305ec..3527970 100644 --- a/TODO +++ b/TODO @@ -60,8 +60,6 @@ Features: * better error message if you run systemctl without systemd running -* unlink PID files of units after exit - * tiny tool that saves/restores backlight * systemctl status output should should include list of triggering units and their status diff --git a/src/core/service.c b/src/core/service.c index 4070fd7..916821f 100644 --- a/src/core/service.c +++ b/src/core/service.c @@ -1957,6 +1957,10 @@ static void service_enter_dead(Service *s, ServiceResult f, bool allow_restart) /* we want fresh tmpdirs in case service is started again immediately */ exec_context_tmp_dirs_done(s-exec_context); +/* try to delete pidfile*/ +if (s-pid_file) +unlink_noerrno(s-pid_file); + return; fail: 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] blkio bandwidth: don't clean up all of entries in blockio_device_bandwidths list
On Fri, 30.08.13 10:56, Gao feng (gaof...@cn.fujitsu.com) wrote:
if we get BlockIOReadBandwidth=, we should only remove the
read-bandwidth-entries in blockio_device_bandwidths list.
Thanks! Applied, though with one change:
+read = streq(BlockIOReadBandwidth, lvalue);
+
if (isempty(rvalue)) {
-while (c-blockio_device_bandwidths)
-cgroup_context_free_blockio_device_bandwidth(c,
c-blockio_device_bandwidths);
+CGroupBlockIODeviceBandwidth *next;
+
+LIST_FOREACH_SAFE (device_bandwidths, b, next,
c-blockio_device_bandwidths) {
+if (b-read == read) {
+LIST_REMOVE(CGroupBlockIODeviceBandwidth,
device_bandwidths, c-blockio_device_bandwidths, b);
+free(b-path);
+free(b);
I replaced the three previous lines with an invocation of
cgroup_context_free_blockio_device_bandwidth() again.
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 2/3] cgroup: setup BlockIORead/WriteBandwidth in bus_cgroup_set_property
On Fri, 30.08.13 10:56, Gao feng (gaof...@cn.fujitsu.com) wrote:
This patch adds the support for setting up BlockIORead/WriteBandwidth
in bus_cgroup_set_property.
Thanks!
Applied!
---
src/core/dbus-cgroup.c | 101
+
1 file changed, 101 insertions(+)
diff --git a/src/core/dbus-cgroup.c b/src/core/dbus-cgroup.c
index c0e2371..4ef203d 100644
--- a/src/core/dbus-cgroup.c
+++ b/src/core/dbus-cgroup.c
@@ -307,6 +307,107 @@ int bus_cgroup_set_property(
}
return 1;
+
+} else if (streq(name, BlockIOReadBandwidth) || streq(name,
BlockIOWriteBandwidth)) {
+DBusMessageIter sub;
+unsigned n = 0;
+bool read = true;
+
+if (streq(name, BlockIOWriteBandwidth))
+read = false;
+
+if (dbus_message_iter_get_arg_type(i) != DBUS_TYPE_ARRAY ||
+dbus_message_iter_get_element_type(i) !=
DBUS_TYPE_STRUCT)
+return -EINVAL;
+
+dbus_message_iter_recurse(i, sub);
+while (dbus_message_iter_get_arg_type(sub) ==
DBUS_TYPE_STRUCT) {
+DBusMessageIter sub2;
+const char *path;
+uint64_t u64;
+CGroupBlockIODeviceBandwidth *a;
+
+dbus_message_iter_recurse(sub, sub2);
+
+if (bus_iter_get_basic_and_next(sub2,
DBUS_TYPE_STRING, path, true) 0 ||
+bus_iter_get_basic_and_next(sub2,
DBUS_TYPE_UINT64, u64, false) 0)
+return -EINVAL;
+
+if (mode != UNIT_CHECK) {
+CGroupBlockIODeviceBandwidth *b;
+bool exist = false;
+
+LIST_FOREACH(device_bandwidths, b,
c-blockio_device_bandwidths) {
+if (streq(path, b-path) read ==
b-read) {
+a = b;
+exist = true;
+break;
+}
+}
+
+if (!exist) {
+a =
new0(CGroupBlockIODeviceBandwidth, 1);
+if (!a)
+return -ENOMEM;
+
+a-read = read;
+a-path = strdup(path);
+if (!a-path) {
+free(a);
+return -ENOMEM;
+}
+}
+
+a-bandwidth = u64;
+
+if (!exist)
+
LIST_PREPEND(CGroupBlockIODeviceBandwidth, device_bandwidths,
+
c-blockio_device_bandwidths, a);
+}
+
+n++;
+dbus_message_iter_next(sub);
+}
+
+if (mode != UNIT_CHECK) {
+_cleanup_free_ char *buf = NULL;
+_cleanup_fclose_ FILE *f = NULL;
+CGroupBlockIODeviceBandwidth *a;
+CGroupBlockIODeviceBandwidth *next;
+size_t size = 0;
+
+if (n == 0) {
+LIST_FOREACH_SAFE(device_bandwidths, a,
next, c-blockio_device_bandwidths) {
+if (a-read == read) {
+
LIST_REMOVE(CGroupBlockIODeviceBandwidth, device_bandwidths,
c-blockio_device_bandwidths, a);
+free(a-path);
+free(a);
+}
+}
+}
+
+f = open_memstream(buf, size);
+if (!f)
+return -ENOMEM;
+
+if (read) {
+fputs(BlockIOReadBandwidth=\n, f);
+LIST_FOREACH(device_bandwidths, a,
c-blockio_device_bandwidths)
+if (a-read)
+fprintf(f,
BlockIOReadBandwidth=%s % PRIu64 \n, a-path, a-bandwidth);
+} else {
+
Re: [systemd-devel] [PATCH 3/3] systemcl: add support for setting BlockIORead/WriteBandwidth for unit
On Fri, 30.08.13 10:56, Gao feng (gaof...@cn.fujitsu.com) wrote: This patch allows user to set up BlockIOReadBandwidth and BlockIOWriteBandwidth for unit through systemctl. Such as systemctl set-property sshd.service BlockIOReadBandwidth=/dev/sda 10 systemctl set-property sshd.service BlockIOWriteBandwidth=/dev/sda 20 Applied, with one change though. I replaced safe_atou64() by parse_bytes() so that people can specifiy values like 5M or so instead of 5242880, the same way as we allow this in unit files. Thanks! 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] 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.
Also, can those new functions replace normal ellipsize and ellipsize_mem,
so that we have support everywhere?
e = new0(char, new_length*4 old_length ? new_length*4 : old_length);
→ we have a min macro
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,
../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);
^
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)
...
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.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] systemcl: add support for setting BlockIODeviceWeight for unit
On Tue, 27.08.13 13:36, Gao feng (gaof...@cn.fujitsu.com) wrote: This patch allows user to set up BlockIODeviceWeight for unit through systemctl. Such as 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
Re: [systemd-devel] [PATCH 2/7] mount: don't pull in network.target, just order after it
On Fri, 23.08.13 15:09, Tom Gundersen (t...@jklm.no) wrote:
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index c7d29b0..7838e60 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -476,7 +476,7 @@ static int mount_add_default_dependencies(Mount *m) {
}
if (online) {
-r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_WANTS,
UNIT_AFTER, online, NULL, true);
+r = unit_add_dependency_by_name(UNIT(m), UNIT_AFTER, online,
NULL, true);
if (r 0)
return r;
}
Hmm, no. network-online.target is supposed to contain a unit like
NetworkManager-wait-online.service, i.e. awful scripts that just wait,
that should be kept out of the boot if possible, and should only be
pulled in if some code really needs it, like NFS shares do, for example.
See systemd.special(7) for an explanation:
snip
Units that strictly require a configured network connection
should pull in network-online.target (via a Wants= type dependency)
and
order themselves after it. This
target unit is intended to pull in a service that delays
further execution until the network is sufficiently set
up. What precisely this requires is left to the
implementation of the network managing service.
Note the distinction between this unit and
network.target. This unit is an active unit (i.e. pulled in
by the consumer rather than the provider of this
functionality) and pulls in a service which possibly adds
substantial delays to further execution. In contrast,
network.target is a passive unit (i.e. pulled in by
the provider of the functionality, rather than the consumer)
that usually does not delay execution much. Usually,
network.target is part of the boot of most
systems, while network-online.target is not, except when at
least one unit requires it. Also see Running Services After
the Network is up[1] for more information.
All mount units for remote network file systems automatically
pull in this unit, and order themselves after it. Note that
networking daemons that simply provide
functionality to other hosts generally don't need to pull
this in.
/snip
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] util, utf8: new wellipsize and wellipsize_mem that take into account multi-byte characters
On Monday 2013-09-09 01:17, Shawn wrote: ping Lennart was away in (what seems to be) South America, systemd progress is resuming now. :) This version counts all multibyte characters as 1 width, not taking into account double width cjk characters and zerowidth characters ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PrivateNetwork=true conflicts with Type=notify
Hi all, 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. On a side node: The private network systemd sets up for such services enables IPv6 even if this is disabled on the host using net.ipv6.conf.all.disable_ipv6=1. I cannot think of a scenario where this leads to trouble though. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com ___ 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 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 passive, why would it need to change labels? What's the missing link here precisely? --- Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.am b/Makefile.am index 5654ad3..dc5170a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3870,6 +3870,7 @@ libsystemd_login_la_LDFLAGS = \ -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym libsystemd_login_la_LIBADD = \ + libsystemd-label.la \ libsystemd-shared.la \ libsystemd-daemon-internal.la \ $(RT_LIBS) 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] Remove device and its relatives when action is offlined
On Tue, 10 Sep 2013 15:36:26 +0200, Kay Sievers k...@vrfy.org wrote: Udev still does all what did before systemd. It was never really able to run or start long-running tasks. Udev can only reliably handle synchronously started and very short-living programs, and that was always the case. Ahh, you are correct. But, we used to use a 'trick' to call long-running task by adding '' to kill the relationship between udev and task. Ah, you mean you wrapped it in /bin/sh and added there? Yeah, that's the easiest way to detect the uevent and call my own programs for the event. Udev never supported any sort of detaching. It's really fragile to do that, because unlike systemd, udev will fork the same thing over and over with every event, which can easily cause problems. Understand. My device is a bit uncommon so it has a specific sysfs path. Then I can make a strict rule jsut for device not to detect events for other devices. However, current implementation does not allow to do that, because even if we call a such task by adding '', all processes are under same cgroup and all process will be killed. So, my understanding is that we don't have such tricks anymore. If you need to do that, which we really do not recommend to ever do, you need to move out of udev's own cgroup, otherwise udev will rightfully clean up the mess you left behind. :) I would like to choose more generic way. My first idea was to invoke my own service from udev rules and escape from the udev's cgroup, but it's not a good way. I'm thinking to have my own daemon to listen uevent directly or get a notification from udev rules which finishes shortly. Thanks, Takahiro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: one more example in tmpfiles.d
On Thu, 22.08.13 14:47, Lukas Nykryn (lnyk...@redhat.com) wrote: Thanks! Applied! --- man/tmpfiles.d.xml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml index 6a2193d..30e1314 100644 --- a/man/tmpfiles.d.xml +++ b/man/tmpfiles.d.xml @@ -322,6 +322,13 @@ L/tmp/foobar ---- /dev/null/programlisting programlistingd /var/run/screens 1777 root root 10d d /var/run/uscreens 0755 root root 10d12h/programlisting /example +example +title/etc/tmpfiles.d/abrt.conf example/title +paracommandabrt/command needs a directory created at boot with specific mode and ownership and its content should be preserved./para + +programlistingd /var/tmp/abrt 0755 abrt abrt +x /var/tmp/abrt/*/programlisting +/example /refsect1 refsect1 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 2/7] mount: don't pull in network.target, just order after it
On Tue, Sep 10, 2013 at 6:40 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 23.08.13 15:09, Tom Gundersen (t...@jklm.no) wrote:
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
.
diff --git a/src/core/mount.c b/src/core/mount.c
index c7d29b0..7838e60 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -476,7 +476,7 @@ static int mount_add_default_dependencies(Mount *m) {
}
if (online) {
-r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_WANTS,
UNIT_AFTER, online, NULL, true);
+r = unit_add_dependency_by_name(UNIT(m), UNIT_AFTER,
online, NULL, true);
if (r 0)
return r;
}
Hmm, no.
You are right. I dropped the patch.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v2] mount: improve DefaultDependencies and use in generator
On Fri, 23.08.13 15:09, Tom Gundersen (t...@jklm.no) wrote: This moves reduces redundancy between systemd core and the fstab-generator, by improving and relying on the DefaultDependencies logic. Commented on two patches. The others look good, please commit those! Functional changes: * Mount units will no longer Want network.target, only order themselves After it. * Both monut and swap units will now be WantedBy their backing device, unless they have the option noauto. * Mount units in the real instance representing mounts that are known to be mounted in the initrd (i.e., /usr and anything marked with x-initrd.mount) will no longer conflict with unmount.target. (and yeah, the gpt stuff should rely on the built-in logic too, I totally agree!) 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, Sep 10, 2013 at 6:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 23.08.13 15:51, Colin Walters (walt...@verbum.org) wrote: First, thanks for working on this, most of these patches look sane to me. On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote: +if (path_equal(m-where, /) || +path_equal(m-where, /usr)) +return false; 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). 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. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH resend] getty-generator: Enable getty on all active serial consoles.
On Tue, Sep 10, 2013 at 8:41 AM, Lennart Poettering
lenn...@poettering.netwrote:
On Wed, 28.08.13 13:12, Michael Marineau (michael.marin...@coreos.com)
wrote:
This enables a getty on active kernel consoles even when they are not
the last one specified on the kernel command line and mapped to
/dev/console. Now the order console=ttyS0 console=tty0 works in
addition to console=tty0 console=ttyS0.
Hmm, so when we added the generator initially we though about this and
came to the conclusion that it might be risky to spawn gettys on all
configured console outputs and we should limit the magic logic to the
primary console only. The kernel already makes a distinction between the
primary console, and all others (the latter only receive logs, but you
cannot read from them via /dev/console iirc), and so we propagated that
distinction into systemd, too.
I can totally see that this is confusing though, as nobody remembers the
right ordering...
And in my case there isn't a truly correct ordering either because I'm
creating filesystem images that need to boot on a wide variety of platforms
including QEMU which gives the user a VGA console most of the time but a
serial console when using the -nographic option. The bootloader doesn't
know the difference.
Kay, do you have an opinion about this?
---
src/getty-generator/getty-generator.c | 37
++-
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/src/getty-generator/getty-generator.c
b/src/getty-generator/getty-generator.c
index 4b7a60a..6c93806 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -122,33 +122,42 @@ int main(int argc, char *argv[]) {
}
if (read_one_line_file(/sys/class/tty/console/active,
active) = 0) {
-const char *tty;
-
-tty = strrchr(active, ' ');
-if (tty)
-tty ++;
-else
-tty = active;
-
-/* Automatically add in a serial getty on the kernel
- * console */
-if (isempty(tty) || tty_is_vc(tty))
-free(active);
-else {
+char *w, *state;
+size_t l;
+
+/* Automatically add in a serial getty on all active
+ * kernel consoles */
+FOREACH_WORD(w, l, active, state) {
+char *tty;
int k;
+tty = strndup(w, l);
+if (!tty) {
+log_oom();
+free(active);
+r = EXIT_FAILURE;
+goto finish;
+}
+
+if (isempty(tty) || tty_is_vc(tty)) {
+free(tty);
+continue;
+}
+
/* We assume that gettys on virtual terminals
are
* started via manual configuration and do this
magic
* only for non-VC terminals. */
k = add_serial_getty(tty);
-free(active);
if (k 0) {
+free(tty);
+free(active);
r = EXIT_FAILURE;
goto finish;
}
}
+free(active);
}
/* Automatically add in a serial getty on the first
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] implies MemoryAccounting=true
On Mon, 26.08.13 11:19, Gao feng (gaof...@cn.fujitsu.com) wrote: Hi 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... 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
'Twas brillig, and Tom Gundersen at 10/09/13 18:54 did gyre and gimble: 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. Yeah, I agree with Tom here. This question seems to have come up about two or three on the list in the last six months or so with different paths etc. Something that took note at startup and maintained that state as y ou described sounds good to me. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ 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 Fri, 23.08.13 15:51, Colin Walters (walt...@verbum.org) wrote: First, thanks for working on this, most of these patches look sane to me. On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote: +if (path_equal(m-where, /) || +path_equal(m-where, /usr)) +return false; 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... 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() or so? It should probably be changed to use NULSTR_FOREACH or so for the list, so that it is easy to add more entries when we need that... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix build without blkid
On Mon, 26.08.13 13:06, Chengwei Yang (chengwei.y...@intel.com) wrote: build systemd-gpt-auto-generator only if have blkid, otherwise, it will fail. Tahnks! Already fixed now, with a pretty much identical patch from Marcel. --- Makefile.am |2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index fd38e82..5654ad3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1708,6 +1708,7 @@ bin_PROGRAMS += \ bootctl endif +if HAVE_BLKID # -- systemgenerator_PROGRAMS += \ systemd-gpt-auto-generator @@ -1725,6 +1726,7 @@ systemd_gpt_auto_generator_LDADD = \ systemd_gpt_auto_generator_CFLAGS = \ $(AM_CFLAGS) \ $(BLKID_CFLAGS) +endif # -- systemd_rc_local_generator_SOURCES = \ 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 resend] getty-generator: Enable getty on all active serial consoles.
On Wed, 28.08.13 13:12, Michael Marineau (michael.marin...@coreos.com) wrote:
This enables a getty on active kernel consoles even when they are not
the last one specified on the kernel command line and mapped to
/dev/console. Now the order console=ttyS0 console=tty0 works in
addition to console=tty0 console=ttyS0.
Hmm, so when we added the generator initially we though about this and
came to the conclusion that it might be risky to spawn gettys on all
configured console outputs and we should limit the magic logic to the
primary console only. The kernel already makes a distinction between the
primary console, and all others (the latter only receive logs, but you
cannot read from them via /dev/console iirc), and so we propagated that
distinction into systemd, too.
I can totally see that this is confusing though, as nobody remembers the
right ordering...
Kay, do you have an opinion about this?
---
src/getty-generator/getty-generator.c | 37
++-
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/src/getty-generator/getty-generator.c
b/src/getty-generator/getty-generator.c
index 4b7a60a..6c93806 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -122,33 +122,42 @@ int main(int argc, char *argv[]) {
}
if (read_one_line_file(/sys/class/tty/console/active, active) =
0) {
-const char *tty;
-
-tty = strrchr(active, ' ');
-if (tty)
-tty ++;
-else
-tty = active;
-
-/* Automatically add in a serial getty on the kernel
- * console */
-if (isempty(tty) || tty_is_vc(tty))
-free(active);
-else {
+char *w, *state;
+size_t l;
+
+/* Automatically add in a serial getty on all active
+ * kernel consoles */
+FOREACH_WORD(w, l, active, state) {
+char *tty;
int k;
+tty = strndup(w, l);
+if (!tty) {
+log_oom();
+free(active);
+r = EXIT_FAILURE;
+goto finish;
+}
+
+if (isempty(tty) || tty_is_vc(tty)) {
+free(tty);
+continue;
+}
+
/* We assume that gettys on virtual terminals are
* started via manual configuration and do this magic
* only for non-VC terminals. */
k = add_serial_getty(tty);
-free(active);
if (k 0) {
+free(tty);
+free(active);
r = EXIT_FAILURE;
goto finish;
}
}
+free(active);
}
/* Automatically add in a serial getty on the first
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 3/3] systemctl: show BlockIODeviceWeight for unit
On Tue, 27.08.13 13:36, Gao feng (gaof...@cn.fujitsu.com) wrote:
We can use systemctl show unitname to show the BlockIODeviceWeight
of unit.
Applied! Thanks!
---
src/systemctl/systemctl.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index ff29b0f..4ea301a 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3315,6 +3315,24 @@ static int print_property(const char *name,
DBusMessageIter *iter) {
}
return 0;
+} else if (dbus_message_iter_get_element_type(iter) ==
DBUS_TYPE_STRUCT streq(name, BlockIODeviceWeight)) {
+DBusMessageIter sub, sub2;
+
+dbus_message_iter_recurse(iter, sub);
+while (dbus_message_iter_get_arg_type(sub) ==
DBUS_TYPE_STRUCT) {
+const char *path;
+uint64_t weight;
+
+dbus_message_iter_recurse(sub, sub2);
+
+if (bus_iter_get_basic_and_next(sub2,
DBUS_TYPE_STRING, path, true) = 0
+bus_iter_get_basic_and_next(sub2,
DBUS_TYPE_UINT64, weight, false) = 0)
+printf(%s=%s % PRIu64 \n, name,
strna(path), weight);
+
+dbus_message_iter_next(sub);
+}
+return 0;
+
} else if (dbus_message_iter_get_element_type(iter) ==
DBUS_TYPE_STRUCT (streq(name, BlockIOReadBandwidth) || streq(name,
BlockIOWriteBandwidth))) {
DBusMessageIter sub, sub2;
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] man: wording and grammar updates
On Sun, 25.08.13 09:01, Jan Engelhardt (jeng...@inai.de) wrote:
Thanks!
Applied!
This includes regularly-submitted corrections to comma setting and
orthographical mishaps that appeared in man/ in recent commits.
In this particular commit:
- the usual comma fixes
- expand contractions (this is prose)
---
man/journalctl.xml | 2 +-
man/sd_journal_get_cursor.xml | 2 +-
man/sd_journal_get_fd.xml | 14 +++---
man/sd_notify.xml | 2 +-
man/shutdown.xml | 4 ++--
man/systemd-backli...@.service.xml | 4 ++--
man/systemd-cgls.xml | 2 +-
man/systemd-efi-boot-generator.xml | 4 ++--
man/systemd-nspawn.xml | 2 +-
man/systemd.exec.xml | 9 -
man/systemd.journal-fields.xml | 2 +-
man/systemd.mount.xml | 2 +-
man/systemd.service.xml| 4 ++--
man/systemd.special.xml| 2 +-
man/systemd.time.xml | 2 +-
man/systemd.xml| 2 +-
man/telinit.xml| 2 +-
man/timedatectl.xml| 2 +-
man/tmpfiles.d.xml | 12 ++--
19 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/man/journalctl.xml b/man/journalctl.xml
index 8680e53..e7097d6 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -281,7 +281,7 @@
optionshort-monotonic/option
/term
listitem
-parais very similar
+parais very
similar,
but shows monotonic
timestamps instead of
wallclock timestamps.
diff --git a/man/sd_journal_get_cursor.xml b/man/sd_journal_get_cursor.xml
index 861927e..4cee7d5 100644
--- a/man/sd_journal_get_cursor.xml
+++ b/man/sd_journal_get_cursor.xml
@@ -120,7 +120,7 @@
returns 0 on success or a negative errno-style error
code. functionsd_journal_test_cursor()/function
returns positive if the current entry matches the
-specified cursor, 0 if it doesn't match the specified
+specified cursor, 0 if it does not match the specified
cursor or a negative errno-style error code on
failure./para
/refsect1
diff --git a/man/sd_journal_get_fd.xml b/man/sd_journal_get_fd.xml
index 1c6f250..c4387b0 100644
--- a/man/sd_journal_get_fd.xml
+++ b/man/sd_journal_get_fd.xml
@@ -232,15 +232,15 @@ else {
constantSD_JOURNAL_APPEND/constant or
constantSD_JOURNAL_INVALIDATE/constant on success or
a negative errno-style error code. If
-constantSD_JOURNAL_NOP/constant is returned the
-journal didn't change since the last invocation. If
-constantSD_JOURNAL_APPEND/constant is returned new
+constantSD_JOURNAL_NOP/constant is returned, the
+journal did not change since the last invocation. If
+constantSD_JOURNAL_APPEND/constant is returned, new
entries have been appended to the end of the
-journal. If constantSD_JOURNAL_INVALIDATE/constant
+journal. If constantSD_JOURNAL_INVALIDATE/constant,
journal files were added or removed (possibly due to
-rotation). In the latter event live-view UIs should
-probably refresh their entire display while in the
-case of constantSD_JOURNAL_APPEND/constant it is
+rotation). In the latter event, live-view UIs should
+probably refresh their entire display, while in the
+case of constantSD_JOURNAL_APPEND/constant, it is
sufficient to simply continue reading at the previous
end of the journal./para
/refsect1
diff --git a/man/sd_notify.xml b/man/sd_notify.xml
index 7d96890..fc0f2f6 100644
--- a/man/sd_notify.xml
+++ b/man/sd_notify.xml
@@ -200,7 +200,7 @@
the status was sent these functions return with a
positive return value. In order to support both, init
systems that implement this scheme and those which
-don't, it is generally recommended to ignore the return
+do not, it is generally recommended to ignore the return
value of this call./para
/refsect1
diff --git a/man/shutdown.xml b/man/shutdown.xml
index af799c6..795fb66 100644
--- a/man/shutdown.xml
+++
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble: On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt jeng...@inai.de wrote: On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. If it were so that mount stripped them, I would not be reporting it, would I. Or maybe that is a feature of a future util-linux? # grep /mnt /etc/fstab /srv/www /mnt fuse.bindfs auto,nofail,group=company,perms=g+rw,create-for-group=www,create-with-perms=g+r:go-w 0 0 # mount /mnt fuse: unknown option `nofail' # rpm -q util-linux util-linux-2.21.2-10.2.1.x86_64 Hm, I thought that feature was part of 2.21... or perhaps your distro is still not using the libmount based mount? I suspect this issue (libmount based mount) as this is what hit us a while back (I think our problem there was not using libmount in nfs-utils rather than mount itself, but my memory is fuzzy and I could be getting this wrong) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] cgroup: setup BlockIODeviceWeight in bus_cgroup_set_property
On Tue, 27.08.13 13:36, Gao feng (gaof...@cn.fujitsu.com) wrote:
This patch adds the support for setting up BlockIODeviceWeight
in bus_cgroup_set_property. most of the codes are copied from
the case that sets up DeviceAllow.
Thanks!
Applied!
---
src/core/dbus-cgroup.c | 85
++
1 file changed, 85 insertions(+)
diff --git a/src/core/dbus-cgroup.c b/src/core/dbus-cgroup.c
index 30c99dd..1555c34 100644
--- a/src/core/dbus-cgroup.c
+++ b/src/core/dbus-cgroup.c
@@ -222,6 +222,91 @@ int bus_cgroup_set_property(
return 1;
+} else if (streq(name, BlockIODeviceWeight)) {
+DBusMessageIter sub;
+unsigned n = 0;
+
+if (dbus_message_iter_get_arg_type(i) != DBUS_TYPE_ARRAY ||
+dbus_message_iter_get_element_type(i) !=
DBUS_TYPE_STRUCT)
+return -EINVAL;
+
+dbus_message_iter_recurse(i, sub);
+while (dbus_message_iter_get_arg_type(sub) ==
DBUS_TYPE_STRUCT) {
+DBusMessageIter sub2;
+const char *path;
+uint64_t u64;
+unsigned long ul;
+CGroupBlockIODeviceWeight *a;
+
+dbus_message_iter_recurse(sub, sub2);
+
+if (bus_iter_get_basic_and_next(sub2,
DBUS_TYPE_STRING, path, true) 0 ||
+bus_iter_get_basic_and_next(sub2,
DBUS_TYPE_UINT64, u64, false) 0)
+return -EINVAL;
+
+ul = (unsigned long) u64;
+
+if (u64 10 || u64 1000)
+return -EINVAL;
+
+if (mode != UNIT_CHECK) {
+CGroupBlockIODeviceWeight *b;
+bool exist = false;
+
+LIST_FOREACH(device_weights, b,
c-blockio_device_weights) {
+if (streq(b-path, path)) {
+a = b;
+exist = true;
+break;
+}
+}
+
+if (!exist) {
+a = new0(CGroupBlockIODeviceWeight,
1);
+if (!a)
+return -ENOMEM;
+
+a-path = strdup(path);
+if (!a-path) {
+free(a);
+return -ENOMEM;
+}
+}
+
+a-weight = ul;
+
+if (!exist)
+
LIST_PREPEND(CGroupBlockIODeviceWeight, device_weights,
+
c-blockio_device_weights, a);
+}
+
+n++;
+dbus_message_iter_next(sub);
+}
+
+if (mode != UNIT_CHECK) {
+_cleanup_free_ char *buf = NULL;
+_cleanup_fclose_ FILE *f = NULL;
+CGroupBlockIODeviceWeight *a;
+size_t size = 0;
+
+if (n == 0) {
+while (c-blockio_device_weights)
+
cgroup_context_free_blockio_device_weight(c, c-blockio_device_weights);
+}
+
+f = open_memstream(buf, size);
+if (!f)
+return -ENOMEM;
+
+fputs(BlockIODeviceWeight=\n, f);
+LIST_FOREACH(device_weights, a,
c-blockio_device_weights)
+fprintf(f, BlockIODeviceWeight=%s %lu\n,
a-path, a-weight);
+fflush(f);
+unit_write_drop_in_private(u, mode, name, buf);
+}
+
+return 1;
} else if (streq(name, MemoryAccounting)) {
if (dbus_message_iter_get_arg_type(i) != DBUS_TYPE_BOOLEAN)
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, 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? 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH resend] getty-generator: Enable getty on all active serial consoles.
On Sep 10, 2013 6:41 PM, Jan Engelhardt jeng...@inai.de wrote: On Tuesday 2013-09-10 17:41, Lennart Poettering wrote: On Wed, 28.08.13 13:12, Michael Marineau (michael.marin...@coreos.com) wrote: This enables a getty on active kernel consoles even when they are not the last one specified on the kernel command line and mapped to /dev/console. Now the order console=ttyS0 console=tty0 works in addition to console=tty0 console=ttyS0. The kernel already makes a distinction between the primary console, and all others (the latter only receive logs, but you cannot read from them via /dev/console iirc), and so we propagated that distinction into systemd, too. I can totally see that this is confusing though, as nobody remembers the right ordering... Though console= just follows the standard principle of later values override earlier ones, if nobody can remember the ordering, perhaps the kernel should be taught a suboption to explicitly specify the primary console. Think console.primary=ttyS0 console=tty0 console=tty0 console.primary=ttyS0 That doesn't answer the question whether a getty should be started on secondary consoles though. My surprise was that the generator doesn't already do that, not how the primary console that gets mapped to /dev/console is chosen. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH resend] getty-generator: Enable getty on all active serial consoles.
On Tuesday 2013-09-10 17:41, Lennart Poettering wrote: On Wed, 28.08.13 13:12, Michael Marineau (michael.marin...@coreos.com) wrote: This enables a getty on active kernel consoles even when they are not the last one specified on the kernel command line and mapped to /dev/console. Now the order console=ttyS0 console=tty0 works in addition to console=tty0 console=ttyS0. The kernel already makes a distinction between the primary console, and all others (the latter only receive logs, but you cannot read from them via /dev/console iirc), and so we propagated that distinction into systemd, too. I can totally see that this is confusing though, as nobody remembers the right ordering... Though console= just follows the standard principle of later values override earlier ones, if nobody can remember the ordering, perhaps the kernel should be taught a suboption to explicitly specify the primary console. Think console.primary=ttyS0 console=tty0 console=tty0 console.primary=ttyS0 ___ 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/10/2013 11:50 PM, Lennart Poettering wrote: On Mon, 26.08.13 11:19, Gao feng (gaof...@cn.fujitsu.com) wrote: Hi 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] blkio bandwidth: don't clean up all of entries in blockio_device_bandwidths list
On 09/10/2013 11:13 PM, Lennart Poettering wrote:
On Fri, 30.08.13 10:56, Gao feng (gaof...@cn.fujitsu.com) wrote:
if we get BlockIOReadBandwidth=, we should only remove the
read-bandwidth-entries in blockio_device_bandwidths list.
Thanks! Applied, though with one change:
+read = streq(BlockIOReadBandwidth, lvalue);
+
if (isempty(rvalue)) {
-while (c-blockio_device_bandwidths)
-cgroup_context_free_blockio_device_bandwidth(c,
c-blockio_device_bandwidths);
+CGroupBlockIODeviceBandwidth *next;
+
+LIST_FOREACH_SAFE (device_bandwidths, b, next,
c-blockio_device_bandwidths) {
+if (b-read == read) {
+LIST_REMOVE(CGroupBlockIODeviceBandwidth,
device_bandwidths, c-blockio_device_bandwidths, b);
+free(b-path);
+free(b);
I replaced the three previous lines with an invocation of
cgroup_context_free_blockio_device_bandwidth() again.
Thanks for your help!
Gao
___
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 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 -- Thanks, Chengwei passive, why would it need to change labels? What's the missing link here precisely? --- Makefile.am |1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.am b/Makefile.am index 5654ad3..dc5170a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3870,6 +3870,7 @@ libsystemd_login_la_LDFLAGS = \ -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym libsystemd_login_la_LIBADD = \ + libsystemd-label.la \ libsystemd-shared.la \ libsystemd-daemon-internal.la \ $(RT_LIBS) Lennart -- Lennart Poettering - Red Hat, Inc. signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
