[systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems

[Hendrik Brueckner]

From: Liu Yuan Yuan 

Improve and enhance the path_id udev builtin to correctly handle bus'
available on Linux on z Systems (s390).

Previously, the CCW bus and, in particular, any FCP devices on it, have
been treated separately.  This commit integrates the CCW bus into the
device chain loop.  FCP devices and their associated SCSI disks are now
handled through the common SCSI handling functions in path_id.

This implies also a change in the naming of the symbolic links created
by udev.  So any backports of this commit to existing Linux distribution
must be done with care.  If a backport is requires, a udev rule can be
created to create the "old-style" symbolic links too.

Apart from the CCW bus, this commit adds bus support for the:

- ccwgroup bus which manages network devices, and
- ap bus which manages cryptographic adapters
- iucv bus which manages IUCV devices on z/VM

Signed-off-by: Liu Yuan Yuan 
Signed-off-by: Hendrik Brueckner 
---
 src/udev/udev-builtin-path_id.c |   57 --
 1 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/src/udev/udev-builtin-path_id.c b/src/udev/udev-builtin-path_id.c
index 01e2c65..a436e4f 100644
--- a/src/udev/udev-builtin-path_id.c
+++ b/src/udev/udev-builtin-path_id.c
@@ -591,31 +591,23 @@ static struct udev_device *handle_bcma(struct udev_device 
*parent, char **path)
 return parent;
 }
 
-static struct udev_device *handle_ccw(struct udev_device *parent, struct 
udev_device *dev, char **path) {
-struct udev_device *scsi_dev;
+/* Handle devices of AP bus in System z platform. */
+static struct udev_device *handle_ap(struct udev_device *parent, char **path) {
+const char *type, *func;
 
 assert(parent);
-assert(dev);
 assert(path);
 
-scsi_dev = udev_device_get_parent_with_subsystem_devtype(dev, "scsi", 
"scsi_device");
-if (scsi_dev != NULL) {
-const char *wwpn;
-const char *lun;
-const char *hba_id;
-
-hba_id = udev_device_get_sysattr_value(scsi_dev, "hba_id");
-wwpn = udev_device_get_sysattr_value(scsi_dev, "wwpn");
-lun = udev_device_get_sysattr_value(scsi_dev, "fcp_lun");
-if (hba_id != NULL && lun != NULL && wwpn != NULL) {
-path_prepend(path, "ccw-%s-zfcp-%s:%s", hba_id, wwpn, 
lun);
-goto out;
-}
-}
+type = udev_device_get_sysattr_value(parent, "type");
+func = udev_device_get_sysattr_value(parent, "ap_functions");
 
-path_prepend(path, "ccw-%s", udev_device_get_sysname(parent));
+if (type != NULL && func != NULL) {
+path_prepend(path, "ap-%s-%s", type, func);
+goto out;
+}
+path_prepend(path, "ap-%s", udev_device_get_sysname(parent));
 out:
-parent = skip_subsystem(parent, "ccw");
+parent = skip_subsystem(parent, "ap");
 return parent;
 }
 
@@ -627,13 +619,6 @@ static int builtin_path_id(struct udev_device *dev, int 
argc, char *argv[], bool
 
 assert(dev);
 
-/* S390 ccw bus */
-parent = udev_device_get_parent_with_subsystem_devtype(dev, "ccw", 
NULL);
-if (parent != NULL) {
-handle_ccw(parent, dev, );
-goto out;
-}
-
 /* walk up the chain of devices and compose path */
 parent = dev;
 while (parent != NULL) {
@@ -681,6 +666,25 @@ static int builtin_path_id(struct udev_device *dev, int 
argc, char *argv[], bool
 parent = skip_subsystem(parent, "scm");
 supported_transport = true;
 supported_parent = true;
+} else if (streq(subsys, "ccw")) {
+path_prepend(, "ccw-%s", 
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "ccw");
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "ccwgroup")) {
+path_prepend(, "ccwgroup-%s", 
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "ccwgroup");
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "ap")) {
+parent = handle_ap(parent, );
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "iucv")) {
+path_prepend(, "iucv-%s", 
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "iucv");
+supported_transport = true;
+supported_parent = 

[systemd-devel] Running a script as FIRST script before shutdown

[Luca Bertoncello]

Hi list!

I'm new here and I hope, I'm in topic... I don't want to develop system, but I 
didn't found a "system-user"-ML...

So, to my problem:
I need a possibility to call a script on shutdown/reboot/halt (I use CentOS 7). 
This **MUST** be the first one be called, since it needs many other service to 
be running...
The second important thing is, that the shutdown-process has to wait until my 
script ends.

Right now I got my script to be called, but:
1) not as first script on shutdown
2) shutdown does not wait, so that my script cannot do what it should...

My definition:

[Unit]
Description=SHUTDOWN oVirt
Before=shutdown.target reboot.target halt.target
Wants=local-fs.target remote-fs.target network.target

[Service]
Type=simple
ExecStart=/bin/true
ExecStop=/usr/local/bin/ovirt-maintenance.sh maintenance
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Can someone help me?

Thanks a lot for your help!

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] mising: add __NR_memfd_create syscall number for s390

[Daniel Mack]

Applied thanks!

Though I removed the S-o-b line, we don't use that in systemd.

On 09/23/2015 01:42 PM, Hendrik Brueckner wrote:
> Signed-off-by: Hendrik Brueckner 
> ---
>  src/basic/missing.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/src/basic/missing.h b/src/basic/missing.h
> index dc1f244..93a7cb9 100644
> --- a/src/basic/missing.h
> +++ b/src/basic/missing.h
> @@ -139,6 +139,8 @@ static inline int pivot_root(const char *new_root, const 
> char *put_old) {
>  #define __NR_memfd_create 385
>  #  elif defined __aarch64__
>  #define __NR_memfd_create 279
> +#  elif defined __s390__
> +#define __NR_memfd_create 350
>  #  elif defined _MIPS_SIM
>  #if _MIPS_SIM == _MIPS_SIM_ABI32
>  #  define __NR_memfd_create 4354
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Lennart Poettering]

On Wed, 23.09.15 16:20, Luca Bertoncello (l.bertonce...@queo-group.com) wrote:

> Hi list!
> 
> I'm new here and I hope, I'm in topic... I don't want to develop system, but 
> I didn't found a "system-user"-ML...
> 
> So, to my problem:

> I need a possibility to call a script on shutdown/reboot/halt (I use
> CentOS 7). This **MUST** be the first one be called, since it needs
> many other service to be running...  The second important thing is,
> that the shutdown-process has to wait until my script ends.

There is no concept of "first" or "last" in systemd, since it's not
clear what that's supposed to mean if there are multiple, and what
happens if some operation results in activation?

Hence, simply order your service against the services it
requires. If you want to just run some code when shutting down, make
it a service with Type=oneshot and RemainAfterExit=yes, give it an
empty ExecStart=, but specify ExecStop= to whatever it's supposed to
do. Then order it *after* the services that it shall be able to use,
as the shutdown order in systemd is always the inverse of the startup
order, and what you specify via After= and Before= specifies the
startup order.

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] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

[Krzysztof Kotlenga]

Krzysztof Kotlenga wrote:

> I recommend the following gdb script, because it provides some
> possibly interesting output:

Slightly fixed version:
https://gist.github.com/pocek/709d8c098d632ed1f21e

The first one was incorrectly printing pending_iteration instead of
prepare_iteration field. Nothing major.

> What's going on with order in that "prepare" Prioq?

I've debugged this a bit more. Two things:

1. I think prepare_prioq_compare function is wrong: "enabled" field
should be the first one to compare.

2. Maybe I don't get something right - please enlighten me if that's the
case - but prioq_put or rather shuffle_up function is buggy. 

Let's start with prepare Prioq like this:
bus-input e=1 pri=0 pi=8 fd=12
bus-input e=1 pri=0 pi=9 fd=18 <- netcat

Now we enter some garbage in netcat:
bus-input e=1 pri=0 pi=9 fd=12
bus-input e=0 pri=0 pi=9 fd=18 <- netcat

BTW, some loop iterations later it is still OK if we have fixed the
order in prepare_prioq_compare (see 1):

bus-input e=1 pri=0 pi=10 fd=12
bus-input e=0 pri=0 pi=9 fd=18 <- netcat

Good! Now let's make another connection. We have a breakpoint in
prepare_prioq_compare.

bus-input e=1 pri=0 pi=11 fd=12
bus-input e=0 pri=0 pi=9 fd=18
(null) e=1 pri=0 pi=0 fd=19 <- new connection, it doesn't have a
   description set yet.

Backtrace for some context (shortened):
#0  prepare_prioq_compare (a=0x81466e18, b=0x81477490) 
#1  shuffle_up (q=0x81466ee8, idx=2)
#2  prioq_put (q=0x81466ee8, data=0x81477490, idx=0x814774b8)
#3  sd_event_source_set_prepare (s=0x81477490, callback=0x80181f81 
)
#4  attach_io_events (bus=0x81476d20)
#5  sd_bus_attach_event (bus=0x81476d20, event=0x8140e6e0, priority=0)
#6  bus_on_connection (s=0x81471680, fd=14, revents=1, userdata=0x8140e318)
#7  source_dispatch (s=0x81471680)
#8  sd_event_dispatch (e=0x8140e6e0)
#9  sd_event_run (e=0x8140e6e0, timeout=18446744073709551615)
#10 manager_loop (m=0x8140e318)
#11 main (argc=4, argv=0xbfb1b254)

OK, let's see what we have got here:
(gdb) p x->prepare_index
$2 = 0
(gdb) p y->prepare_index
$3 = 2

So we are comparing the new sd_event_source with the first one in the
queue. This is bad. Let's move to shuffle_up first.

(gdb) frame 1
(gdb) p k
$4 = 0

Right. So shuffle_up doesn't iterate more than once here. It has only
swapped item 0 and 2. The prepare queue looks like this now:

(null) e=1 pri=0 pi=0 fd=19
bus-input e=0 pri=0 pi=9 fd=18
bus-input e=1 pri=0 pi=11 fd=12

It doesn't look like a correct order judging by how prepare_event
(sd-event.c) works. The last bus-input above is pretty much broken
because s->prepare callback won't be called anymore.

Am I wrong to believe that it should have swapped 2 and 1, not 2 and 0?

Lennart, can you fix Prioq or correct me if I'm wrong, please?

> This has been debugged on v225, but AFAICS master has the same issues.

I'm debugging this now on v226 now.

-- 
kjk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a script as FIRST script before shutdown

[Mantas Mikulėnas]

On Wed, Sep 23, 2015 at 5:20 PM, Luca Bertoncello <
l.bertonce...@queo-group.com> wrote:

> Hi list!
>
> I'm new here and I hope, I'm in topic... I don't want to develop system,
> but I didn't found a "system-user"-ML...
>

Yeah, systemd-devel is still also the tech support list.


> So, to my problem:
> I need a possibility to call a script on shutdown/reboot/halt (I use
> CentOS 7). This **MUST** be the first one be called, since it needs many
> other service to be running...
>

Almost always, being "first" is a made up requirement. The actually
important part here is "it needs many other services" – and you probably
know /which/ specific services it needs, so you can declare them as
dependencies in your unit. *(Sometimes takes some trial and error
though...)*

In systemd, the shutdown order is generally inverse of the boot order – if
a unit has "After=X", it will be started after X, but stopped before X. So
your unit should have a Requires= (or Wants=) plus an After= for every
service it actually needs.

Also – the unit seems more like a Type=oneshot, not a Type=simple.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [HEADS-UP] Please register for systemd.conf 2015 now, only 14 tickets left!

[Lennart Poettering]

Heya!

We are close to being sold out now, only 14 tickets are still
available now. If you intend to attend, make sure to register for the
conference *now*, before it's too late and all tickets are gone.

Register here:

https://systemd.events/systemdconf-2015/registration

To get an idea about the sessions offered, please see our preliminary
schedule:

https://systemd.events/systemdconf-2015/schedule

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] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

[Krzysztof Kotlenga]

Krzysztof Kotlenga wrote:

> Two things:
> (...)

One more. Prioq compare functions in sd-event.c contain this:

/* Stability for the rest */
if (x < y)
return -1;
if (x > y)
return 1;


How comparing prioq_item.data pointers is going to ensure stability?
Shouldn't it be:

if (x->prepare_index < y->prepare_index)
...

and so on?

-- 
kjk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] xorg uses 100% CPU after upgrading to 226

[Jin Liu]

According to strace -p, xorg is spinning on a select(), which always return
the same fd #6, which seems related to the system dbus:


$ pgrep Xorg
614
$ strace -p 614
Process 614 attached
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
537000}) = 1 (in [6], left {214, 536993})
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
537000}) = 1 (in [6], left {214, 536995})
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
537000}) = 1 (in [6], left {214, 536995})
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
537000}) = 1 (in [6], left {214, 536995})
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
537000}) = 1 (in [6], left {214, 536996})
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
536000}) = 1 (in [6], left {214, 535996})
select(256, [1 3 5 6 8 10 19 23 25 29 36 37 38 39 40 41], NULL, NULL, {214,
536000}) = 1 (in [6], left {214, 535996})
^C
$ gdb -p 614
GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 614
Reading symbols from /usr/lib/xorg-server/Xorg...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libdbus-1.so.3...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libudev.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libgcrypt.so.20...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libdl.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libunwind.so.8...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libpciaccess.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libdrm.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libpixman-1.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libXfont.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libXau.so.6...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libsystemd.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libxshmfence.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libXdmcp.so.6...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.6...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libc.so.6...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libpthread.so.0...(no debugging symbols
found)...done.
[New LWP 980]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libresolv.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcap.so.2...(no debugging symbols
found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libgpg-error.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/liblzma.so.5...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libfreetype.so.6...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libfontenc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/liblz4.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libattr.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libbz2.so.1.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libpng16.so.16...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libharfbuzz.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libglib-2.0.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libgraphite2.so.3...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libpcre.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/xorg/modules/extensions/libglx.so...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/libGL.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols
found)...done.

[systemd-devel] [PATCH] gssd: Improve scalability by not waiting for child processes

[Steve Dickson]

Instead of waiting on every fork, which would
become a bottle neck during a mount storm, simply
set a SIGCHLD signal handler to do the wait on
the child process

Signed-off-by: Steve Dickson 
---
 utils/gssd/gssd.c  | 18 ++
 utils/gssd/gssd_proc.c | 11 ++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index e480349..8b778cb 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -44,11 +44,13 @@
 #define _GNU_SOURCE
 #endif
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -736,6 +738,21 @@ sig_die(int signal)
printerr(1, "exiting on signal %d\n", signal);
exit(0);
 }
+static void
+sig_child(int signal)
+{
+   int err;
+   pid_t pid;
+
+   /* Parent: just wait on child to exit and return */
+   do {
+   pid = wait();
+   } while(pid == -1 && errno != -ECHILD);
+
+   if (WIFSIGNALED(err))
+   printerr(0, "WARNING: forked child was killed"
+"with signal %d\n", WTERMSIG(err));
+}
 
 static void
 usage(char *progname)
@@ -902,6 +919,7 @@ main(int argc, char *argv[])
 
signal(SIGINT, sig_die);
signal(SIGTERM, sig_die);
+   signal(SIGCHLD, sig_child);
signal_set(_ev, SIGHUP, gssd_scan_cb, NULL);
signal_add(_ev, NULL);
event_set(_ev, inotify_fd, EV_READ | EV_PERSIST, 
gssd_inotify_cb, NULL);
diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
index 11168b2..8f5ca03 100644
--- a/utils/gssd/gssd_proc.c
+++ b/utils/gssd/gssd_proc.c
@@ -656,16 +656,9 @@ process_krb5_upcall(struct clnt_info *clp, uid_t uid, int 
fd, char *tgtname,
/* fork() failed! */
printerr(0, "WARNING: unable to fork() to handle"
"upcall: %s\n", strerror(errno));
-   return;
+   /* FALLTHROUGH */
default:
-   /* Parent: just wait on child to exit and return */
-   do {
-   pid = wait();
-   } while(pid == -1 && errno != -ECHILD);
-
-   if (WIFSIGNALED(err))
-   printerr(0, "WARNING: forked child was killed"
-"with signal %d\n", WTERMSIG(err));
+   /* Parent: Return and wait for the SIGCHLD */
return;
}
 no_fork:
-- 
2.4.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

[Krzysztof Kotlenga]

Krzysztof Kotlenga wrote:

> 2. Maybe I don't get something right - please enlighten me if that's
> the case - but prioq_put or rather shuffle_up function is buggy. 
> 
> (...)
> 
> Am I wrong to believe that it should have swapped 2 and 1, not 2 and
> 0?

OK, I've finally realised that I'm a moron iterating over a heap-like
structure...

-- 
kjk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] failed to change interface name (systemd-networkd)

[James]

Hello,

Hoping someone can point me in the right direction. I'm attempting to
change the interface name (eth0 -> wired) on one of my servers.

Here's the output from the journal:

~# journalctl --no-pager | grep -i wired
Sep 23 17:11:15 vivid systemd-udevd[399]: error changing net interface
name 'eth0' to 'wired0': Device or resource busy
Sep 23 17:11:15 vivid systemd-udevd[399]: could not rename interface
'2' from 'eth0' to 'wired0': Device or resource busy
Sep 23 17:11:17 vivid sh[566]: Unknown interface wired0
Sep 23 17:11:17 vivid systemd[1]: Started ifup for wired0.
Sep 23 17:11:17 vivid systemd[1]: Starting ifup for wired0...

Here's what the .link contains:

# cat 10-ethernet.link
[Match]
MACAddress=fa:16:3e:31:7a:4b
[Link]
Name=wired0
MACAddress=fa:15:33:55:33:44

And the .network:

# cat 20-ethernet.network
[Match]
Name=wired*
[Network]
DNS=8.8.8.8
DNS=8.8.4.4
[Address]
Address=10.1.1.190/24
[Route]
Destination=0.0.0.0/0
Gateway=10.1.1.1

The MAC address of the interface changes properly, so I know that the
unit is at least being read and parsed.

As an aside, this is happening on Ubuntu 15.04. I've disabled
NetworkManager and am relying, obviously, on systemd-networkd and
systemd-resolved. I've also temporarily disabled dhcpd thinking that
may have had something to do with the interface being busy, to no
avail.

Any thoughts on why the interface is busy resulting in the name change failing?

Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel