Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd
On Wed, May 20, 2015 at 8:24 AM, Martin Pitt martin.p...@ubuntu.com wrote: Hey David, David Herrmann [2015-05-19 17:06 +0200]: We're about to remove gudev from the systemd repository, as it is in no way related to the systemd code-base, nor used by the systemd project. This makes sense indeed. gudev used to be a standalone project before it was merged into udev, so the circle is complete now :-) For those of us who already packaged gudev from systemd 219, would it be possible to bump the current release to 220, so that gudev can be packaged without renaming the tarball and doing ugly version numbers? Monotonously increasing version numbers and all.. (Yes, there are epochs in Debian, and I'm sure RPM has these too, but they might not be available everywhere and are generally frowned upon) While you are at it, why not bump it to 225 or something (just to guarantee that the last systemd release with gudev has a lower version number than gudev at that time, so people can switch over whenever they want without having to worry about going backwards). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd
Hey David, David Herrmann [2015-05-19 17:06 +0200]: We're about to remove gudev from the systemd repository, as it is in no way related to the systemd code-base, nor used by the systemd project. This makes sense indeed. gudev used to be a standalone project before it was merged into udev, so the circle is complete now :-) For those of us who already packaged gudev from systemd 219, would it be possible to bump the current release to 220, so that gudev can be packaged without renaming the tarball and doing ugly version numbers? Monotonously increasing version numbers and all.. (Yes, there are epochs in Debian, and I'm sure RPM has these too, but they might not be available everywhere and are generally frowned upon) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tentative state and unmount on mapper
On Mon, May 18, 2015 at 3:59 PM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: Hi, There have been few discussions about tentative state and unmounting and I am experiencing different problem in the same device logic. I am at 219 + 628c89cc + 496068a8 + 5259bcf6 I have 2 mounts (one is bind mount) on mapper device. /proc/self/mountinfo: 47 37 254:0 / /var/spool/storage/SD_DISK rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered systemctl -t device --all | grep map: dev-mapper-mmcblk0p1.device loaded activating tentative /dev/mapper/mmcblk0p1 As soon as I unmount the bind mount, systemd picks up the change in /proc/self/mountinfo and changes the tentative device to dead and due to that all file systems BindsTo to the device are being unmounted. Application which mounted the partitions is not getting a chance to unmount the fs. Should I enumerate available mount units to see if anyone else has been mounted on the device that is about to be set as DEVICE_DEAD in device_update_found_one()? For the achieve purpose, Lennart has implemented something similar at 394763f6 and fcd8b266. Things have worked for me. But the proper solution is enabling udev awareness for DM/LVM. Umut Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd
Hi On Wed, May 20, 2015 at 8:46 AM, Tom Gundersen t...@jklm.no wrote: On Wed, May 20, 2015 at 8:24 AM, Martin Pitt martin.p...@ubuntu.com wrote: Hey David, David Herrmann [2015-05-19 17:06 +0200]: We're about to remove gudev from the systemd repository, as it is in no way related to the systemd code-base, nor used by the systemd project. This makes sense indeed. gudev used to be a standalone project before it was merged into udev, so the circle is complete now :-) For those of us who already packaged gudev from systemd 219, would it be possible to bump the current release to 220, so that gudev can be packaged without renaming the tarball and doing ugly version numbers? Monotonously increasing version numbers and all.. (Yes, there are epochs in Debian, and I'm sure RPM has these too, but they might not be available everywhere and are generally frowned upon) While you are at it, why not bump it to 225 or something (just to guarantee that the last systemd release with gudev has a lower version number than gudev at that time, so people can switch over whenever they want without having to worry about going backwards). I intend to apply patches to systemd-git until we finally removed it there. Given that we had 0 patches so far this year, it'll probably stay that way. Hence, there's no hurry in replacing gudev from systemd with libgudev. It'd be enough to just drop the systemd sub-package and provide a new libgudev package, even if that might not forcefully update the package. However, I see no reason not to bump it, so I'll gladly follow the packager's demands: https://github.com/systemd-devs/libgudev/commit/f6203336e5b1ccf896acc506b54ec895fdae98b4 @Bastien: At your convenience, can you cherry-pick this and do another release? Should have done this right away, sorry! Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
Hello Frank and systemd devs,
frank.thalberg at tuta.io [2015-04-12 20:51 +]:
This fixes an issue within journald aborting when running inside
archlinux container via systemd-nspawn on a debian host with audit
enabled kernel.
We have exactly the same problem with both standard nspawn as well as
user LXC containers. This completely breaks journalling in containers
and also prints a lot of error messages.
Using audit=0 on the host is not satisfying, though:
- It's hard to discover
- There is no reason to disable audit support on the host when all
you need to do is to unbreak containers and disable auditing there.
- We don't want admins to create static configs which are (1)
always the same workaround everywhere, and (2) become obsolete once
the kernel is fixed.
So I'd rather have a dynamic solution. Your patch works, but I don't
like it that much:
+ if (errno == EPERM detect_container(NULL) 0) {
+ log_debug(Audit not supported in
containers.);
+ return 0;
+ }
The detect_container() check is not really related to the question
does audit work. It's certainly that way today, but future kernels
might change this.
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1585,9 +1585,11 @@ int server_init(Server *s) {
if (r 0)
return r;
+#ifdef HAVE_AUDIT
r = server_open_audit(s);
if (r 0)
return r;
+#endif
This would require statically enabling/disabling the complete audit
support in the systemd package, while we can do this check at runtime
without much effort.
Also, with your patch you merely unbreak journald itself, but
systemd-journald-audit.socket and other units which have
ConditionSecurity=audit will still fail.
I created a patch which is a more direct approach which makes the
ConditionSecurity=audit check more thorough and actually working in
containers. With that I can leave audit enabled on the host,
containers will boot fine (including journalling) without audit
support, and as soon as the kernel gets fixed it'll automagically start
working in containers as well.
Lennart, WDYT?
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 4900d31e22719464ed7208c7013730acb551d961 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 20 May 2015 13:36:45 +0200
Subject: [PATCH] audit: Fix journal failing on unsupported audit in containers
Commit cfb1f5df introduced ConditionSecurity=audit via use_audit(). However,
use_audit() is still true in namespaces like nspawn containers as there
creating an audit socket succeeds. What fails in journald is binding to it
(Permission denied). So make the check more thorough to only declare that
audit is supported when bind() works as well. This is now exactly the same
check as journald does.
In journald, check use_audit() to see if auditing is supported before we
actually try to bind to the audit socket (as that will fail hard in
namespaces).
This avoids a failing journald and systemd-journald-audit.socket in nspawn and
similar environments. If/once the kernel gets proper auditing support for
namespaces, this will magically start to work without further changes.
Adjust README accordingly.
---
README | 18 --
src/journal/journald-audit.c | 5 +
src/shared/audit.c | 9 -
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/README b/README
index 039110e..da7a86a 100644
--- a/README
+++ b/README
@@ -97,20 +97,6 @@ REQUIREMENTS:
CONFIG_EFIVAR_FS
CONFIG_EFI_PARTITION
-Note that kernel auditing is broken when used with systemd's
-container code. When using systemd in conjunction with
-containers, please make sure to either turn off auditing at
-runtime using the kernel command line option audit=0, or
-turn it off at kernel compile time using:
- CONFIG_AUDIT=n
-If systemd is compiled with libseccomp support on
-architectures which do not use socketcall() and where seccomp
-is supported (this effectively means x86-64 and ARM, but
-excludes 32-bit x86!), then nspawn will now install a
-work-around seccomp filter that makes containers boot even
-with audit being enabled. This works correctly only on kernels
-3.14 and newer though. TL;DR: turn audit off, still.
-
glibc = 2.16
libcap
libmount = 2.20 (from util-linux)
@@ -249,6 +235,10 @@ WARNINGS:
false positives will be triggered by code which violates
some rules but is actually safe.
+Kernel auditing is broken when used with systemd's container
+code. journal support for audit messages will not be available
Re: [systemd-devel] [PATCH/resend] Use reflinking to copy kernel
On Tue, 19.05.15 02:33, Pádraig Brady (p...@draigbrady.com) wrote: FYI... mv reflinks by default, but only in the unreleased V8.24 (Fedora 23). cp doesn't default to --reflink=auto as that would break the case where one uses copy for durability reasons to have a second copy of the data. Also for performance reasons you may want the writes to happen at copy time rather than some latency sensitive process working on a CoW file and being delayed by the writes possibly to a different part of a mechanical disk. I am pretty sure that both those usecases are of the more exotic kind, and that reflinks should hence be the default, and people who want the byte-by-byte kind of copy should request it explicitly with --reflink=no or dd. I think a good user interface make the common operations easy (and hence default) and the exotic ones possible. For me that clearly means that --reflink=auto should be the default, and --reflink=no the option, and *not* the other way round... 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] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150520115326.GA32127%40piware.de -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timers and Service Conditions
Hi, I am running version 216. I will try to reproduce it using a newer version when I got some spare time. I tried to reproduce it and I had, at first, some problems. But here are the steps that I used: * Enable autobackup@merten.timer * Restart system with AC connected * Let the timer activate once * Disconnect AC * Wait for next timer trigger After the timer elapsed the dbus-daemon fully utilizes the CPU with messages like the following: signal sender=:1.0 - dest=(null destination) serial=5611797 path=/org/freedesktop/systemd1/unit/autobackup_40merten_2etimer; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged string org.freedesktop.systemd1.Timer array [ dict entry( string NextElapseUSecRealtime variant uint64 0 ) dict entry( string NextElapseUSecMonotonic variant uint64 1671969806 ) dict entry( string LastTriggerUSec variant uint64 1432119664109599 ) dict entry( string LastTriggerUSecMonotonic variant uint64 1820165195 ) dict entry( string Result variant string success ) ] array [ string TimersMonotonic string TimersCalendar ] Attached you find the service and timer units that I used. Thanks On 19/05/15 16:57, Lennart Poettering wrote: On Thu, 02.04.15 12:01, Merten Sach (mer...@tabinin.eu) wrote: Hi, I have a problem with a timer that trigges a service that has a condition set. The timer defines the following properties: [Timer] OnBootSec=1h OnUnitInactiveSec=1h Unit=autobackup@%i.service The service unit set the following condition: ConditionACPower=true When I'm now on AC power the service is never active and, therefor, the inactive timestamp is never set. This causes the timer to be triggered repeatedly which causes a very high system load. I want to keep the timer relative to bootup. So, can I avoid OnCalendar= ? Hmm, so I tried to reproduce this issue here, bu I couldn't. I used the same unit files as you propose, but this works cleanly, as the code already contains checks that if the triggered unit doesn't have an initialized inactive timestamp we'll fall back to the last trigger time of the unit. And if that's not set, we'll simply not set any timer... Hence, which version of systemd did you run this into with? Any chance you can check if you can reproduce this with current git or at least 219? Lennart [Unit] Description=autobackup service Documentation= Wants=avahi-daemon.socket ConditionACPower=true [Service] Type=simple User=%i ExecStart=/usr/bin/true #ExecStart=/usr/local/bin/autobackup [Unit] Description=autobackup timer Documentation= [Timer] OnBootSec=3m OnUnitInactiveSec=3m Unit=autobackup@%i.service [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] WIP: conf-parser: allow config_parse_iec_off to parse percentages
On Wed, 20.05.15 10:37, jsyna...@redhat.com (jsyna...@redhat.com) wrote:
From: Jan Synacek jsyna...@redhat.com
Allow certain configuration options to be specified as percentages. For
example, in journald.conf, SystemMaxUse= can now also be specified as 33%.
There is a slight problem with the patch. It parses option names to
determine
what filesystem it should use to get the available space from. This approach
is probably not the rigth thing to do, but I couldn't think of a better one.
Another approach that came to my mind was to use the highest bit of the off_t
value returned by the parser to indicate if the value was a percentage, or
a normal value. This would require to rewrite a significant amount of code
which now counts on the values being definite (not percentages), and would,
IMHO, be hardly any improvement at all.
What do you think? Is there a better way to implement this functionality? Is
it
a real problem to parse the option lvalues like that?
Yes, it's ugly! Also, it's problematic since disk sizes and space
change dynamically, hence evaluating this only when parsing is not
enough.
What about this: introduce a new type:
typedef struct SizeParameter {
uint64_t value;
bool relative;
} SizeParameter;
When .relative is false, then .value is an absolute value, otherwise
it's a relative value normalized to let's say 0x1 (so that
this value equals 100%, and values below it 100% and above it
100%).
Then add new helper calls:
int size_parameter_from_string(const char *s, SizeParameter *ret);
uint64 size_parameter_evaluate(SizeParameter *p, uint64_t base);
The latter should return .value as-is if p-relative is false, and
(base * .value) 32 otherwise.
THen, change the appropriate places to use SizeParameter instead of
simple uint64_t where necessary, and use size_parameter_evaluate()
with the data from statvfs when the actual value is required.
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-udev causes slow boot and high load
Am 19.05.2015 um 18:32 schrieb Marco Steinacher: Am 19.05.2015 um 12:37 schrieb Lennart Poettering: On Tue, 19.05.15 12:02, Marco Steinacher (mailingli...@websource.ch) wrote: Hi, After upgrading my system to Debian jessie and switching to systemd I have the following problem: 1. During boot there is the message [**] A start job is running for udev Wait for Complete De...on (11s / 3min) after systemd-fsck[452]: /dev/sda5: clean and it takes about 2 minutes until the boot process continues. systemd-analyze blame shows: 2min 2.945s systemd-udev-settle.service systemd-udev-settle.service just waits for devices to be probed. It will wait for the kernel drivers to initialize and the udev rules to be pliugged in. In fact, there's really no need to have this in the boot process at all, unless you are using some broken software that assumes that there's a point in time where all hardware has been plugged in, but such a point in time does not actually exist, and hasn't existed in a long time (simply because USB and other busses can take any time they want before initialization is complete and the devices have shown up). 2. dmesg also shows: [ 254.305831] INFO: task systemd-udevd:296 blocked for more than 120 seconds. [ 254.305962] Not tainted 3.16.0-4-686-pae #1 [ 254.306069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 254.306165] systemd-udevd D 0 296234 0x0004 and similar messages for the tasks systemd-udevd:308 and systemd-udevd:307. The messages repeat a couple of times (see full log below). There you go: your kernel is hung, some driver or your xen irq handling is borked and hangs during initialization. This is a kernel problem, please report this to the kernel bugzilla. Thank you for the swift reply and for clarifying the situation. I understand now that this is a kernel issue and not a problem with systemd. I'll try to track down the kernel issue now. Just for the record - in case somebody faces a similar issue and stumbles upon this thread: I solved the problem. It was embarrassingly simple: Loading the I2C driver JC42 with kernel 3.16.0 caused the irq 16: nobody cared issue and the subsequent timeouts. Removing the module jc42 from /etc/modules solved it! Thanks again and sorry for the noise on the wrong mailing list, Marco -- OpenPGP Key ID: 0x62937F7F ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] WIP: conf-parser: allow config_parse_iec_off to parse percentages
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432111062-22923-2-git-send-email-jsynacek%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] WIP: conf-parser: allow config_parse_iec_off to parse percentages
From: Jan Synacek jsyna...@redhat.com Allow certain configuration options to be specified as percentages. For example, in journald.conf, SystemMaxUse= can now also be specified as 33%. There is a slight problem with the patch. It parses option names to determine what filesystem it should use to get the available space from. This approach is probably not the rigth thing to do, but I couldn't think of a better one. Another approach that came to my mind was to use the highest bit of the off_t value returned by the parser to indicate if the value was a percentage, or a normal value. This would require to rewrite a significant amount of code which now counts on the values being definite (not percentages), and would, IMHO, be hardly any improvement at all. What do you think? Is there a better way to implement this functionality? Is it a real problem to parse the option lvalues like that? Jan Synacek (1): WIP: conf-parser: allow config_parse_iec_off to parse percentages src/shared/conf-parser.c | 42 ++ 1 file changed, 38 insertions(+), 4 deletions(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] WIP: conf-parser: allow config_parse_iec_off to parse percentages
From: Jan Synacek jsyna...@redhat.com
---
src/shared/conf-parser.c | 42 ++
1 file changed, 38 insertions(+), 4 deletions(-)
diff --git a/src/shared/conf-parser.c b/src/shared/conf-parser.c
index 2c85515..d7d9aa4 100644
--- a/src/shared/conf-parser.c
+++ b/src/shared/conf-parser.c
@@ -23,6 +23,7 @@
#include stdio.h
#include errno.h
#include stdlib.h
+#include sys/statvfs.h
#include conf-parser.h
#include conf-files.h
@@ -517,6 +518,37 @@ int config_parse_si_size(const char* unit,
return 0;
}
+static int parse_percent(const char *lvalue, const char *rvalue, off_t *bytes)
{
+char *p, *e;
+off_t percent;
+struct statvfs ss;
+
+p = endswith(rvalue, %);
+if (!p)
+return -ERANGE;
+
+percent = strtoll(rvalue, e, 10);
+if (*e != '%' || e != p)
+return -ERANGE;
+
+if (percent 100)
+return -ERANGE;
+
+if (!startswith(lvalue, System) !startswith(lvalue, Runtime)) {
+if (statvfs(/var/lib/systemd/coredump, ss) 0)
+return -errno;
+} else if (startswith(lvalue, System)) {
+if (statvfs(/var/log/journal, ss) 0)
+return -errno;
+} else
+if (statvfs(/run/log, ss) 0)
+return -errno;
+
+*bytes = percent * 0.01 * ss.f_bsize * ss.f_bavail;
+
+return 0;
+}
+
int config_parse_iec_off(const char* unit,
const char *filename,
unsigned line,
@@ -538,10 +570,12 @@ int config_parse_iec_off(const char* unit,
assert_cc(sizeof(off_t) == sizeof(uint64_t));
-r = parse_size(rvalue, 1024, bytes);
-if (r 0)
-log_syntax(unit, LOG_ERR, filename, line, -r, Failed to parse
size value, ignoring: %s, rvalue);
-
+r = parse_percent(lvalue, rvalue, bytes);
+if (r 0) {
+r = parse_size(rvalue, 1024, bytes);
+if (r 0)
+log_syntax(unit, LOG_ERR, filename, line, -r, Failed
to parse size value, ignoring: %s, rvalue);
+}
return 0;
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
On Wed, 20.05.15 13:53, Martin Pitt (martin.p...@ubuntu.com) wrote:
-cached_use = true;
+/* bind() fails in namespaces (containers), so check
that too */
+static const union sockaddr_union sa = {
+.nl.nl_family = AF_NETLINK,
+.nl.nl_pid= 0,
+.nl.nl_groups = AUDIT_NLGRP_READLOG,
+};
+cached_use = (bind(fd, sa.sa, sizeof(sa.nl)) = 0);
safe_close(fd);
This check is simply not right. With that you check whether the
multicast audit API is available. But given that it has been added
only one or two kernel releases ago, and is protected by its own
capabality the check is definitely too broad.
The fact is simply that the kernel audit subsystem is borked in the
kernel when it comes to namespacing, and there's no nice way to detect
whether it is borked I am aware of.
And it's not really about this multicast journald feature only. Sooner
or later you will run into other problems: any fedora-based distro
will not allow you to even log in in the container if you leave audit
on in the kernel, and don#t use the seccomp hack we have in place (for
example, because you are on 32bit x86, or because your distro turned
it off).
We could of course add a detect_container() check now to journald. But
I think that would be a big mistake, since there was work on fixing
audit in the kernel for containers (by adding audit namespacing or
so). And we should try to write our code so that things will start
working when the kernel is fixed, but a detect_container() check would
make that impossible.
Anyway, I think people are mostly concerned about bind() failing here,
hence I have now added some code to handle that gracefully.
Right now it will still log a message with LOG_WARNING. I'd be willing
to downgrade this to LOG_DEBUG for select error codes, if you tell me
the ones you run into. EINVAL?
Also, please convince your distro to enable seccomp support!
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 v4] nvme_id utility + support in 60-persistent-storage.rules
On Mon, 18.05.15 22:43, Per Bergqvist (p...@bst.lu) wrote:
heya,
I talked to Kay now. He suggested that we should not add new xyz_id
tools anymore to udev, but actually rather remove more of them, and
have the kernel drivers export everything via sysfs, so that the
fields can be directly be accessed with ATTRS{} and $attrs{}, without
indirecting things via another tool, and more udev properties.
He suggested two options:
a) the preferred one: update the kernel driver to export the relevant
fields in sysfs, so that udev can read them from there. when that's
in place we can hook that up from udev without any new C code, and
all is great.
b) maintain this outside of udev: introduce a new package nvme-tools
or so, ship the tool there, and ask distros to add that to their
base set of tools.
Of course, a) is much preferrably I think, and the kernel patch
shouldn't be particularly complex...
Sorry for the delay, and for putting this through multiple rouns of
reviews before then denying that...
Sorry!
Lennart
---
Makefile.am | 11 +++
rules/60-persistent-storage.rules | 5 ++
src/udev/nvme_id/nvme_id.c| 147
++
3 files changed, 163 insertions(+)
create mode 100644 src/udev/nvme_id/nvme_id.c
diff --git a/Makefile.am b/Makefile.am
index bf04d31..0de0d18 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3904,6 +3904,17 @@ dist_udevrules_DATA += \
rules/60-persistent-v4l.rules
#
--
+nvme_id_SOURCES = \
+ src/udev/nvme_id/nvme_id.c
+
+nvme_id_LDADD = \
+ libudev-internal.la \
+ libsystemd-shared.la
+
+udevlibexec_PROGRAMS += \
+ nvme_id
+
+#
--
accelerometer_SOURCES = \
src/udev/accelerometer/accelerometer.c
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index 25b44a5..d3368a5 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -42,6 +42,11 @@ KERNEL==cciss*, ENV{DEVTYPE}==disk,
ENV{ID_SERIAL}!=?*, IMPORT{program}=s
KERNEL==sd*|sr*|cciss*, ENV{DEVTYPE}==disk, ENV{ID_SERIAL}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}
KERNEL==sd*|cciss*, ENV{DEVTYPE}==partition, ENV{ID_SERIAL}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n
+# NVMe
+KERNEL==nvme*, ENV{ID_SERIAL}!=?*, IMPORT{program}=nvme_id --export
$devnode
+KERNEL==nvme*, ENV{DEVTYPE}==disk, ENV{ID_SERIAL}==?*,
SYMLINK+=disk/by-id/nvme-$env{ID_SERIAL}
+KERNEL==nvme*, ENV{DEVTYPE}==partition, ENV{ID_SERIAL}==?*,
SYMLINK+=disk/by-id/nvme-$env{ID_SERIAL}-part%n
+
# firewire
KERNEL==sd*[!0-9]|sr*, ATTRS{ieee1394_id}==?*,
SYMLINK+=disk/by-id/ieee1394-$attr{ieee1394_id}
KERNEL==sd*[0-9], ATTRS{ieee1394_id}==?*,
SYMLINK+=disk/by-id/ieee1394-$attr{ieee1394_id}-part%n
diff --git a/src/udev/nvme_id/nvme_id.c b/src/udev/nvme_id/nvme_id.c
new file mode 100644
index 000..c61b0b8
--- /dev/null
+++ b/src/udev/nvme_id/nvme_id.c
@@ -0,0 +1,147 @@
+/* -*- mode:c; tab-width:8; intent-tabs-mode:nil; -*-
+ *
+ * nvme_id - reads model/serial/firmware revision numbers from nvme drives
+ *
+ * Copyright (C) 2015 Per Bergqvist p...@bst.lu
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include stdint.h
+#include unistd.h
+#include fcntl.h
+#include ctype.h
+#include string.h
+#include errno.h
+#include getopt.h
+#include linux/nvme.h
+#include sys/ioctl.h
+#include sys/types.h
+#include sys/stat.h
+
+#include libudev.h
+#include libudev-private.h
+#include udev-util.h
+#include log.h
+
+static int nvme_identify(struct udev *udev, int fd, void *buf, size_t
buf_len) {
+struct nvme_admin_cmd command = {
+.opcode = nvme_admin_identify,
+.addr = (unsigned long)buf,
+.data_len = buf_len,
+.cdw10= 1 };
+
+if (ioctl(fd, NVME_IOCTL_ADMIN_CMD, command) 0)
+return -errno;
+
+return 0;
+}
+
+int main(int argc, char *argv[]) {
+_cleanup_udev_unref_ struct udev *udev = NULL;
+
+struct nvme_id_ctrl nvme_id_ctrl = {};
+
Re: [systemd-devel] cp --reflink=auto by default
On Wed, 20.05.15 12:41, Pádraig Brady (p...@draigbrady.com) wrote: On 20/05/15 11:48, Lennart Poettering wrote: On Tue, 19.05.15 02:33, Pádraig Brady (p...@draigbrady.com) wrote: FYI... mv reflinks by default, but only in the unreleased V8.24 (Fedora 23). cp doesn't default to --reflink=auto as that would break the case where one uses copy for durability reasons to have a second copy of the data. Also for performance reasons you may want the writes to happen at copy time rather than some latency sensitive process working on a CoW file and being delayed by the writes possibly to a different part of a mechanical disk. I am pretty sure that both those usecases are of the more exotic kind, and that reflinks should hence be the default, and people who want the byte-by-byte kind of copy should request it explicitly with --reflink=no or dd. I think a good user interface make the common operations easy (and hence default) and the exotic ones possible. Well I certainly agree on that generic point: http://www.pixelbeat.org/docs/power_of_the_default.html For me that clearly means that --reflink=auto should be the default, and --reflink=no the option, and *not* the other way round... This is something we may consider changing in coreutils = 9. Especially considering data deduplication is being added to more and lower layers, which makes the first point about implicit bit duplication less valid. The performance concern is still valid, though again less so with SSDs. Well, sure, but it's a balance. It might make the later access a bit slower due to fragmentation, but cp itself would become a *ton* faster... 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] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
Lennart Poettering [2015-05-20 14:57 +0200]:
On Wed, 20.05.15 13:53, Martin Pitt (martin.p...@ubuntu.com) wrote:
-cached_use = true;
+/* bind() fails in namespaces (containers), so
check that too */
+static const union sockaddr_union sa = {
+.nl.nl_family = AF_NETLINK,
+.nl.nl_pid= 0,
+.nl.nl_groups = AUDIT_NLGRP_READLOG,
+};
+cached_use = (bind(fd, sa.sa, sizeof(sa.nl)) =
0);
safe_close(fd);
This check is simply not right. With that you check whether the
multicast audit API is available. But given that it has been added
only one or two kernel releases ago, and is protected by its own
capabality the check is definitely too broad.
OK. I thought the intention of ConditionSecurity=audit was exactly
that, as this condition was added together with adding it to
systemd-journald-audit.socket.
The fact is simply that the kernel audit subsystem is borked in the
kernel when it comes to namespacing, and there's no nice way to detect
whether it is borked I am aware of.
Right, hence my thinking was that we check for the things we actually
want to do with it.
We could of course add a detect_container() check now to journald. But
I think that would be a big mistake, since there was work on fixing
audit in the kernel for containers (by adding audit namespacing or
so).
Right, fully agreed. That's why I wrote that I didn't like Frank's original
patch.
Anyway, I think people are mostly concerned about bind() failing here,
hence I have now added some code to handle that gracefully.
Right now it will still log a message with LOG_WARNING. I'd be willing
to downgrade this to LOG_DEBUG for select error codes, if you tell me
the ones you run into. EINVAL?
bind(7, {sa_family=AF_NETLINK, pid=0, groups=0001}, 12) = -1 EPERM
(Operation not permitted)
With commit 417a7fdc journald now starts working, but
systemd-journald-audit.socket still fails:
Active: failed (Result: resources)
systemd[1]: systemd-journald-audit.socket: Socket service
systemd-journald.service already active, refusing.
systemd[1]: Failed to listen on Journal Audit Socket.
That's why I thought tightening the ConditionSecurity=audit check
would make more sense, as systemd-journald-audit.socket is the only
unit which actually uses it. We could add
ConditionVirtualization=!container to it as a distro-level workaround,
but I don't like that for the reasons above. I don't just want to
leave it like that as it makes the system stay in degraded mode.
Also, please convince your distro to enable seccomp support!
Fair enough, but that hack doesn't work on all platforms we support
(i386, powerpc, ppc64el, etc.), and quite frankly that's an even worse
hack: You'd need to disable that filter once the kernel gets fixed,
and/or conditionalize it based on the running kernel version. I'd like
the same code to work everywhere :-)
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] swap: use swapon -o
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432137260-585-1-git-send-email-kzak%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
On Tue, Apr 21, 2015 at 11:59 PM, Nick Owens misch...@offblast.org wrote: hello tom, On Mon, Apr 20, 2015 at 2:32 PM, Tom Gundersen t...@jklm.no wrote: On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau michael.marin...@coreos.com wrote: On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens misch...@offblast.org wrote: hi, sorry for the delay. from http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html: By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, *and for at least one link to gain a carrier.*. the import part here is the end of the sentence. without this patch, systemd-networkd-wait-online will block until all configured interfaces have carrier.. you can reproduce this by running systemd-networkd in qemu with two ethernet interfaces, and issue 'info network' and then 'set_link if down' to simulate no carrier. then you can run systemd-networkd-wait-online, and observe that it will block until both interfaces are up, not just one. nick On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov arvidj...@gmail.com wrote: On Wed, Mar 25, 2015 at 11:49 PM, misch...@offblast.org wrote: From: mischief misch...@offblast.org when checking interface status, systemd-networkd-wait-online will continue to wait if any interface is still configuring or being processed by udev. this patch allows it to return if any one interface is degraded/routable, as per the manual. But current behavior is exactly what manual says: By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed. Or do I miss something? It is worth noting that there may be some issues with tracking interface states in networkd, there appear to be ways to get an interface stuck in a 'configuring' state despite the fact that the interface has no network config and/or has no carrier. Do you have any more info on this? Can you reproduce with current git? There was a fix after the last release which should fix a problem with enumerating devices. the original issue was discussed at https://github.com/coreos/bugs/issues/279. i just tested commit cffacc741cb79f63999720525ceaa65aae01a542. https://github.com/coreos/init/blob/master/systemd/network/zz-default.network is our default for networkd. it seems logical that given this config, systemd-networkd-wait-online would wait for all of the dhcp interfaces, no matter how many. however, i'm not sure what use case there is for this. it seems like there's no way to wait for any one nic to be routeable/configured without knowing its name ahead of time. Correct. I mean, waiting for the system coming online like this is mostly a legacy thing, so we support this in a relatively limited way. Anything modern better explicitly listen for rtnl events and act accordingly. another instance of this problem is having a bridge like [NetDev] Name=br0 Kind=bridge and run 'systemctl restart systemd-networkd; /usr/bin/systemd-networkd-wait-online'. systemd-networkd-wait-online will not return. is this intended behavior? Hm, I'm not able to reproduce this. Can you still reproduce with git HEAD? If so what are the other config files that are applied, and what is the output of networkctl whilst wait-online is hanging? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
On Wed, 20.05.15 15:48, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-05-20 14:57 +0200]:
On Wed, 20.05.15 13:53, Martin Pitt (martin.p...@ubuntu.com) wrote:
-cached_use = true;
+/* bind() fails in namespaces (containers), so
check that too */
+static const union sockaddr_union sa = {
+.nl.nl_family = AF_NETLINK,
+.nl.nl_pid= 0,
+.nl.nl_groups = AUDIT_NLGRP_READLOG,
+};
+cached_use = (bind(fd, sa.sa, sizeof(sa.nl)) =
0);
safe_close(fd);
This check is simply not right. With that you check whether the
multicast audit API is available. But given that it has been added
only one or two kernel releases ago, and is protected by its own
capabality the check is definitely too broad.
OK. I thought the intention of ConditionSecurity=audit was exactly
that, as this condition was added together with adding it to
systemd-journald-audit.socket.
Nope, ConditionSecurity=audit is only a simple boolean check that
holds when audit is enabled at all. It doesn't tell you anything about
the precise audit feature set of the kernel.
Anyway, I think people are mostly concerned about bind() failing here,
hence I have now added some code to handle that gracefully.
Right now it will still log a message with LOG_WARNING. I'd be willing
to downgrade this to LOG_DEBUG for select error codes, if you tell me
the ones you run into. EINVAL?
bind(7, {sa_family=AF_NETLINK, pid=0, groups=0001}, 12) = -1 EPERM
(Operation not permitted)
With commit 417a7fdc journald now starts working, but
systemd-journald-audit.socket still fails:
Active: failed (Result: resources)
systemd[1]: systemd-journald-audit.socket: Socket service
systemd-journald.service already active, refusing.
systemd[1]: Failed to listen on Journal Audit Socket.
I have now conditionalized the unit on CAP_ADMIN_READ, which is the
cap that you need to read the audit multicast stuff. You container
manager hence should simply drop that cap fro, the cap set it passes
and all should be good.
I didn't test this though, hence please check if current git fixes
that for you now.
That's why I thought tightening the ConditionSecurity=audit check
would make more sense, as systemd-journald-audit.socket is the only
unit which actually uses it. We could add
ConditionVirtualization=!container to it as a distro-level workaround,
but I don't like that for the reasons above. I don't just want to
leave it like that as it makes the system stay in degraded mode.
Both conditions are now in place, and we need both: one can have the
cap without auditing being enabled, and auditing can be enabled
without the cap available, only if one has both the audit suff in
journal can work.
Also, please convince your distro to enable seccomp support!
Fair enough, but that hack doesn't work on all platforms we support
(i386, powerpc, ppc64el, etc.), and quite frankly that's an even worse
hack: You'd need to disable that filter once the kernel gets fixed,
and/or conditionalize it based on the running kernel version. I'd like
the same code to work everywhere :-)
Well, it's relatively simply fixing one container manager than all
userspaces that can run within it...
But anyway, please check if git works for you now.
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 v3] journalctl: Improve boot ID lookup
Works fine. Don't forget to close the bug, though. :P On 2015-05-19 00:37, Lennart Poettering wrote: On Fri, 01.05.15 15:15, Jan Janssen (medhe...@web.de) wrote: This method should greatly improve offset based lookup, by simply jumping from one boot to the next boot. It starts at the journal head to get the a boot ID, makes a _BOOT_ID match and then comes from the opposite journal direction (tail) to get to the end that boot. After flushing the matches and advancing the journal from that exact position, we arrive at the start of next boot. Rinse and repeat. This is faster than the old method of aggregating the full boot listing just so we can jump to a specific boot, which can be a real pain on big journals just for a mere -b -1 case. As an additional benefit --list-boots should improve slightly too, because it does less seeking. Note that there can be a change in boot order with this lookup method because it will use the order of boots in the journal, not the realtime stamp stored in them. That's arguably better, though. Another deficiency is that it will get confused with boots interleaving in the journal, therefore, it will refuse operation in --merge, --file and --directory mode. I have now applied this. Afterwards I added a couple of (mostly unrelated) clean-ups to journalctl. Would be nice if you could verify that things still work as intended! Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] swap: use swapon -o
This patch simplify swapon usage in systemd. The command swapon(8)
since util-linux v2.26 supports -o list. The idea is exactly the
same like for mount(8). The -o specifies options in fstab-compatible
way. For systemd it means that it does not have to care about things
like discard or another swapon specific options.
swapon -o options-from-fstab
For backward compatibility the code cares about Priority: swap unit
field (for a case when Priority: is set, but pri= in the Options: is
missing).
References:
http://lists.freedesktop.org/archives/systemd-devel/2014-October/023576.html
---
src/core/swap.c | 41 -
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/src/core/swap.c b/src/core/swap.c
index 12ebf84..658ac8b 100644
--- a/src/core/swap.c
+++ b/src/core/swap.c
@@ -717,8 +717,8 @@ fail:
}
static void swap_enter_activating(Swap *s) {
-_cleanup_free_ char *discard = NULL;
-int r, priority = -1;
+_cleanup_free_ char *opts = NULL;
+int r;
assert(s);
@@ -726,13 +726,19 @@ static void swap_enter_activating(Swap *s) {
s-control_command = s-exec_command + SWAP_EXEC_ACTIVATE;
if (s-from_fragment) {
-fstab_filter_options(s-parameters_fragment.options,
discard\0, NULL, discard, NULL);
+int priority = -1;
+
+r = fstab_find_pri(s-parameters_fragment.options, priority);
+if (r 0)
+log_notice_errno(r, Failed to parse swap priority
\%s\, ignoring: %m, s-parameters_fragment.options);
-priority = s-parameters_fragment.priority;
-if (priority 0) {
-r = fstab_find_pri(s-parameters_fragment.options,
priority);
+if (r = 0 s-parameters_fragment.priority = 0) {
+if (s-parameters_fragment.options)
+r = asprintf(opts, %s,pri=%i,
s-parameters_fragment.options, s-parameters_fragment.priority);
+else
+r = asprintf(opts, pri=%i,
s-parameters_fragment.priority);
if (r 0)
-log_notice_errno(r, Failed to parse swap
priority \%s\, ignoring: %m, s-parameters_fragment.options);
+goto fail;
}
}
@@ -740,24 +746,9 @@ static void swap_enter_activating(Swap *s) {
if (r 0)
goto fail;
-if (priority = 0) {
-char p[DECIMAL_STR_MAX(int)];
-
-sprintf(p, %i, priority);
-r = exec_command_append(s-control_command, -p, p, NULL);
-if (r 0)
-goto fail;
-}
-
-if (discard !streq(discard, none)) {
-const char *discard_arg;
-
-if (streq(discard, all))
-discard_arg = --discard;
-else
-discard_arg = strjoina(--discard=, discard);
-
-r = exec_command_append(s-control_command, discard_arg, NULL);
+if (s-parameters_fragment.options || opts) {
+r = exec_command_append(s-control_command, -o,
+opts ? : s-parameters_fragment.options, NULL);
if (r 0)
goto fail;
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Idea of splitting boot up logic from core
Hi all, It seems too many branches in core: * system mode in host * system mode in container * user mode IMHO, the central concept of systemd is units, hence it seems more sensible to keep units related logic in core, and split boot up logic in each manager running in: 1. system mode in host 2. system mode in container 3. user mode This makes the boot up procedure ** more declarative **(no or less branches, think about android's initrc) And the central units logic is only for: 1. Tracking the dependencies among units 2. Schedule launch of units: confine them to meet the dependencies, and *** make the best schedule decision ***, e.g. If A is a much more dependent unit, do not start A with too many units in parallel -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
Hey Lennart, Lennart Poettering [2015-05-20 17:49 +0200]: Nope, ConditionSecurity=audit is only a simple boolean check that holds when audit is enabled at all. It doesn't tell you anything about the precise audit feature set of the kernel. Ah, thanks for the clarification. I have now conditionalized the unit on CAP_ADMIN_READ, which is the cap that you need to read the audit multicast stuff. You container manager hence should simply drop that cap fro, the cap set it passes and all should be good. Wonderful! Now it works perfectly in nspawn. (This needs to be fixed in unprivileged LXC containers, but that's not a systemd problem; I'll talk to LXC upstream about that). With these two fixes, should we now remove the scary warning in README? AFAICS there is no need to turn auditing off on the host any more. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
On May 20, 2015 9:48 AM, Tom Gundersen t...@jklm.no wrote: On Tue, Apr 21, 2015 at 11:59 PM, Nick Owens misch...@offblast.org wrote: hello tom, On Mon, Apr 20, 2015 at 2:32 PM, Tom Gundersen t...@jklm.no wrote: On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau michael.marin...@coreos.com wrote: On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens misch...@offblast.org wrote: hi, sorry for the delay. from http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html : By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, *and for at least one link to gain a carrier.*. the import part here is the end of the sentence. without this patch, systemd-networkd-wait-online will block until all configured interfaces have carrier.. you can reproduce this by running systemd-networkd in qemu with two ethernet interfaces, and issue 'info network' and then 'set_link if down' to simulate no carrier. then you can run systemd-networkd-wait-online, and observe that it will block until both interfaces are up, not just one. nick On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov arvidj...@gmail.com wrote: On Wed, Mar 25, 2015 at 11:49 PM, misch...@offblast.org wrote: From: mischief misch...@offblast.org when checking interface status, systemd-networkd-wait-online will continue to wait if any interface is still configuring or being processed by udev. this patch allows it to return if any one interface is degraded/routable, as per the manual. But current behavior is exactly what manual says: By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed. Or do I miss something? It is worth noting that there may be some issues with tracking interface states in networkd, there appear to be ways to get an interface stuck in a 'configuring' state despite the fact that the interface has no network config and/or has no carrier. Do you have any more info on this? Can you reproduce with current git? There was a fix after the last release which should fix a problem with enumerating devices. the original issue was discussed at https://github.com/coreos/bugs/issues/279. i just tested commit cffacc741cb79f63999720525ceaa65aae01a542. https://github.com/coreos/init/blob/master/systemd/network/zz-default.network is our default for networkd. it seems logical that given this config, systemd-networkd-wait-online would wait for all of the dhcp interfaces, no matter how many. however, i'm not sure what use case there is for this. it seems like there's no way to wait for any one nic to be routeable/configured without knowing its name ahead of time. Correct. I mean, waiting for the system coming online like this is mostly a legacy thing, so we support this in a relatively limited way. Anything modern better explicitly listen for rtnl events and act accordingly. another instance of this problem is having a bridge like [NetDev] Name=br0 Kind=bridge and run 'systemctl restart systemd-networkd; /usr/bin/systemd-networkd-wait-online'. systemd-networkd-wait-online will not return. is this intended behavior? Hm, I'm not able to reproduce this. Can you still reproduce with git HEAD? If so what are the other config files that are applied, and what is the output of networkctl whilst wait-online is hanging? I haven't retested HEAD yet but up through 219 it would report 'no-carrier configuring' which seems bogus since it shouldn't be configuring an interface in such a state and there is no .network config to apply to the interface either. We have seen similar looking networkctl output for physical interfaces too but since several different states get squashed into 'configuring' I'm not sure if it is the same situation, it was just easier to demo with a .netdev and bridge. Interestingly no other mechanism for creating a bridge (ip or brctl) got it into the same state but I'm not sure why. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
