Re: [systemd-devel] Enabling timesyncd in virtual machines
On Fri, 13.03.15 12:25, Michael Marineau (michael.marin...@coreos.com) wrote: Greetings, Currently systemd-timesyncd.service includes ConditionVirtualization=no, disabling it in both containers and virtual machines. Each VM platform tends to deal with or ignore the time problem in their own special ways, KVM/QEMU has the kernel time source kvm-clock, Xen has had different schemes over the years, VMware expects a userspace daemon sync the clock, and other platforms are content to drift with the wind as far as I can tell. I don't know of a robust way to know if a platform needs a little extra help from userspace to keep the clock sane or not but it seems generally safer to try than to risk drifting. Does anyone know of a reason to leave timesyncd off by default? Otherwise switching to ConditionVirtualization=!container should be reasonable. Just for the sake of completeness of the archives, a patch for this was merged a while back now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=4b16233e59b3edd8338819dad275cc94b5e5f6e7 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
On Thu, 09.04.15 15:20, Michal Sekletar (msekl...@redhat.com) wrote: +quotes = chars_intersect(service, SHELL_NEED_QUOTES); + +service_maybe_quoted = alloca(strlen(service) + 3); +sprintf(service_maybe_quoted, %s%s%s, quotes ? ' : , service, quotes ? ' : ); I have now added a new call to systemd git that properly prepares a string for inclusion in a shell command line. It will not just enclose the string in double quotes if necessary, but also escape all shell special shell characters within it. It's called shell_maybe_quote(), ad I ported the current code over to it, please use it for your new code too! Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir
On 08/04/15 20:11, Kay Sievers wrote: Right, we have to find out what we want to support here, cross-compile or secondary arch things. Only one thing is clear at the moment, that the current status makes no sense. :) We got $libdir for the secondary arch: http://cgit.freedesktop.org/systemd/systemd/commit/?id=eb39a6239c631873db62f6a942e6cb3dab0a2db4 But then we took $libdir as the reason to move the file and make it inaccessible for the secondary arch: http://cgit.freedesktop.org/systemd/systemd/commit/?id=aec432c6134146e138124c4130be2ee89dca07fa I think the question to be asking is, what API does systemd.pc represent? Is it the architecture-independent drop unit files in these directories...-style API of the systemd init system and related things, or is it a C ABI? If it's the various architecture-independent APIs (unit files, D-Bus, etc.) then $datadir/pkgconfig is an appropriate place. If it's a C API then $libdir/pkgconfig would be appropriate, but AIUI the C API is libsystemd, which already has its own separate .pc file. I don't think systemd.pc is really the appropriate place to answer the question what is the preferred library directory for the primary architecture on this system?, because there doesn't seem to be anything about systemd that makes its CPU architecture particularly important. Yes, systemd is in a unique position because it's pid 1, so there can only be one of it; but it doesn't actually seem to *do* anything with the $libdir? For the normal libraries to which it is linked (libselinux or whatever), it relies on ld.so's configured search path rather than doing its own thing; it doesn't load plugins, which is one situation where applications might need to know the preferred $libdir themselves; and it deliberately always uses /[usr/]lib, never /[usr/]lib/i386-linux-gnu or /[usr/]lib64, for architecture-independent APIs like units and tmpfiles snippets. If I wanted to find the primary architecture on a particular system, I'd start by looking at the toolchain (in particular, what /usr/bin/cc produces and where it looks for libraries), the kernel, and/or the package manager (Debian-style multiarch doesn't necessarily need to have a primary architecture at all, but the de facto standard for finding the closest-to-primary architecture where needed is to look in dpkg -s dpkg and see which architecture it is). Similarly, when compiling software, I don't think it's the upstream developer's place to be redefining $libdir (or indeed $prefix) according to local practices. GNU-style software defaults to /usr/local/lib, which is not the most appropriate location for *any* packaging system (except possibly *BSD ports) - but all distributions already know that, and have a standard set of configure arguments to redirect --prefix and --libdir to their preferred paths, whether that means /usr/i686-linux-gnu/lib or /usr/lib/i386-linux-gnu or /usr/lib64. It seems better for third-party software to be predictable about its installation paths, rather than for it to do what I mean and alter its defaults depending whether it thinks it's on a Debian or Red Hat derivative. -- Simon McVittie Collabora Ltd. http://www.collabora.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved service ignores UseDNS=false
I think I get it now. I have two interfaces that have different DNS servers set -- bond0 and br_lxc. All of the LXC containers use my router's DNS and everything else uses 127.0.2.1 . The config file for the br_lxc interface looks like this: [Match] Name=br_lxc [Network] Description=LXC bridge configuration DHCP=no LinkLocalAddressing=no Address=192.168.10.100/24 DNS=192.168.1.1 IPForward=true Now the DNS option is empty, and the 192.168.1.1 resolver disappeared from the /etc/resolv.conf file, and this is what I actually wanted, and I've accidentally found the bug. :) I also changed the bond0 interface config file to the following one: [Match] Name=bond0 [Network] Description=Bonded network DHCP=ipv4 LinkLocalAddressing=no DNS= IPForward=true [DHCP] UseDNS=false UseMTU=false SendHostname=true UseHostname=false UseDomains=true UseRoutes=true CriticalConnection=true RequestBroadcast=true And in the /etc/systemd/resolved.conf file I set DNS=127.0.2.1 only, and the two interfaces looks like this: # networkctl status -a ... ● 6: br_lxc Link File: n/a Network File: /etc/systemd/network/30-br_lxc-static.network Type: ether State: no-carrier (configured) Driver: bridge HW Address: 6e:7d:a5:7f:d6:06 MTU: 1500 Address: 192.168.10.100 fe80::6c7d:a5ff:fe7f:d606 ● 7: bond0 Link File: n/a Network File: /etc/systemd/network/50-bond0-dhcp.network Type: ether State: routable (configured) Driver: bonding HW Address: 3c:4a:92:00:4c:5b (Hewlett-Packard Company) MTU: 1500 Address: 192.168.1.150 fe80::3e4a:92ff:fe00:4c5b Gateway: 192.168.1.1 (TP-LINK TECHNOLOGIES CO.,LTD) Domain: mhouse.lh I'm not sure, but shouldn't there be a DNS field pointing to the local 127.0.2.1 address that was set in /etc/systemd/resolved.conf file? It looks like the DNS line in the above log shows only if the DNS= option is set in a corresponding interface config file. pgpywIvfDlXcs.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On 04/09/2015 11:04 AM, Lennart Poettering wrote: On Thu, 09.04.15 10:51, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: My above questions where directed directly at Lennart since you cannot know if Lennart's assumption which he bases his decisions on are premature,correct, wrong or misguided until you know what those assumptions are. Once those assumptions are known one can compare it with ones own as well as facts and have a higher level discussion about what makes suitable upstreams defaults and why. We generally follow the rule: we develop for the future, not for the past. A file system like ext234 is clearly not the future, A filesystem like ext is being actively developed,maintained and new features being added to it. While filesystems are being supported and actively developed,maintained and new features added to them you hardly can consider them not part of the future now can you despite their shortcomings compared to eachother. the concept of requiring fsck on dirty is just broken with today's large disks. Now, of course we will continue to support ext234, and fsck and stuff. However, we will not add *new* features to this scheme, since the whole idea of having something like this at all is yesterday's idea. Sure, btrfs is not particularly stable yet, but that hardly matters, as not even xfs requires such an fsck scheme anymore! BTRFS relevance matters no more or less then the rest of them ( despite it being new or feature rich ) since it will become obsolete at the same time as the rest of the existing filesystem since they will all be replaced by a filesystem that will be tailored to a new technology like pervasive persistent memory or memristors or something else. That new technology can be expected to emerge in the next 5 - 10 years ( which is around the same amount of time BTRFS becomes widely accepted and industry wide default that is if it ever manage to become that ) with another 10 years of obsolete/deprecation time for existing technology and their filesystems We will not add completely new features to the old stuff, How can you come to that conclusion when our largest consumer base across the three categories uses ext4 and undoubtedly will want systemd native features around for example [1] implemented? if we already know *now* that the old stuff is a dead end, How do you know that when a) existing filesystem will be very much alive for atleast 10 - 20 years more and b) the entire IT industry has absolutely no idea where it is heading, the technology evolution or even the market will take it? and things are already good enough in the area, and the future will make the whole problem go away. Since we are on the subject of future problems and predictions could you give me 5 random numbers between 1 and 40, 6 numbers between 1 and 48 and finally 5 numbers from 1 - 50 with two numbers from 1 - 10? Thanks JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Wed, 18.03.15 17:10, Christoph Pleger (christoph.ple...@cs.tu-dortmund.de) wrote: Warming up this old thread... Why does systemd not follow the above instructions to start the services of test.target after those of basic.target and before those of multi-user.target? I figure this trhead already explaiend why this doesn't work as you suggest. I just wanted to add what I think si the best option to do what you want: make your service an early boot service (by specifying DefaultDependencies=no), then order it before basic.target. Then, order it after the precise units you need from early boot, or, if you really think you need all of them, order your unit after sysinit.target, local-fs.target and possibly sockets.target, paths.target, slices.target. That way you will run after whatever you pick from the basic system initialization, but before the first normal services are run. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: Introduce journal-syslogd
On 04/09/2015 02:02 PM, Lennart Poettering wrote:
On Wed, 18.03.15 11:00, Susant Sahani (sus...@redhat.com) wrote:
Sorry for the late review!
Thanks for the review .
+paracommandsystemd-journal-syslogd/command serves journal
+events over the network. It multicasts journal event to Syslog RFC 5424
format.
+/para
The tool can also be used to unicast events, no? Maybe clarify that it
can do unicasting as well as multicasting, it's just a matter of
specifying the right target address, no?
yes infact I tested with the unicast . added now .
+static int update_cursor_state(Manager *m) {
+_cleanup_fclose_ FILE *f = NULL;
+int r;
+
+assert(m);
+
+if (!m-state_file || !m-last_cursor)
+return 0;
+
+f = fopen(m-state_file, we);
+if (!f)
+goto finish;
I think this really should be written in atomic style, i.e. into a
temporary file first, that is then renamed into the actual state file
name. That way the state file is either the old or the new one, but
never half-written for other processes.
Our fopen_temporary() call helps wth this.
Ok
+
+fprintf(f,
+# This is private data. Do not parse.\n
+LAST_CURSOR=%s\n,
+m-last_cursor);
+
+fflush(f);
+
+if (ferror(f))
+r = -errno;
This flusing and check should be done via fflush_and_check().
Added.
+static int manager_journal_event_handler(sd_event_source *event, int fd,
uint32_t revents, void *userp) {
+Manager *m = userp;
+int r;
+
+if (revents EPOLLHUP) {
+log_debug(Received HUP);
+return 0;
+}
+
+if (!(revents EPOLLIN)) {
+log_warning(Unexpected poll event %PRIu32., revents);
+return -EINVAL;
+}
+
+if (m-event_journal_input) {
Hmm, why this check? Isn't this set anyway if we entered this event
handler function?
OK
+
+r = sd_event_default(m-event);
+if (r 0)
+return log_error_errno(r, sd_event_default failed: %m);
+
+assert_se(sigemptyset(mask) == 0);
+sigset_add_many(mask, SIGINT, SIGTERM, -1);
+assert_se(sigprocmask(SIG_SETMASK, mask, NULL) == 0);
We have sigprocmask_many() now for this (and shouild probably convert
all invocations like this to it...
OK
+
+pri = (uint16_t) strtoul(priority, NULL, 0);
+fac = (uint16_t) strtoul(facility, NULL, 0);
Hmm, I'd really like some error checking for this.
Also can we use safe_atou16() for this?
Yes doing now .
+r = setsockopt(m-socket, IPPROTO_IP, IP_PKTINFO, one, sizeof(one));
+if (r 0) {
+r = -errno;
+goto fail;
+}
This is not needed is it?
+
+r = setsockopt(m-socket, IPPROTO_IP, IP_MULTICAST_TTL, ttl,
sizeof(ttl));
+if (r 0) {
+r = -errno;
+goto fail;
+}
And this neither?
Removed both
+
+r = setsockopt(m-socket, IPPROTO_IP, IP_MULTICAST_LOOP, one,
sizeof(one));
+if (r 0) {
+r = -errno;
+goto fail;
+}
This might be useful.
Looks pretty good already!
Thanks !
Lennart
Susant
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: Introduce journal-syslogd
This tiny daemon enables to pull journal entries and push to a UDP
multicast address in syslog RFC 5424 format. systemd-journal-syslogd
runs with own user systemd-journal-syslog. It starts running after
the network is up.
V2: Address Zbigniew's comments
1. Rename binary systemd-journal-syslogd
2. Fixed up man and added example
3. Error code check sd_event_add_signal
4. remove +User=systemd-journal-network from service file
5. remove opterr=0
6. assignment into declaration of mh
V3: Address Lennart's comments
1. add unicast events in the man
2. use fopen_temporary and fflush_and_check().
3. remove if (m-event_journal_input) {
4. use sigprocmask_many
5. fix facility and priority
6. remove IP_MULTICAST_TTL and IP_PKTINFO
7. use safe_atoi
---
Makefile-man.am | 8 +
Makefile.am | 37 ++
man/systemd-journal-syslogd.service.xml | 84 +
man/systemd-journal-syslogd.xml | 156
src/journal-remote/journal-syslog-conf.c | 61
src/journal-remote/journal-syslog-conf.h | 39 ++
src/journal-remote/journal-syslog-gperf.gperf | 18 +
src/journal-remote/journal-syslog-manager.c | 501 ++
src/journal-remote/journal-syslog-manager.h | 70
src/journal-remote/journal-syslog-network.c | 201 +++
src/journal-remote/journal-syslogd.c | 217 +++
src/journal-remote/journal-syslogd.conf.in| 2 +
units/systemd-journal-syslogd.service | 18 +
13 files changed, 1412 insertions(+)
create mode 100644 man/systemd-journal-syslogd.service.xml
create mode 100644 man/systemd-journal-syslogd.xml
create mode 100644 src/journal-remote/journal-syslog-conf.c
create mode 100644 src/journal-remote/journal-syslog-conf.h
create mode 100644 src/journal-remote/journal-syslog-gperf.gperf
create mode 100644 src/journal-remote/journal-syslog-manager.c
create mode 100644 src/journal-remote/journal-syslog-manager.h
create mode 100644 src/journal-remote/journal-syslog-network.c
create mode 100644 src/journal-remote/journal-syslogd.c
create mode 100644 src/journal-remote/journal-syslogd.conf.in
create mode 100644 units/systemd-journal-syslogd.service
diff --git a/Makefile-man.am b/Makefile-man.am
index 2f3e5f2..437d488 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1380,6 +1380,14 @@ man/systemd-journal-gatewayd.socket.html:
man/systemd-journal-gatewayd.service.h
endif
+MANPAGES += \
+man/systemd-journal-syslogd.service.8 \
+man/systemd-journal-syslogd.8
+MANPAGES_ALIAS += \
+man/systemd-journal-syslogd.8
+man/systemd-journal-syslogd.8: man/systemd-journal-syslogd.service.8
+man/systemd-journal-syslogd.html: man/systemd-journal-syslogd.service.html
+
if HAVE_MYHOSTNAME
MANPAGES += \
man/nss-myhostname.8
diff --git a/Makefile.am b/Makefile.am
index 0a57389..0b843ac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4361,6 +4361,43 @@ EXTRA_DIST += \
src/journal-remote/journal-upload.conf.in
endif
+systemd_journal_syslogd_SOURCES = \
+ src/journal-remote/journal-syslog-manager.h \
+ src/journal-remote/journal-syslog-manager.c \
+ src/journal-remote/journal-syslog-conf.h \
+ src/journal-remote/journal-syslog-conf.c \
+ src/journal-remote/journal-syslog-network.c \
+ src/journal-remote/journal-syslogd.c
+
+nodist_systemd_journal_syslogd_SOURCES = \
+ src/journal-remote/journal-syslog-gperf.c
+
+EXTRA_DIST += \
+src/journal-remote/journal-syslog-gperf.gperf
+
+CLEANFILES += \
+src/journal-remote/journal-syslog-gperf.c
+
+systemd_journal_syslogd_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-journal-internal.la \
+ libsystemd-shared.la
+
+rootlibexec_PROGRAMS += \
+ systemd-journal-syslogd
+
+nodist_systemunit_DATA += \
+ units/systemd-journal-syslogd.service
+
+EXTRA_DIST += \
+ units/systemd-journal-syslogd.service.in
+
+nodist_pkgsysconf_DATA += \
+ src/journal-remote/journal-syslogd.conf
+
+EXTRA_DIST += \
+ src/journal-remote/journal-syslogd.conf.in
+
# using _CFLAGS = in the conditional below would suppress AM_CFLAGS
journalctl_CFLAGS = \
$(AM_CFLAGS)
diff --git a/man/systemd-journal-syslogd.service.xml
b/man/systemd-journal-syslogd.service.xml
new file mode 100644
index 000..e837153
--- /dev/null
+++ b/man/systemd-journal-syslogd.service.xml
@@ -0,0 +1,84 @@
+?xml version='1.0'? !--*- Mode: nxml; nxml-child-indent: 2;
indent-tabs-mode: nil -*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+
+!--
+ This file is part of systemd.
+
+ Copyright 2015 Susant Sahani
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as
Re: [systemd-devel] bootloader time on a non-EFI bootloader
On Thu, Apr 9, 2015 at 11:28 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 16.03.15 11:29, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: I would like to pass the time it was spent in bootloader to systemd. Is there a kernel command line to pass this information on non EFI bootloader? Or is there an another way? I am open to add this, but I really don't want to see tons of different drivers to read this data added to systemd. Right, mis-using the kernel command line does not look like an option for support in systemd. Hence the way I think this should work, is adding a generic interface to the kernel to /sys/firmware/timing or so, where this information can be read from. We'd then make systemd read that. And wherever the information comes from would be a kernel internal decision, and could be implemented in a myriad of different ways for different architectures. Yeah, something like that. For the non-EFI setups, the kernel boot protocol could have an extension where the boot loader or the firmware can pass generic key/value pairs to the starting kernel and the kernel exports them; just like the volatile variables of EFI provide us. Also note that ACPI 5.0 exports this timing information in a generic way anyway. Given that ACPI is fairly standard and apparently is even what embedded is standardizing on I'd be open to adding native support for parsing this info from ACPI to systemd, if it's easy enough. The ACPI Firmware Basic Boot Performance Data Record provides some values on more recent firmware versions: $ sudo ./test-boot-timestamp ACPI FPDT: loader start=7.994s exit=8.115s duration=120ms EFI Loader: start=7.994s exit=8.080s duration=86ms Firmware began 8.115550s before kernel. Loader began 120.791ms before kernel. The ACPI values are accessible after the system booted up, just like EFI variables are. For platforms which do not have anything like that, the kernel boot protocol still sounds like the closest thing to fill the gap. However, beyond that: please abstract this in the kernel, I don#t want to see tons of drivers for this in systemd. Yeah, we should not invent things here to cover for missing core features. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On 04/09/2015 08:54 AM, Lennart Poettering wrote: Of course, this only works for GPT systems, i.e. modern systems, and modern systems probably wouldn't run ext234 anyway, so maybe it's not worth it... Actually neither xfs nor btrfs nor reiserfs appear to require an fsck still, it's only ext234 and vfat. And I figure it's not worth fixing this for ext234 now... Now I just have to ask since I have a hard time understanding where you are coming from regarding your view on filesystems in general, their future thus the upstream choices you are making seem quite illogical to me... What is your definition of modern system? Why are you under the assumption that modern systems wont run those filesystems? Where is that assumption coming from? What is the time frame you are basing your assumptions on? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, Apr 9, 2015 at 12:18 PM, Lennart Poettering lenn...@poettering.net wrote: order it after the precise units you need from early boot, This is fragile because it will break every time precise units change. This is exact reason why we have systemd.special man page at all - to provide high level synchronization points that are not affected by underlying implementation change. The problem is, systemd does not allow to insert something *between* two synchronization points without knowing precise implementation. You seem to insist it is a feature. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: Implement fallback DHCPv6 prefix handling for older kernels
Hi! On 09/04/15 12:45, Patrik Flykt wrote: Hmm, in general, we really should try to create the same binaries, regardless if we are built on an old or new kernel. And the binaries should work as good as possible, regardless which kernel version they are running on. But with the change above the binary built on a newer kernel work differently from an older kernel, even though we added the definition to missing.h to make the distinction go away... Or in other words: we try to do runtime compat, not just compile time compat, so that we don't strictly have to sync kernel and userspace updated. Hmm, I was suspecting that for a moment. I need to come up with a better runtime solution for version 2 of the patch then. You should construct and send netlink packet as for kernel 3.14, but be prepared, you will get error back on 3.13, because the parameter is unknown. So you just need to handle the error gacefully, not fail. Alex. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootloader time on a non-EFI bootloader
On Mon, 16.03.15 11:29, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, I would like to pass the time it was spent in bootloader to systemd. Is there a kernel command line to pass this information on non EFI bootloader? Or is there an another way? I am open to add this, but I really don't want to see tons of different drivers to read this data added to systemd. Hence the way I think this should work, is adding a generic interface to the kernel to /sys/firmware/timing or so, where this information can be read from. We'd then make systemd read that. And wherever the information comes from would be a kernel internal decision, and could be implemented in a myriad of different ways for different architectures. Also note that ACPI 5.0 exports this timing information in a generic way anyway. Given that ACPI is fairly standard and apparently is even what embedded is standardizing on I'd be open to adding native support for parsing this info from ACPI to systemd, if it's easy enough. However, beyond that: please abstract this in the kernel, I don#t want to see tons of drivers for this in systemd. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: Introduce journal-syslogd
On Wed, 18.03.15 11:00, Susant Sahani (sus...@redhat.com) wrote:
Sorry for the late review!
+paracommandsystemd-journal-syslogd/command serves journal
+events over the network. It multicasts journal event to Syslog RFC 5424
format.
+/para
The tool can also be used to unicast events, no? Maybe clarify that it
can do unicasting as well as multicasting, it's just a matter of
specifying the right target address, no?
+static int update_cursor_state(Manager *m) {
+_cleanup_fclose_ FILE *f = NULL;
+int r;
+
+assert(m);
+
+if (!m-state_file || !m-last_cursor)
+return 0;
+
+f = fopen(m-state_file, we);
+if (!f)
+goto finish;
I think this really should be written in atomic style, i.e. into a
temporary file first, that is then renamed into the actual state file
name. That way the state file is either the old or the new one, but
never half-written for other processes.
Our fopen_temporary() call helps wth this.
+
+fprintf(f,
+# This is private data. Do not parse.\n
+LAST_CURSOR=%s\n,
+m-last_cursor);
+
+fflush(f);
+
+if (ferror(f))
+r = -errno;
This flusing and check should be done via fflush_and_check().
+static int manager_journal_event_handler(sd_event_source *event, int fd,
uint32_t revents, void *userp) {
+Manager *m = userp;
+int r;
+
+if (revents EPOLLHUP) {
+log_debug(Received HUP);
+return 0;
+}
+
+if (!(revents EPOLLIN)) {
+log_warning(Unexpected poll event %PRIu32., revents);
+return -EINVAL;
+}
+
+if (m-event_journal_input) {
Hmm, why this check? Isn't this set anyway if we entered this event
handler function?
+
+r = sd_event_default(m-event);
+if (r 0)
+return log_error_errno(r, sd_event_default failed: %m);
+
+assert_se(sigemptyset(mask) == 0);
+sigset_add_many(mask, SIGINT, SIGTERM, -1);
+assert_se(sigprocmask(SIG_SETMASK, mask, NULL) == 0);
We have sigprocmask_many() now for this (and shouild probably convert
all invocations like this to it...
+
+pri = (uint16_t) strtoul(priority, NULL, 0);
+fac = (uint16_t) strtoul(facility, NULL, 0);
Hmm, I'd really like some error checking for this.
Also can we use safe_atou16() for this?
+r = setsockopt(m-socket, IPPROTO_IP, IP_PKTINFO, one, sizeof(one));
+if (r 0) {
+r = -errno;
+goto fail;
+}
This is not needed is it?
+
+r = setsockopt(m-socket, IPPROTO_IP, IP_MULTICAST_TTL, ttl,
sizeof(ttl));
+if (r 0) {
+r = -errno;
+goto fail;
+}
And this neither?
+
+r = setsockopt(m-socket, IPPROTO_IP, IP_MULTICAST_LOOP, one,
sizeof(one));
+if (r 0) {
+r = -errno;
+goto fail;
+}
This might be useful.
Looks pretty good already!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
Am 09.04.2015 um 12:17 schrieb Jóhann B. Guðmundsson: On 04/09/2015 08:54 AM, Lennart Poettering wrote: Of course, this only works for GPT systems, i.e. modern systems, and modern systems probably wouldn't run ext234 anyway, so maybe it's not worth it... Actually neither xfs nor btrfs nor reiserfs appear to require an fsck still, it's only ext234 and vfat. And I figure it's not worth fixing this for ext234 now... Now I just have to ask since I have a hard time understanding where you are coming from regarding your view on filesystems in general, their future thus the upstream choices you are making seem quite illogical to me... What is your definition of modern system? Why are you under the assumption that modern systems wont run those filesystems? Where is that assumption coming from? What is the time frame you are basing your assumptions on? they are just wrong because in production environments *virtually nobody* will jump to BTRFS that soon, not for upgraded and not for new installed systems, there will be a high percentage of admins stick at ext4 just because they know it, can handle it and it works and much more important: BTRFS *currently* don't exist, not for serious environments because it's not finished and so declare anything which is production ready and everywhere in use as legacy and not worth is more than questionable 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] [PATCH v2] log: be more verbose if dbus job fails
On Thu, Apr 09, 2015 at 04:35:53PM +0200, Michal Sekletar wrote:
On Thu, Apr 09, 2015 at 02:10:14PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 03:20:02PM +0200, Michal Sekletar wrote:
Users might have hard time figuring out why exactly their systemctl
request
failed. If dbus job fails try to figure out more details about failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c
b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char **result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+
org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs *d,
bool quiet) {
log_error(Operation on or unit type of %s not
supported on this system., strna(d-name));
else if (!streq(d-result, done) !streq(d-result,
skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d,
result);
+if (q 0)
+log_debug_errno(q, Failed to
get Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See
\systemctl status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : , d-name,
quotes ? ' : );
+
log_job_error_with_service_result(d-name, result);
} else
log_error(Job failed. See \journalctl
-xe\ for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const struct
signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
dbus property returns the result as a string. So we need to map this string
to an explanation. Going through the intermediate ServiceResult int does
not really gain anything... I think things would be simpler if you added a
table mapping result to explanation:
static const struct {
const char *result, *explanation;
} explanations[] = {
{timeout, start timeout was exceeded},
...
{}
};
and then simply looped over this table. This way it won't be necessary to
have three different lists.
I guess that what you are suggesting will remove a
Re: [systemd-devel] [PATCH] fstab-generator: Support root on tmpfs
Hi Lennart, that does sound interesting. Let me polish my patches for stateless systems on real hardware a bit first though:-) It would give a horrible impression if the system would not come up properly, just because you forgot to pass root= to the kernel. Sorry for the delay, I was on vacation over the eastern On Wed, Apr 8, 2015 at 11:21 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 22.03.15 00:57, Tobias Hunger (tobias.hun...@gmail.com) wrote: BTW, if you are interested, I'd be willing to take this one step further even, and default to tmpfs as root fs, if only mount.usr= is specified on the kernel cmdline, and root= is missing. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
On Thu, Apr 09, 2015 at 02:44:38PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 04:35:53PM +0200, Michal Sekletar wrote:
On Thu, Apr 09, 2015 at 02:10:14PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 03:20:02PM +0200, Michal Sekletar wrote:
Users might have hard time figuring out why exactly their systemctl
request
failed. If dbus job fails try to figure out more details about failure
by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c
b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char
**result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+
org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs
*d, bool quiet) {
log_error(Operation on or unit type of %s not
supported on this system., strna(d-name));
else if (!streq(d-result, done)
!streq(d-result, skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d,
result);
+if (q 0)
+log_debug_errno(q, Failed to
get Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See
\systemctl status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : , d-name,
quotes ? ' : );
+
log_job_error_with_service_result(d-name, result);
} else
log_error(Job failed. See
\journalctl -xe\ for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const struct
signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
dbus property returns the result as a string. So we need to map this
string
to an explanation. Going through the intermediate ServiceResult int does
not really gain anything... I think things would be simpler if you added a
table mapping result to explanation:
static const struct {
const char *result, *explanation;
} explanations[] = {
[systemd-devel] issuing 'reboot' command does not print the familiar 'Restarting system.' message
Hi Systemd devs : We have some scripts that depend on the kernel printing Restarting system. when a reboot command is issued on the console. Unfortunately we are not seeing such a message just before reboot. It seems that the reboot() syscall is not even getting invoked by start_special(). Do you guys have any insights on this? Is there any way to fix this? version : rpm : systemd-201-2.fc18.9.i686 % systemd --version systemd 201 +PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ [ani@bs360:/src] [EOS18.dev]% systemctl --version systemd 201 +PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ Thanks! ani ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: Implement fallback DHCPv6 prefix handling for older kernels
On Thu, 09.04.15 13:37, Patrik Flykt (patrik.fl...@linux.intel.com) wrote:
src/libsystemd/sd-rtnl/rtnl-types.c | 2 ++
src/network/networkd-address.c | 5 +++-
src/network/networkd-dhcp6.c| 55
+++--
src/network/networkd-link.c | 4 +++
src/network/networkd-link.h | 2 ++
5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
index 49784bf..407b749 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -360,7 +360,9 @@ static const NLType rtnl_address_types[CONST_MAX(IFA_MAX,
IFA_FLAGS) + 1] = {
[IFA_ANYCAST],
[IFA_MULTICAST],
*/
+#if HAVE_DECL_IFA_FLAGS
[IFA_FLAGS] = { .type = NLA_U32 },
+#endif
};
Hmm, in general, we really should try to create the same binaries,
regardless if we are built on an old or new kernel. And the binaries
should work as good as possible, regardless which kernel version they
are running on. But with the change above the binary built on a newer
kernel work differently from an older kernel, even though we added the
definition to missing.h to make the distinction go away...
Or in other words: we try to do runtime compat, not just compile time
compat, so that we don't strictly have to sync kernel and userspace
updated.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - man/standard-conf.xml src/vconsole
On Thu, Apr 09, 2015 at 01:13:23PM +0200, Lennart Poettering wrote:
On Sun, 15.03.15 17:42, Zbigniew Jędrzejewski-Szmek
(zbys...@kemper.freedesktop.org) wrote:
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..fe8573f 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -96,16 +96,14 @@ static int enable_utf8(int fd) {
return r;
}
-static int keymap_load(const char *vc, const char *map, const char
*map_toggle, bool utf8, pid_t *_pid) {
+static bool keyboard_load_and_wait(const char *vc, const char *map,
const char *map_toggle, bool utf8) {
No! Please don't!
We follow kernel-style error handling, and that means returning int
as return value, and negative errno values for errors.
Please do not turn error cases into bool. This is simply confusing,
and different from all our other code.
If you want to return some boolean value, you then you can also do
that with an int: return negative on error, 0 on false and 1 on
true...
OK. In this case this removed some boilerplate error handling, but I
agree it's nice to be consistent with the rest of the error code.
Will undo the part now that changes the return values of the functions
to bool.
Thanks.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On 04/09/2015 10:30 AM, Reindl Harald wrote: Am 09.04.2015 um 12:17 schrieb Jóhann B. Guðmundsson: On 04/09/2015 08:54 AM, Lennart Poettering wrote: Of course, this only works for GPT systems, i.e. modern systems, and modern systems probably wouldn't run ext234 anyway, so maybe it's not worth it... Actually neither xfs nor btrfs nor reiserfs appear to require an fsck still, it's only ext234 and vfat. And I figure it's not worth fixing this for ext234 now... Now I just have to ask since I have a hard time understanding where you are coming from regarding your view on filesystems in general, their future thus the upstream choices you are making seem quite illogical to me... What is your definition of modern system? Why are you under the assumption that modern systems wont run those filesystems? Where is that assumption coming from? What is the time frame you are basing your assumptions on? they are just wrong because in production environments *virtually nobody* will jump to BTRFS that soon, not for upgraded and not for new installed systems, there will be a high percentage of admins stick at ext4 just because they know it, can handle it and it works and much more important: BTRFS *currently* don't exist, not for serious environments because it's not finished and so declare anything which is production ready and everywhere in use as legacy and not worth is more than questionable My above questions where directed directly at Lennart since you cannot know if Lennart's assumption which he bases his decisions on are premature,correct, wrong or misguided until you know what those assumptions are. Once those assumptions are known one can compare it with ones own as well as facts and have a higher level discussion about what makes suitable upstreams defaults and why. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
Am 09.04.2015 um 19:05 schrieb Kay Sievers: On Thu, Apr 9, 2015 at 6:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.04.2015 um 18:52 schrieb Kay Sievers: On Thu, Apr 9, 2015 at 3:02 PM, Jóhann B. Guðmundsson wrote: We generally follow the rule: we develop for the future, not for the past. A file system like ext234 is clearly not the future, A filesystem like ext is being actively developed,maintained and new features being added to it. While filesystems are being supported and actively developed,maintained and new features added to them you hardly can consider them not part of the future now can you despite their shortcomings compared to eachother. It is more about that: A filesystem which requires an out-of-kernel fsck, but has no proper indication in the superblock to indicate that, and integrates that way with its own fsck tool, is nothing systemd needs to work around. If the filesystem wants better integration, it has to provide the needed features not rely on hacks on mis-use of other facilities like EFI or the kernel cmdline, or flag files, to cover for the missing feature. At a general level, an out-of-kernel fsck for a filesystem used as the rootfs soulds really really weird in the year 2015. And this is not neccessarily about btrfs, xfs solved that problem many many years ago http://linux.die.net/man/8/xfs_check If the filesystem is very large (has many files) then xfs_check might run out of memory. In this case the message out of memory is printed sounds really so much better than ext4 Yeah, that is why Red Hat Enterprise Linux uses XFS as the default. Too bad for them that they did not ask for you valuable expert advise keep your cynicism for yourself * i just pointed out that NO current existing and stable FS is perfect * xfs solved that problem many many years ago and Red Hat Enterprise Linux uses XFS as the default combined with weird in the year 2015 is only arrogant given that this is a recent change in RHEL7 * before ext4 was the default FS * just because you say the whole world won't go and convert anything to XFS and there are filesystems which will use ext4 in 10 years as now 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] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Sun, 15.03.15 21:30, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: So this used to to be possible for ext4, by setting mount count one below the mount limit. But mount limit now defaults to disabled, so this stopped being possible. Also, this suffers from the same problem that setting the flag requires modyfing the filesystem. Just touching the super block is not that bad, but still, doing it externally seems nicer. Another option might be to define a bit for this in the GPT partition header, and then write only to that. The file system stays unmodified then. This would work for all file systems, and we could collect this easily in systemd via udev... Operating systems such as ChromeOS write to the partition table all the time, and maintain boot counters and suchlike there, so this might be an option? Of course, this only works for GPT systems, i.e. modern systems, and modern systems probably wouldn't run ext234 anyway, so maybe it's not worth it... Actually neither xfs nor btrfs nor reiserfs appear to require an fsck still, it's only ext234 and vfat. And I figure it's not worth fixing this for ext234 now... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] network: Implement fallback DHCPv6 prefix handling for older kernels
When setting IPv6 addresses acquired by DHCPv6, systemd-networkd sets
the IFA_F_NOPREFIXROUTE flag in the IFA_FLAGS netlink attribute. As the
flag and the attribute are present starting with Linux 3.14, older
kernels will need systemd-network to manage prefix route handling.
Support for IFA_FLAGS is done during compile time and implemented as
part of netlink type checking. When IFA_FLAGS is detected in an systemd
external kernel header, HAVE_DECL_IFA_FLAGS is defined and the type
check will be successful. If not, setting the attribute will fail and
systemd-network will record this fact to its Link structure. Later if
a prefix expires, the same Link structure will be queried for the
successful use of IFA_FLAGS, with the DHCPv6 addresses handled either
by the kernel or the systemd-networkd fallback code.
The prefix expiration and IPv6 address updating fallback code is
resurrected from the parts deleted with commit
47d45d3cde45d6545367570264e4e3636bc9e345.
This patch can be removed once the minimum kernel requirements are
greater than or equal to 3.14.
---
Hi,
This patch implements a compile time fix for IFA_FLAGS support. Doing the
fix run time has its difficulties as the kernel discarding DHCPv6 address
assignment in the error path of dhcp6_address_handler() can have been
caused by other error situations.
I got this one working on my machine by commenting IFA_FLAGS out/leaving
IFA_FLAGS defined in the kernel headers, please test against real running
3.8/3.14 Linux versions.
Cheers,
Patrik
src/libsystemd/sd-rtnl/rtnl-types.c | 2 ++
src/network/networkd-address.c | 5 +++-
src/network/networkd-dhcp6.c| 55 +++--
src/network/networkd-link.c | 4 +++
src/network/networkd-link.h | 2 ++
5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
index 49784bf..407b749 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -360,7 +360,9 @@ static const NLType rtnl_address_types[CONST_MAX(IFA_MAX,
IFA_FLAGS) + 1] = {
[IFA_ANYCAST],
[IFA_MULTICAST],
*/
+#if HAVE_DECL_IFA_FLAGS
[IFA_FLAGS] = { .type = NLA_U32 },
+#endif
};
static const NLTypeSystem rtnl_address_type_system = {
diff --git a/src/network/networkd-address.c b/src/network/networkd-address.c
index 85acc49..2057d05 100644
--- a/src/network/networkd-address.c
+++ b/src/network/networkd-address.c
@@ -218,7 +218,10 @@ int address_update(Address *address, Link *link,
if (address-flags ~0xff) {
r = sd_rtnl_message_append_u32(req, IFA_FLAGS, address-flags);
if (r 0)
-return log_error_errno(r, Could not set extended
flags: %m);
+log_link_warning(link, Could not set extended flags:
%s,
+ strerror(-r));
+else
+link-rtnl_extended_flags = true;
}
r = sd_rtnl_message_addr_set_scope(req, address-scope);
diff --git a/src/network/networkd-dhcp6.c b/src/network/networkd-dhcp6.c
index e863f4b..6b040bd 100644
--- a/src/network/networkd-dhcp6.c
+++ b/src/network/networkd-dhcp6.c
@@ -67,7 +67,7 @@ static int dhcp6_address_update(Link *link, struct in6_addr
*ip6_addr,
memcpy(addr-in_addr.in6, ip6_addr, sizeof(*ip6_addr));
addr-flags = IFA_F_NOPREFIXROUTE;
-addr-prefixlen = 64;
+addr-prefixlen = prefixlen;
addr-cinfo.ifa_prefered = lifetime_preferred;
addr-cinfo.ifa_valid = lifetime_valid;
@@ -262,6 +262,52 @@ static int dhcp6_configure(Link *link, int event) {
return r;
}
+static int dhcp6_prefix_expired(Link *link) {
+int r;
+sd_dhcp6_lease *lease;
+struct in6_addr *expired_prefix, ip6_addr;
+uint8_t expired_prefixlen;
+uint32_t lifetime_preferred, lifetime_valid;
+
+r = sd_icmp6_ra_get_expired_prefix(link-icmp6_router_discovery,
+expired_prefix, expired_prefixlen);
+if (r 0)
+return r;
+
+r = sd_dhcp6_client_get_lease(link-dhcp6_client, lease);
+if (r 0)
+return r;
+
+log_link_struct(link, LOG_INFO,
+MESSAGE=%-*s: IPv6 prefix
SD_ICMP6_ADDRESS_FORMAT_STR/%d expired,
+IFNAMSIZ, link-ifname,
+SD_ICMP6_ADDRESS_FORMAT_VAL(*expired_prefix),
+expired_prefixlen, NULL);
+
+sd_dhcp6_lease_reset_address_iter(lease);
+
+while (sd_dhcp6_lease_get_address(lease, ip6_addr,
+lifetime_preferred,
+lifetime_valid) = 0) {
+
+r = sd_icmp6_prefix_match(expired_prefix, expired_prefixlen,
+
Re: [systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
On Thu, Apr 09, 2015 at 03:20:02PM +0200, Michal Sekletar wrote:
Users might have hard time figuring out why exactly their systemctl request
failed. If dbus job fails try to figure out more details about failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c
b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char **result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+ org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs *d,
bool quiet) {
log_error(Operation on or unit type of %s not
supported on this system., strna(d-name));
else if (!streq(d-result, done) !streq(d-result,
skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d, result);
+if (q 0)
+log_debug_errno(q, Failed to get
Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See
\systemctl status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : , d-name, quotes
? ' : );
+log_job_error_with_service_result(d-name,
result);
} else
log_error(Job failed. See \journalctl
-xe\ for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const struct
signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
dbus property returns the result as a string. So we need to map this string
to an explanation. Going through the intermediate ServiceResult int does
not really gain anything... I think things would be simpler if you added a
table mapping result to explanation:
static const struct {
const char *result, *explanation;
} explanations[] = {
{timeout, start timeout was exceeded},
...
{}
};
and then simply looped over this table. This way it won't be necessary to
have three different lists.
This could live simply in systemctl.c. Those are only parts of
sentences, nothing generally useful.
+static const char* const service_result_table[_SERVICE_RESULT_MAX] = {
+[SERVICE_SUCCESS] = success,
+[SERVICE_FAILURE_RESOURCES] = resources,
+[SERVICE_FAILURE_TIMEOUT] = timeout,
+[SERVICE_FAILURE_EXIT_CODE] = exit-code,
+[SERVICE_FAILURE_SIGNAL] = signal,
+[SERVICE_FAILURE_CORE_DUMP] = core-dump,
+
Re: [systemd-devel] [systemd-commits] 2 commits - man/standard-conf.xml src/vconsole
On Sun, 15.03.15 17:42, Zbigniew Jędrzejewski-Szmek
(zbys...@kemper.freedesktop.org) wrote:
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..fe8573f 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -96,16 +96,14 @@ static int enable_utf8(int fd) {
return r;
}
-static int keymap_load(const char *vc, const char *map, const char
*map_toggle, bool utf8, pid_t *_pid) {
+static bool keyboard_load_and_wait(const char *vc, const char *map,
const char *map_toggle, bool utf8) {
No! Please don't!
We follow kernel-style error handling, and that means returning int
as return value, and negative errno values for errors.
Please do not turn error cases into bool. This is simply confusing,
and different from all our other code.
If you want to return some boolean value, you then you can also do
that with an int: return negative on error, 0 on false and 1 on
true...
Also see CODING_STYLE about this.
Will undo the part now that changes the return values of the functions
to bool.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
On Thu, Apr 09, 2015 at 02:10:14PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 03:20:02PM +0200, Michal Sekletar wrote:
Users might have hard time figuring out why exactly their systemctl request
failed. If dbus job fails try to figure out more details about failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c
b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char **result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+ org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs *d,
bool quiet) {
log_error(Operation on or unit type of %s not
supported on this system., strna(d-name));
else if (!streq(d-result, done) !streq(d-result,
skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d, result);
+if (q 0)
+log_debug_errno(q, Failed to get
Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See
\systemctl status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : , d-name,
quotes ? ' : );
+log_job_error_with_service_result(d-name,
result);
} else
log_error(Job failed. See \journalctl
-xe\ for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const struct
signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
dbus property returns the result as a string. So we need to map this string
to an explanation. Going through the intermediate ServiceResult int does
not really gain anything... I think things would be simpler if you added a
table mapping result to explanation:
static const struct {
const char *result, *explanation;
} explanations[] = {
{timeout, start timeout was exceeded},
...
{}
};
and then simply looped over this table. This way it won't be necessary to
have three different lists.
This could live simply in systemctl.c. Those are only parts of
sentences, nothing generally useful.
Yes, these const values and perhaps the followings should not be in
log.c, perhaps systemctl.c or in a file where services state make sense
and where we can
Re: [systemd-devel] Drop systemd-ui
On Tue, Mar 31, 2015 at 01:47:40PM +, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 31, 2015 at 07:31:31AM +, Jóhann B. Guðmundsson wrote: What I'm proposing is that we dropped that proof of concept since it's not being maintained, there exist better alternatives thus it's intended purpose has been fulfilled already. Agreed that it doesn't make sense to have this distributed. E.g. Fedora should retire the package. Upstream git repository should stay as a historical artifact of course. FYI: I have now retired the package in Fedora 22 and rawhide. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Tips for using GDB to analyze systemd init process (`/sbin/init`)
On Sat, 14.03.15 09:14, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Dear systemd folks, using Debian Sid/unstable with systemd 215-12, I attached to it with GDB to analyze some things. Attached with `gdb --pid 1` worked. But continuing the execution and then hitting Ctrl + c to stop and analyze it again, systemd caught that command and shut the system down. How do you accomplish the goal to analyze systemd with GDB? All programs that use signalfd() are really nasty to debug in gdb, since gdb doesn't catch the Ctl-C then anymore via ptrace, but it gets delivered to the signalfd instead, and thus handled by the app anyway. To work around this: keep a second terminal open and send SIGTRAP from there. I usually carefully set break points though so that I never have to deal with PID 1 running uncontrolled in gdb though... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] activate on DBus signal
On Thu, 09.04.15 14:52, WaLyong Cho (walyong@samsung.com) wrote: I know, this is very strange and seems not cool. And maybe the activation will really slow. But seems not impossible. Well, if something is ugly, then this is often a hint that it might not be thought to the end, or might ultimately not be what one should do. I agree with Simon here: this really smells like something where a different solution for your original usecase might be a better option. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Thu, Apr 9, 2015 at 3:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: We generally follow the rule: we develop for the future, not for the past. A file system like ext234 is clearly not the future, A filesystem like ext is being actively developed,maintained and new features being added to it. While filesystems are being supported and actively developed,maintained and new features added to them you hardly can consider them not part of the future now can you despite their shortcomings compared to eachother. It is more about that: A filesystem which requires an out-of-kernel fsck, but has no proper indication in the superblock to indicate that, and integrates that way with its own fsck tool, is nothing systemd needs to work around. If the filesystem wants better integration, it has to provide the needed features not rely on hacks on mis-use of other facilities like EFI or the kernel cmdline, or flag files, to cover for the missing feature. At a general level, an out-of-kernel fsck for a filesystem used as the rootfs soulds really really weird in the year 2015. And this is not neccessarily about btrfs, xfs solved that problem many many years ago. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
On Thu, Apr 09, 2015 at 05:20:43PM +0200, Michal Sekletar wrote:
On Thu, Apr 09, 2015 at 02:44:38PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 04:35:53PM +0200, Michal Sekletar wrote:
On Thu, Apr 09, 2015 at 02:10:14PM +, Zbigniew Jędrzejewski-Szmek
wrote:
On Thu, Apr 09, 2015 at 03:20:02PM +0200, Michal Sekletar wrote:
Users might have hard time figuring out why exactly their systemctl
request
failed. If dbus job fails try to figure out more details about
failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c
b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char
**result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+
org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs
*d, bool quiet) {
log_error(Operation on or unit type of %s
not supported on this system., strna(d-name));
else if (!streq(d-result, done)
!streq(d-result, skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d,
result);
+if (q 0)
+log_debug_errno(q, Failed
to get Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See
\systemctl status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : ,
d-name, quotes ? ' : );
+
log_job_error_with_service_result(d-name, result);
} else
log_error(Job failed. See
\journalctl -xe\ for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const
struct signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
dbus property returns the result as a string. So we need to map this
string
to an explanation. Going through the intermediate ServiceResult int does
not really gain
Re: [systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
On Thu, Apr 09, 2015 at 02:10:14PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 03:20:02PM +0200, Michal Sekletar wrote:
Users might have hard time figuring out why exactly their systemctl request
failed. If dbus job fails try to figure out more details about failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c
b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char **result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+ org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs *d,
bool quiet) {
log_error(Operation on or unit type of %s not
supported on this system., strna(d-name));
else if (!streq(d-result, done) !streq(d-result,
skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d, result);
+if (q 0)
+log_debug_errno(q, Failed to get
Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See
\systemctl status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : , d-name,
quotes ? ' : );
+log_job_error_with_service_result(d-name,
result);
} else
log_error(Job failed. See \journalctl
-xe\ for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const struct
signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
dbus property returns the result as a string. So we need to map this string
to an explanation. Going through the intermediate ServiceResult int does
not really gain anything... I think things would be simpler if you added a
table mapping result to explanation:
static const struct {
const char *result, *explanation;
} explanations[] = {
{timeout, start timeout was exceeded},
...
{}
};
and then simply looped over this table. This way it won't be necessary to
have three different lists.
I guess that what you are suggesting will remove a bit of boilerplate code, will
do that.
This could live simply in systemctl.c. Those are only parts of
sentences, nothing generally useful.
I'd say that having general function for logging about failed dbus
Re: [systemd-devel] Boot ordering
On Thu, 09.04.15 12:26, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Thu, Apr 9, 2015 at 12:18 PM, Lennart Poettering lenn...@poettering.net wrote: order it after the precise units you need from early boot, This is fragile because it will break every time precise units change. This is exact reason why we have systemd.special man page at all - to provide high level synchronization points that are not affected by underlying implementation change. The problem is, systemd does not allow to insert something *between* two synchronization points without knowing precise implementation. You seem to insist it is a feature. Hmm? I am not sure I follow... I mean, as I explained you can insert your stuff between sysinit.target+local-fs.target and basic.target. In general: if you don't want to care about precise deps, then use socket activation and set DefaultDependencies=yes, and all is good. That's what I recommend to do. If you want to fiddle with the deps, then you get to keep the pieces, and you have to know what you do, and know what you need to depend on. It's a fair deal I think. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: Implement fallback DHCPv6 prefix handling for older kernels
On Thu, 2015-04-09 at 12:43 +0200, Lennart Poettering wrote: Hmm, in general, we really should try to create the same binaries, regardless if we are built on an old or new kernel. And the binaries should work as good as possible, regardless which kernel version they are running on. But with the change above the binary built on a newer kernel work differently from an older kernel, even though we added the definition to missing.h to make the distinction go away... Or in other words: we try to do runtime compat, not just compile time compat, so that we don't strictly have to sync kernel and userspace updated. Hmm, I was suspecting that for a moment. I need to come up with a better runtime solution for version 2 of the patch then. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] log: be more verbose if dbus job fails
Users might have hard time figuring out why exactly their systemctl request
failed. If dbus job fails try to figure out more details about failure by
examining Result property of the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1016680
---
src/libsystemd/sd-bus/bus-util.c | 41 +++---
src/shared/log.c | 76
src/shared/log.h | 2 ++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index 6498769..bb4c993 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -30,6 +30,7 @@
#include path-util.h
#include missing.h
#include set.h
+#include unit-name.h
#include sd-bus.h
#include bus-error.h
@@ -1716,6 +1717,35 @@ static int bus_process_wait(sd_bus *bus) {
}
}
+static int bus_job_get_service_result(BusWaitForJobs *d, char **result) {
+int r = 0;
+_cleanup_free_ char *dbus_path = NULL, *p = NULL;
+
+assert(d);
+assert(d-result);
+assert(d-name);
+assert(result);
+
+dbus_path = unit_dbus_path_from_name(d-name);
+if (!dbus_path)
+return -ENOMEM;
+
+r = sd_bus_get_property_string(d-bus,
+ org.freedesktop.systemd1,
+ dbus_path,
+ org.freedesktop.systemd1.Service,
+ Result,
+ NULL,
+ p);
+if (r 0)
+return r;
+
+*result = p;
+p = NULL;
+
+return 0;
+}
+
static int check_wait_response(BusWaitForJobs *d, bool quiet) {
int r = 0;
@@ -1736,13 +1766,14 @@ static int check_wait_response(BusWaitForJobs *d, bool
quiet) {
log_error(Operation on or unit type of %s not
supported on this system., strna(d-name));
else if (!streq(d-result, done) !streq(d-result,
skipped)) {
if (d-name) {
-bool quotes;
+int q;
+_cleanup_free_ char *result = NULL;
-quotes = chars_intersect(d-name,
SHELL_NEED_QUOTES);
+q = bus_job_get_service_result(d, result);
+if (q 0)
+log_debug_errno(q, Failed to get
Result property of service %s: %m, d-name);
-log_error(Job for %s failed. See \systemctl
status %s%s%s\ and \journalctl -xe\ for details.,
- d-name,
- quotes ? ' : , d-name, quotes ?
' : );
+log_job_error_with_service_result(d-name,
result);
} else
log_error(Job failed. See \journalctl -xe\
for details.);
}
diff --git a/src/shared/log.c b/src/shared/log.c
index 646a1d6..3219756 100644
--- a/src/shared/log.c
+++ b/src/shared/log.c
@@ -1061,3 +1061,79 @@ void log_received_signal(int level, const struct
signalfd_siginfo *si) {
void log_set_upgrade_syslog_to_journal(bool b) {
upgrade_syslog_to_journal = b;
}
+
+typedef enum ServiceResult {
+SERVICE_SUCCESS,
+SERVICE_FAILURE_RESOURCES,
+SERVICE_FAILURE_TIMEOUT,
+SERVICE_FAILURE_EXIT_CODE,
+SERVICE_FAILURE_SIGNAL,
+SERVICE_FAILURE_CORE_DUMP,
+SERVICE_FAILURE_WATCHDOG,
+SERVICE_FAILURE_START_LIMIT,
+_SERVICE_RESULT_MAX,
+_SERVICE_RESULT_INVALID = -1
+} ServiceResult;
+
+static const char* const service_result_table[_SERVICE_RESULT_MAX] = {
+[SERVICE_SUCCESS] = success,
+[SERVICE_FAILURE_RESOURCES] = resources,
+[SERVICE_FAILURE_TIMEOUT] = timeout,
+[SERVICE_FAILURE_EXIT_CODE] = exit-code,
+[SERVICE_FAILURE_SIGNAL] = signal,
+[SERVICE_FAILURE_CORE_DUMP] = core-dump,
+[SERVICE_FAILURE_WATCHDOG] = watchdog,
+[SERVICE_FAILURE_START_LIMIT] = start-limit
+};
+
+DEFINE_PRIVATE_STRING_TABLE_LOOKUP_FROM_STRING(service_result, ServiceResult);
+
+static const char* const
service_result_error_message_table[_SERVICE_RESULT_MAX] = {
+[SERVICE_FAILURE_RESOURCES] = configured resource limit was exceeded,
+[SERVICE_FAILURE_TIMEOUT] = start timeout was exceeded,
+[SERVICE_FAILURE_EXIT_CODE] = ExecStart process exited with error
code,
+[SERVICE_FAILURE_SIGNAL] = fatal signal was delivered to ExecStart
process,
+[SERVICE_FAILURE_CORE_DUMP] = fatal signal was delivered to ExecStart
process. Core dumped,
+[SERVICE_FAILURE_WATCHDOG] = service failed to sent watchdog ping,
+
Re: [systemd-devel] regarding to cgroup siblings mask
On Thu, 09.04.15 14:10, WaLyong Cho (walyong@samsung.com) wrote: In recent systemd(from some month ago), when a unit has a mask for cpu or blockio or memory, this mask is also propagated to siblings by unit_get_target_mask(). According to some of comments, it seems intentional. Could anyone explain why? I added this after talking to Tejun. It's basically what the kernel will effectively do in sane behaviour mode too. Basically, the kernel really wants to avoid having to compare individual processes against groups, because behaviour is unclear then. They want to comapre groups against groups and processes against processes, but not groups against processes, since in many cases behaviour is very unclear then. To avoid the ambighities this creates entirely the answer is to not allow this, and hence always propagate all controller memberships not only towards the root, but also sideways. OK, understood but I'm not sure the compare group properties came under for all of cgroup subsystem. In case of CPUShares=, BlockIOWeight= such like take weight as value, should be. But in case of CPUQuota=, MemoryLimit=, it just a problems of own. Those are not racing with other groups. So for this kind of properties do not need to be propagated to siblings. I'm not sure this make sense. But if yes, below patch will only propagate proportional or relative properties. http://lists.freedesktop.org/archives/systemd-devel/2015-March/029885.html Well, it's a matter of clean design really. Sure, if a controller doesn't have proportional props it's not that important, but it is a much simpler design to disallow processes and cgroups on the same level in the tree, and it's going to be what the sane behaviour cgroup rework of the kernel does... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
Am 09.04.2015 um 18:52 schrieb Kay Sievers: On Thu, Apr 9, 2015 at 3:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: We generally follow the rule: we develop for the future, not for the past. A file system like ext234 is clearly not the future, A filesystem like ext is being actively developed,maintained and new features being added to it. While filesystems are being supported and actively developed,maintained and new features added to them you hardly can consider them not part of the future now can you despite their shortcomings compared to eachother. It is more about that: A filesystem which requires an out-of-kernel fsck, but has no proper indication in the superblock to indicate that, and integrates that way with its own fsck tool, is nothing systemd needs to work around. If the filesystem wants better integration, it has to provide the needed features not rely on hacks on mis-use of other facilities like EFI or the kernel cmdline, or flag files, to cover for the missing feature. At a general level, an out-of-kernel fsck for a filesystem used as the rootfs soulds really really weird in the year 2015. And this is not neccessarily about btrfs, xfs solved that problem many many years ago http://linux.die.net/man/8/xfs_check If the filesystem is very large (has many files) then xfs_check might run out of memory. In this case the message out of memory is printed sounds really so much better than ext4 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to set primary slave in active-backup mode (bonding)
I usually have two network interfaces on my laptops (one eth and one wlan), and when I was using sysvinit I also was configuring the bond interface via the /etc/network/interfaces file so the two interfaces could work in the active-backup mode. But now, they work in balance-rr mode which is set via the .netdev file. The problem with this mode is that when you have, let's say wifi 30mbit/s and wired 100mbit/s, you can get 60mbit/s max, and that's why I wanted to use the active-backup mode which switches from wire to wifi and vice versa depending on whether the ethernet cable is plugged in. Generally speaking, I have to set some additional parameters so this could work well, and that would be: ... bond-primary eth1 bond-primary-reselect always bond-slaves eth1 wlan0 bond-fail-over-mac none ... I'm not sure if all of them are necessary, and the question is how to pass these parameters in systemd? I'm asking because in the systemd.netdev manual, in the bond section, these options weren't specified. pgpl2qWMR7FIw.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Thu, Apr 9, 2015 at 6:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.04.2015 um 18:52 schrieb Kay Sievers: On Thu, Apr 9, 2015 at 3:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: We generally follow the rule: we develop for the future, not for the past. A file system like ext234 is clearly not the future, A filesystem like ext is being actively developed,maintained and new features being added to it. While filesystems are being supported and actively developed,maintained and new features added to them you hardly can consider them not part of the future now can you despite their shortcomings compared to eachother. It is more about that: A filesystem which requires an out-of-kernel fsck, but has no proper indication in the superblock to indicate that, and integrates that way with its own fsck tool, is nothing systemd needs to work around. If the filesystem wants better integration, it has to provide the needed features not rely on hacks on mis-use of other facilities like EFI or the kernel cmdline, or flag files, to cover for the missing feature. At a general level, an out-of-kernel fsck for a filesystem used as the rootfs soulds really really weird in the year 2015. And this is not neccessarily about btrfs, xfs solved that problem many many years ago http://linux.die.net/man/8/xfs_check If the filesystem is very large (has many files) then xfs_check might run out of memory. In this case the message out of memory is printed sounds really so much better than ext4 Yeah, that is why Red Hat Enterprise Linux uses XFS as the default. Too bad for them that they did not ask for you valuable expert advise. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting in a network name?
Lennart Poettering lennart at poettering.net writes: On Mon, 06.01.14 11:04, Holger Schurig (holgerschurig at gmail.com) wrote: Hi, I used ip netns commands to setup several network namespaces. Now I want to run a user-space (non-root) in one of those netspaces. ip netns exec NAME COMMAND seems to only work for root, not normal users. Is there a way to configure a systemd unit to run in a *specific* network namespace? I mean similar to, but more general than, PrivateNetwork=true and JoinsNamespaceOf= ... No, this is currently not available. But certainly doable. I added it to the TODO list now. Following on this older email thread, did this get implemented?.. What is the current preferred mechanism to start services in different netns? We are doing with 'ip netns exec .. command in the ExecStart for systemD. s there any other options? Thanks, -Vinay. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
On Thu, 09.04.15 10:51, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: My above questions where directed directly at Lennart since you cannot know if Lennart's assumption which he bases his decisions on are premature,correct, wrong or misguided until you know what those assumptions are. Once those assumptions are known one can compare it with ones own as well as facts and have a higher level discussion about what makes suitable upstreams defaults and why. We generally follow the rule: we develop for the future, not for the past. A file system like ext234 is clearly not the future, the concept of requiring fsck on dirty is just broken with today's large disks. Now, of course we will continue to support ext234, and fsck and stuff. However, we will not add *new* features to this scheme, since the whole idea of having something like this at all is yesterday's idea. Sure, btrfs is not particularly stable yet, but that hardly matters, as not even xfs requires such an fsck scheme anymore! I mean, it's really ext234 and vfat that require this, no other commonly used fs does. And those we can support just fine with the status quo, and don't need to invent completely new logic for it. We will not add completely new features to the old stuff, if we already know *now* that the old stuff is a dead end, and things are already good enough in the area, and the future will make the whole problem go away. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
