[systemd-devel] [PATCH 0/2] Scalability fixes for large machines

[Hannes Reinecke]

On large machines we hit the limit on 512 concurrent dbus connections
pretty easily, so we're greeted with tons of messages

Too many concurrent connections, refusing

To raise this limit, however, there another cap on the number of
accepted epoll events, which is particularly nasty as it will
just silently drop events on the floor.

AFAICS both caps are totally arbitrary, so I've removed the cap on
the number of epoll events and raise the number of concurrent
dbus connections to 4096.

Hannes Reinecke (2):
  Remove the cap on epoll events
  Allow up to 4096 simultaneous connections

 src/core/dbus.c| 2 +-
 src/libsystemd/sd-event/sd-event.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

-- 
1.8.4.5

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

[systemd-devel] [PATCH 1/2] Remove the cap on epoll events

[Hannes Reinecke]

Currently the code will silently blank out events
if there are more then 512 epoll events, causing them
never to be handled at all.
This patch removes the cap on the number of events
for epoll_wait, thereby avoiding this issue.

Signed-off-by: Hannes Reinecke h...@suse.de
---
 src/libsystemd/sd-event/sd-event.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/libsystemd/sd-event/sd-event.c 
b/src/libsystemd/sd-event/sd-event.c
index 0c4e517..8eb154c 100644
--- a/src/libsystemd/sd-event/sd-event.c
+++ b/src/libsystemd/sd-event/sd-event.c
@@ -36,7 +36,6 @@
 
 #include sd-event.h
 
-#define EPOLL_QUEUE_MAX 512U
 #define DEFAULT_ACCURACY_USEC (250 * USEC_PER_MSEC)
 
 typedef enum EventSourceType {
@@ -2366,7 +2365,7 @@ _public_ int sd_event_wait(sd_event *e, uint64_t timeout) 
{
 return 1;
 }
 
-ev_queue_max = CLAMP(e-n_sources, 1U, EPOLL_QUEUE_MAX);
+ev_queue_max = e-n_sources  0 ? e-n_sources : 1;
 ev_queue = newa(struct epoll_event, ev_queue_max);
 
 m = epoll_wait(e-epoll_fd, ev_queue, ev_queue_max,
-- 
1.8.4.5

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

[systemd-devel] [PATCH 1/2] Remove the cap on epoll events

[Hannes Reinecke]

Currently the code will silently blank out events
if there are more then 512 epoll events, causing them
never to be handled at all.
This patch removes the cap on the number of events
for epoll_wait, thereby avoiding this issue.

Signed-off-by: Hannes Reinecke h...@suse.de
---
 src/libsystemd/sd-event/sd-event.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/libsystemd/sd-event/sd-event.c 
b/src/libsystemd/sd-event/sd-event.c
index 0c4e517..dae81c5 100644
--- a/src/libsystemd/sd-event/sd-event.c
+++ b/src/libsystemd/sd-event/sd-event.c
@@ -36,7 +36,6 @@
 
 #include sd-event.h
 
-#define EPOLL_QUEUE_MAX 512U
 #define DEFAULT_ACCURACY_USEC (250 * USEC_PER_MSEC)
 
 typedef enum EventSourceType {
@@ -2366,7 +2365,7 @@ _public_ int sd_event_wait(sd_event *e, uint64_t timeout) 
{
 return 1;
 }
 
-ev_queue_max = CLAMP(e-n_sources, 1U, EPOLL_QUEUE_MAX);
+ev_queue_max = e-n_sources  0 ? e-n_source : 1;
 ev_queue = newa(struct epoll_event, ev_queue_max);
 
 m = epoll_wait(e-epoll_fd, ev_queue, ev_queue_max,
-- 
1.8.4.5

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

[systemd-devel] Device cgroups for user systemd scopes

[Alexander Larsson]

The user instance of systemd does not seem to apply the DevicePolicy for
scopes. I.e. I can run:

$ systemd-run --user --scope --property=DevicePolicy=strict glxgears
Running as unit run-994.scope.
... runs fine, should fail to use DRI ...
$ cat /run/user/1000/systemd/user/run-994.scope.d/50-DevicePolicy.conf 
[Scope]
DevicePolicy=strict
$ cat /proc/994/cgroup 
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls,net_prio:/
6:freezer:/
5:devices:/user.slice
4:memory:/user.slice
3:cpu,cpuacct:/
2:cpuset:/
1:name=systemd:/user.slice/user-1000.slice/user@1000.service/run-994.scope

This is with systemd-216-20.fc21.x86_64 from Fedora 21 under gnome.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a world-famous Republican sorceror with a mysterious suitcase 
handcuffed to his arm. She's a cynical hip-hop politician from the wrong 
side of the tracks. They fight crime! 

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

Re: [systemd-devel] systemd-networkd and bonding config

[Ian Pilcher]

On 03/04/2015 03:43 AM, Tom Gundersen wrote:

The logic here is that when we create a new bond we will create it
with these settings, but we will not change the settings of a
preexisting bond, as that may have been created by somebody else we
don't know about so we figure better leave it alone.

The confusing part here is that the kernel will create bond0 with
default settings, and we will then not touch that. Ideally there would
be a kernel config switch to make it not create default devices like
that, but for the moment I think the best solution is to simply call
your bond something else. So if you put bond1 everywhere instead
things should JustWork(TM).


Alternatively, if you're attached to the name bond0, you might be able
to something like this (not tested with systemd-networkd):

/etc/modprobe.d/rename-bond.conf:

install bonding /usr/sbin/modprobe --ignore-install bonding \
$CMDLINE_OPTS; /usr/sbin/ip link set dev bond0 down; \
/usr/sbin/ifrename -c /dev/null -i bond0 -n FOO /dev/null

(Or an equivalent udev rule)

--

Ian Pilcher arequip...@gmail.com
 I grew up before Mark Zuckerberg invented friendship 


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

[systemd-devel] Cleaning up transient scopes

[Alexander Larsson]

If i run a transient scope on the user systemd instance like:

$ systemd-run --user --scope true

Then the scope seems to live past the end of the process. Is there any
way to make it automatically go away with the last process in the
cgroup?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a gun-slinging gay filmmaker possessed of the uncanny powers of an 
insect. She's an elegant tomboy widow with someone else's memories. They 
fight crime! 

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

[systemd-devel] [PATCH 2/2] Allow up to 4096 simultaneous connections

[Hannes Reinecke]

On large system we hit the limit on 512 simultaneous dbus
connections, resulting in tons of annoying messages:

Too many concurrent connections, refusing

This patch raises the limit to 4096.

Signed-off-by: Hannes Reinecke h...@suse.de
---
 src/core/dbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/dbus.c b/src/core/dbus.c
index 5dcb0d1..80f7589 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -43,7 +43,7 @@
 #include bus-internal.h
 #include selinux-access.h
 
-#define CONNECTIONS_MAX 512
+#define CONNECTIONS_MAX 4096
 
 static void destroy_bus(Manager *m, sd_bus **bus);
 
-- 
1.8.4.5

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

[systemd-devel] [PATCH 2/2] Allow up to 4096 simultaneous connections

[Hannes Reinecke]

On large system we hit the limit on 512 simultaneous dbus
connections, resulting in tons of annoying messages:

Too many concurrent connections, refusing

This patch raises the limit to 4096.

Signed-off-by: Hannes Reinecke h...@suse.de
---
 src/core/dbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/dbus.c b/src/core/dbus.c
index 5dcb0d1..80f7589 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -43,7 +43,7 @@
 #include bus-internal.h
 #include selinux-access.h
 
-#define CONNECTIONS_MAX 512
+#define CONNECTIONS_MAX 4096
 
 static void destroy_bus(Manager *m, sd_bus **bus);
 
-- 
1.8.4.5

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

[systemd-devel] [PATCHv2 0/2] Scalability fixes for large machines

[Hannes Reinecke]

On large machines we hit the limit on 512 concurrent dbus connections
pretty easily, so we're greeted with tons of messages

Too many concurrent connections, refusing

To raise this limit, however, there another cap on the number of
accepted epoll events, which is particularly nasty as it will
just silently drop events on the floor.

AFAICS both caps are totally arbitrary, so I've removed the cap on
the number of epoll events and raise the number of concurrent
dbus connections to 4096.

Changes to v1:
- Fix typo in the first patch

Hannes Reinecke (2):
  Remove the cap on epoll events
  Allow up to 4096 simultaneous connections

 src/core/dbus.c| 2 +-
 src/libsystemd/sd-event/sd-event.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

-- 
1.8.4.5

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

Re: [systemd-devel] nilfs-cleanerd startup on boot

[Kai Krakow]

dennis.mur...@wipro.com dennis.mur...@wipro.com schrieb:

 nilfs_cleanerd is invoked through /sbin/mount.nilfs2 helper. [2] The
 helper is called from /sbin/mount if it exists.
 
 What is confusing to me, is an umount then a mount will start the
 nilfs_cleanerd process so it does exist on the system.  I had expected it
 to be started as soon as the file system was mounted the first time.

My first guess would be that the helper is missing in your initrd if you are 
booting from it, or it is hidden away in a partition not yet mounted at 
first mount time.

-- 
Replies to list only preferred.

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

Re: [systemd-devel] Cleaning up transient scopes

[Lennart Poettering]

On Wed, 04.03.15 18:51, Alexander Larsson (al...@redhat.com) wrote:

 If i run a transient scope on the user systemd instance like:
 
 $ systemd-run --user --scope true
 
 Then the scope seems to live past the end of the process. Is there any
 way to make it automatically go away with the last process in the
 cgroup?

Well, yes, the idea is that that just works. However, this is kinda
broken if the systemd instance managing your scope is not PID 1, as we
don't get SIGCHLD then. 

Do you create any subcgroups? presumably not?

Normally it should just work then, but I must admit that --user scopes
got much less testing that system scopes...

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] man: replace obsolete wiki link with man page

[Zachary Cook]

---
 man/systemd-cryptsetup-generator.xml| 6 ++
 man/systemd-debug-generator.xml | 6 ++
 man/systemd-efi-boot-generator.xml  | 4 +---
 man/systemd-fstab-generator.xml | 6 ++
 man/systemd-getty-generator.xml | 5 ++---
 man/systemd-gpt-auto-generator.xml  | 4 +---
 man/systemd-system-update-generator.xml | 6 ++
 man/systemd-sysv-generator.xml  | 6 ++
 man/systemd.unit.xml| 4 ++--
 man/systemd.xml | 5 ++---
 10 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/man/systemd-cryptsetup-generator.xml 
b/man/systemd-cryptsetup-generator.xml
index 0e48e79..1974cd7 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -59,10 +59,8 @@
 
citerefentryrefentrytitlesystemd-cryptsetup@.service/refentrytitlemanvolnum8/manvolnum/citerefentry
 units as necessary./para
 
-parafilenamesystemd-cryptsetup-generator/filename
-implements the ulink
-url=http://www.freedesktop.org/wiki/Software/systemd/Generators;generator
-specification/ulink./para
+parafilenamesystemd-cryptsetup-generator/filename implements
+
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry./para
   /refsect1
 
   refsect1
diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml
index 74c3b26..5c5e9fc 100644
--- a/man/systemd-debug-generator.xml
+++ b/man/systemd-debug-generator.xml
@@ -79,10 +79,8 @@
 
citerefentryrefentrytitlesystemctl/refentrytitlemanvolnum1/manvolnum/citerefentry's
 commandenable/command command./para
 
-parafilenamesystemd-debug-generator/filename implements the
-ulink
-url=http://www.freedesktop.org/wiki/Software/systemd/Generators;generator
-specification/ulink./para
+parafilenamesystemd-debug-generator/filename implements
+
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry./para
   /refsect1
 
   refsect1
diff --git a/man/systemd-efi-boot-generator.xml 
b/man/systemd-efi-boot-generator.xml
index d05d84a..91f8815 100644
--- a/man/systemd-efi-boot-generator.xml
+++ b/man/systemd-efi-boot-generator.xml
@@ -68,9 +68,7 @@
 only be activated on-demand, when accessed./para
 
 parafilenamesystemd-efi-boot-generator/filename implements
-the ulink
-url=http://www.freedesktop.org/wiki/Software/systemd/Generators;generator
-specification/ulink./para
+
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry./para
   /refsect1
 
   refsect1
diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml
index 8f82e33..022efb4 100644
--- a/man/systemd-fstab-generator.xml
+++ b/man/systemd-fstab-generator.xml
@@ -71,10 +71,8 @@
 for more information about special filename/etc/fstab/filename
 mount options this generator understands./para
 
-parafilenamesystemd-fstab-generator/filename implements the
-ulink
-url=http://www.freedesktop.org/wiki/Software/systemd/Generators;generator
-specification/ulink./para
+parafilenamesystemd-fstab-generator/filename implements
+
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry./para
   /refsect1
 
   refsect1
diff --git a/man/systemd-getty-generator.xml b/man/systemd-getty-generator.xml
index 0b5b2f2..3389259 100644
--- a/man/systemd-getty-generator.xml
+++ b/man/systemd-getty-generator.xml
@@ -75,9 +75,8 @@
 for more information on the varnameconsole=/varname kernel
 parameter./para
 
-parafilenamesystemd-getty-generator/filename implements the
-ulink 
url=http://www.freedesktop.org/wiki/Software/systemd/Generators;generator
-specification/ulink./para
+parafilenamesystemd-getty-generator/filename implements
+
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry./para
 
 paraFurther information about configuration of gettys you may
 find in
diff --git a/man/systemd-gpt-auto-generator.xml 
b/man/systemd-gpt-auto-generator.xml
index 9c706df..8d2eaca 100644
--- a/man/systemd-gpt-auto-generator.xml
+++ b/man/systemd-gpt-auto-generator.xml
@@ -157,9 +157,7 @@
 using commandbtrfs subvolume set-default/command./para
 
 parafilenamesystemd-gpt-auto-generator/filename implements
-the
-ulink 
url=http://www.freedesktop.org/wiki/Software/systemd/Generators;Generator
-Specification/ulink./para
+
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry./para
   /refsect1
 
   refsect1
diff --git a/man/systemd-system-update-generator.xml 
b/man/systemd-system-update-generator.xml
index 3eec1d7..e7fc95c 100644
--- a/man/systemd-system-update-generator.xml
+++ b/man/systemd-system-update-generator.xml
@@ -61,10 +61,8 @@
 Updates Specification/ulink.
 /para
 
-parafilenamesystemd-system-update-generator/filename
-implements 

Re: [systemd-devel] Device cgroups for user systemd scopes

[Lennart Poettering]

On Wed, 04.03.15 18:50, Alexander Larsson (al...@redhat.com) wrote:

 The user instance of systemd does not seem to apply the DevicePolicy for
 scopes. I.e. I can run:

None of the controllers are currently available to unprivileged
processes. This will be opened up as the kernel gets improved to allow
this.

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] build-sys: fix check for efi-lds file

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 05, 2015 at 01:22:01AM +0100, Mirco Tischler wrote:
 Using the DIR macro breaks caching and has no benefit as it only offers
 performance improvements when AS_FOR is used with a single element list.
 Also --with-lds-dir= was broken as we never set have_efi_lds in this case.
 Fix this and check if PATH actually contains the efi-lds file.
Thanks, applied.

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

Re: [systemd-devel] [PATCH 1/2] Remove the cap on epoll events

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 04, 2015 at 04:32:16PM +0100, Hannes Reinecke wrote:
 Currently the code will silently blank out events
 if there are more then 512 epoll events, causing them
 never to be handled at all.
 This patch removes the cap on the number of events
 for epoll_wait, thereby avoiding this issue.
 
 Signed-off-by: Hannes Reinecke h...@suse.de
Applied, without SOB, and with MAX() added.

Zbyszek

 ---
  src/libsystemd/sd-event/sd-event.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/src/libsystemd/sd-event/sd-event.c 
 b/src/libsystemd/sd-event/sd-event.c
 index 0c4e517..8eb154c 100644
 --- a/src/libsystemd/sd-event/sd-event.c
 +++ b/src/libsystemd/sd-event/sd-event.c
 @@ -36,7 +36,6 @@
  
  #include sd-event.h
  
 -#define EPOLL_QUEUE_MAX 512U
  #define DEFAULT_ACCURACY_USEC (250 * USEC_PER_MSEC)
  
  typedef enum EventSourceType {
 @@ -2366,7 +2365,7 @@ _public_ int sd_event_wait(sd_event *e, uint64_t 
 timeout) {
  return 1;
  }
  
 -ev_queue_max = CLAMP(e-n_sources, 1U, EPOLL_QUEUE_MAX);
 +ev_queue_max = e-n_sources  0 ? e-n_sources : 1;
  ev_queue = newa(struct epoll_event, ev_queue_max);
  
  m = epoll_wait(e-epoll_fd, ev_queue, ev_queue_max,
 -- 
 1.8.4.5
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] Allow up to 4096 simultaneous connections

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 04, 2015 at 04:32:17PM +0100, Hannes Reinecke wrote:
 On large system we hit the limit on 512 simultaneous dbus
 connections, resulting in tons of annoying messages:
 
 Too many concurrent connections, refusing
 
 This patch raises the limit to 4096.
 
 Signed-off-by: Hannes Reinecke h...@suse.de
Applied, without SOB.

Zbyszek

 ---
  src/core/dbus.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/core/dbus.c b/src/core/dbus.c
 index 5dcb0d1..80f7589 100644
 --- a/src/core/dbus.c
 +++ b/src/core/dbus.c
 @@ -43,7 +43,7 @@
  #include bus-internal.h
  #include selinux-access.h
  
 -#define CONNECTIONS_MAX 512
 +#define CONNECTIONS_MAX 4096
  
  static void destroy_bus(Manager *m, sd_bus **bus);
  
 -- 
 1.8.4.5
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] core/socket: Add REMOTE_IP environment variable for Accept=true

[Shawn Landden]

Fix handling of abstract unix domain sockets too.

v2
---
 TODO |  2 --
 man/systemd.socket.xml   |  5 -
 src/core/service.c   | 24 
 src/shared/socket-util.c | 25 +++--
 4 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/TODO b/TODO
index ae32388..780084a 100644
--- a/TODO
+++ b/TODO
@@ -164,8 +164,6 @@ Features:
 * as soon as we have kdbus, and sender timestamps, revisit coalescing multiple 
parallel daemon reloads:
   http://lists.freedesktop.org/archives/systemd-devel/2014-December/025862.html
 
-* set $REMOTE_IP (or $REMOTE_ADDR/$REMOTE_PORT) environment variable when 
doing per-connection socket activation. use format introduced by xinetd or CGI 
for this
-
 * the install state probably shouldn't get confused by generated units, think 
dbus1/kdbus compat!
 
 * in systemctl list-unit-files: show the install value the presets would 
suggest for a service in a third column
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 3938345..8796d7b 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -357,7 +357,10 @@
 daemons designed for usage with
 
citerefentryrefentrytitleinetd/refentrytitlemanvolnum8/manvolnum/citerefentry
 to work unmodified with systemd socket
-activation./para/listitem
+activation./para
+paraFor IPv4 and IPv6 connections the varnameREMOTE_IP/varname
+environment variable will be set with remote IP and port seperated by a
+colon (for SOCK_RAW the port is the IP protocol)./para/listitem
   /varlistentry
 
   varlistentry
diff --git a/src/core/service.c b/src/core/service.c
index a89ff3f..2ee4e11 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1119,6 +1119,30 @@ static int service_spawn(
 goto fail;
 }
 
+if (s-accept_socket.unit) {
+union sockaddr_union pn;
+socklen_t pnlen = sizeof(pn);
+_cleanup_free_ char *remote_addr = NULL;
+
+r = getpeername(s-socket_fd, pn.sa, pnlen);
+if (r  0) {
+r = -errno;
+goto fail;
+}
+
+if (pn.in.sin_family == AF_INET ||
+pn.in.sin_family == AF_INET6) {
+r = sockaddr_pretty(pn.sa, pnlen, true, remote_addr);
+if (r  0)
+goto fail;
+
+if (asprintf(our_env + n_env++, REMOTE_IP=%s, 
remote_addr)  0) {
+r = -ENOMEM;
+goto fail;
+}
+}
+}
+
 final_env = strv_env_merge(2, UNIT(s)-manager-environment, our_env, 
NULL);
 if (!final_env) {
 r = -ENOMEM;
diff --git a/src/shared/socket-util.c b/src/shared/socket-util.c
index 74d90fa..dbe2bf7 100644
--- a/src/shared/socket-util.c
+++ b/src/shared/socket-util.c
@@ -522,19 +522,32 @@ int sockaddr_pretty(const struct sockaddr *_sa, socklen_t 
salen, bool translate_
 return -ENOMEM;
 
 } else if (sa-un.sun_path[0] == 0) {
+void *i;
 /* abstract */
 
-/* FIXME: We assume we can print the
- * socket path here and that it hasn't
- * more than one NUL byte. That is
- * actually an invalid assumption */
-
+/* see unix(7), abstract is wierd */
+i = memchr(sa-un.sun_path + 1, '\0', 
sizeof(sa-un.sun_path) - 1);
+if (i)
+for (i = (char *)i + 1;
+ (char *)i  
sa-un.sun_path[sizeof(sa-un.sun_path)];
+ i = (char *)i + 1)
+if (*(char *)i != '\0') {
+p = strdup(abstract 
unprintable);
+if (!p)
+return -ENOMEM;
+
+goto end;
+}
+
+/* no non-NUL bytes after second NUL (if any) */
 p = new(char, sizeof(sa-un.sun_path)+1);
 if (!p)
 return -ENOMEM;
 
 p[0] = '@';
 memcpy(p+1, sa-un.sun_path+1, 
sizeof(sa-un.sun_path)-1);
+
+/* make printable if there was no second NUL (i == 
NULL) */
 p[sizeof(sa-un.sun_path)] = 0;
 
 } else {
@@ -549,7 +562,7 @@ int sockaddr_pretty(const struct sockaddr *_sa, socklen_t 
salen, bool translate_
 

Re: [systemd-devel] autoconf cache collision in check for gnuefi

[Mirco Tischler]

Thanks
Mirco

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

[systemd-devel] [PATCH] build-sys: fix check for efi-lds file

[Mirco Tischler]

Using the DIR macro breaks caching and has no benefit as it only offers
performance improvements when AS_FOR is used with a single element list.
Also --with-lds-dir= was broken as we never set have_efi_lds in this case.
Fix this and check if PATH actually contains the efi-lds file.
---
 configure.ac | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 419b5d4..14518bc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1182,9 +1182,10 @@ AS_IF([test x$enable_gnuefi != xno], [
 have_efi_lds=no
 AC_ARG_WITH(efi-ldsdir,
 AS_HELP_STRING([--with-efi-ldsdir=PATH], [Path to EFI lds 
directory]),
-[EFI_LDS_DIR=$withval],
+[EFI_LDS_DIR=$withval  
AC_CHECK_FILE([${EFI_LDS_DIR}/elf_${EFI_ARCH}_efi.lds],
+[have_efi_lds=yes])],
 [AS_FOR([DIR], [EFI_LDS_DIR], [${efiroot}/gnuefi 
${efiroot}],
-[AC_CHECK_FILE([DIR/elf_${EFI_ARCH}_efi.lds],
+
[AC_CHECK_FILE([${EFI_LDS_DIR}/elf_${EFI_ARCH}_efi.lds],
[have_efi_lds=yes  break])])])
 AS_IF([test x$have_efi_lds = xyes],
   [AC_SUBST([EFI_LDS_DIR])],
-- 
2.3.1

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

Re: [systemd-devel] [PATCH] man: replace obsolete wiki link with man page

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 04, 2015 at 06:43:20PM -0500, Zachary Cook wrote:
 ---
  man/systemd-cryptsetup-generator.xml| 6 ++
  man/systemd-debug-generator.xml | 6 ++
  man/systemd-efi-boot-generator.xml  | 4 +---
  man/systemd-fstab-generator.xml | 6 ++
  man/systemd-getty-generator.xml | 5 ++---
  man/systemd-gpt-auto-generator.xml  | 4 +---
  man/systemd-system-update-generator.xml | 6 ++
  man/systemd-sysv-generator.xml  | 6 ++
  man/systemd.unit.xml| 4 ++--
  man/systemd.xml | 5 ++---
  10 files changed, 18 insertions(+), 34 deletions(-)
Applied, thanks.

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

Re: [systemd-devel] [PATCH] core/socket: Add REMOTE_IP environment variable for Accept=true

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 04, 2015 at 03:15:02PM -0800, Shawn Landden wrote:
 Fix handling of abstract unix domain sockets too.
Please split it into two patches.

 ---
  TODO |  2 --
  man/systemd.socket.xml   |  5 -
  src/core/service.c   | 24 
  src/shared/socket-util.c | 25 +++--
  4 files changed, 47 insertions(+), 9 deletions(-)
 
 diff --git a/TODO b/TODO
 index ae32388..780084a 100644
 --- a/TODO
 +++ b/TODO
 @@ -164,8 +164,6 @@ Features:
  * as soon as we have kdbus, and sender timestamps, revisit coalescing 
 multiple parallel daemon reloads:

 http://lists.freedesktop.org/archives/systemd-devel/2014-December/025862.html
  
 -* set $REMOTE_IP (or $REMOTE_ADDR/$REMOTE_PORT) environment variable when 
 doing per-connection socket activation. use format introduced by xinetd or 
 CGI for this
 -
  * the install state probably shouldn't get confused by generated units, 
 think dbus1/kdbus compat!
  
  * in systemctl list-unit-files: show the install value the presets would 
 suggest for a service in a third column
 diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
 index 3938345..8796d7b 100644
 --- a/man/systemd.socket.xml
 +++ b/man/systemd.socket.xml
 @@ -357,7 +357,10 @@
  daemons designed for usage with
  
 citerefentryrefentrytitleinetd/refentrytitlemanvolnum8/manvolnum/citerefentry
  to work unmodified with systemd socket
 -activation./para/listitem
 +activation./para
 +paraFor IPv4 and IPv6 connections the varnameREMOTE_IP/varname
 +environment variable will be set with remote IP and port seperated 
 by a
 +colon (for SOCK_RAW the port is the IP protocol)./para/listitem
Would be nice to have a note here that say that this is the same as xinetd etc.

/varlistentry
  
varlistentry
 diff --git a/src/core/service.c b/src/core/service.c
 index a89ff3f..0942072 100644
 --- a/src/core/service.c
 +++ b/src/core/service.c
 @@ -1119,6 +1119,30 @@ static int service_spawn(
  goto fail;
  }
  
 +if (s-accept_socket.unit) {
 +union sockaddr_union pn;
 +socklen_t pnlen = sizeof(pn);
 +_cleanup_free_ char *remote_addr = NULL;
 +
 +r = getpeername(s-socket_fd, pn.sa, pnlen);
This happens before the fork, right? You cannot call a blocking function
like this in PID 1. This could be called either asynchronously, or
after the fork, in the child thread. The latter seems easier.

 +if (r  0) {
 +r = -errno;
 +goto fail;
 +}
 +
 +if (pn.sa.sun_family == AF_INET ||
 +pn.sa.sun_family == AF_INET6) {
 +r = sockaddr_pretty(pn.sa, pnlen, true, 
 remote_addr);
 +if (r  0)
 +goto fail;
 +
 +if (asprintf(our_env + n_env++, REMOTE_IP=%s, 
 remote_addr)  0) {
 +r = -ENOMEM;
 +goto fail;
 +}
 +}
 +}
 +
  final_env = strv_env_merge(2, UNIT(s)-manager-environment, 
 our_env, NULL);
  if (!final_env) {
  r = -ENOMEM;
 diff --git a/src/shared/socket-util.c b/src/shared/socket-util.c
 index 74d90fa..dbe2bf7 100644
 --- a/src/shared/socket-util.c
 +++ b/src/shared/socket-util.c
 @@ -522,19 +522,32 @@ int sockaddr_pretty(const struct sockaddr *_sa, 
 socklen_t salen, bool translate_
  return -ENOMEM;
  
  } else if (sa-un.sun_path[0] == 0) {
 +void *i;
  /* abstract */
  
 -/* FIXME: We assume we can print the
 - * socket path here and that it hasn't
 - * more than one NUL byte. That is
 - * actually an invalid assumption */
 -
 +/* see unix(7), abstract is wierd */
 +i = memchr(sa-un.sun_path + 1, '\0', 
 sizeof(sa-un.sun_path) - 1);

Wouldn't it be better to cescape the string? We could say that
socket paths are cunescaped when reading, and cescaped when pretty
printing. Nobody sane uses sockets with zeros in the name, except
by istake, so it wouldn't really matter for normal use, but it would
help catch errors. Seems more useful than punting like this.

 +if (i)
 +for (i = (char *)i + 1;
 + (char *)i  
 sa-un.sun_path[sizeof(sa-un.sun_path)];
 + i = (char *)i + 1)
 +if (*(char *)i != '\0') {
 +p = strdup(abstract 
 unprintable);
 + 

Re: [systemd-devel] autoconf cache collision in check for gnuefi

[Mirco Tischler]

2015-03-05 1:22 GMT+01:00 Mirco Tischler mt...@gmx.de:
 Thanks
 Mirco

Sorry I messed up, this was supposed to be.

I figured it out. Patch in seperate Mail
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fix strict aliasing violations in src/udev/udev-builtin-usb_id.c

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 03, 2015 at 04:21:30PM -0800, Shawn Landden wrote:
 also switch to inttypes.h
 ---
  src/udev/udev-builtin-usb_id.c | 35 ++-
  1 file changed, 18 insertions(+), 17 deletions(-)
 
 diff --git a/src/udev/udev-builtin-usb_id.c b/src/udev/udev-builtin-usb_id.c
 index ab0d96e..0223421 100644
 --- a/src/udev/udev-builtin-usb_id.c
 +++ b/src/udev/udev-builtin-usb_id.c
 @@ -28,6 +28,7 @@
  #include ctype.h
  #include fcntl.h
  #include errno.h
 +#include inttypes.h
  
  #include udev.h
  
 @@ -153,15 +154,15 @@ static int dev_if_packed_info(struct udev_device *dev, 
 char *ifs_str, size_t len
  int pos = 0;
  unsigned strpos = 0;
  struct usb_interface_descriptor {
 -u_int8_tbLength;
 -u_int8_tbDescriptorType;
 -u_int8_tbInterfaceNumber;
 -u_int8_tbAlternateSetting;
 -u_int8_tbNumEndpoints;
 -u_int8_tbInterfaceClass;
 -u_int8_tbInterfaceSubClass;
 -u_int8_tbInterfaceProtocol;
 -u_int8_tiInterface;
 +uint8_tbLength;
 +uint8_tbDescriptorType;
 +uint8_tbInterfaceNumber;
 +uint8_tbAlternateSetting;
 +uint8_tbNumEndpoints;
 +uint8_tbInterfaceClass;
 +uint8_tbInterfaceSubClass;
 +uint8_tbInterfaceProtocol;
 +uint8_tiInterface;
  } __attribute__((packed));
  
  if (asprintf(filename, %s/descriptors, 
 udev_device_get_syspath(dev))  0)
 @@ -179,21 +180,21 @@ static int dev_if_packed_info(struct udev_device *dev, 
 char *ifs_str, size_t len
  
  ifs_str[0] = '\0';
  while (pos  size  strpos+7  len-2) {
 -struct usb_interface_descriptor *desc;
 +struct usb_interface_descriptor desc;
  char if_str[8];
  
 -desc = (struct usb_interface_descriptor *) buf[pos];
 -if (desc-bLength  3)
 +memcpy(desc, buf[pos], sizeof(desc));
Copying it seems suboptimal. But is this actually an aliasing
violation? buf is a char array, and [1] says: a character type
may alias any other type.

[1] 
https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825

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

Re: [systemd-devel] [PATCH] fix strict aliasing violations in src/udev/udev-builtin-usb_id.c

[Shawn Landden]

On Wed, Mar 4, 2015 at 7:58 PM, Zbigniew Jędrzejewski-Szmek 
zbys...@in.waw.pl wrote:

 On Tue, Mar 03, 2015 at 04:21:30PM -0800, Shawn Landden wrote:
  also switch to inttypes.h
  ---
   src/udev/udev-builtin-usb_id.c | 35 ++-
   1 file changed, 18 insertions(+), 17 deletions(-)
 
  diff --git a/src/udev/udev-builtin-usb_id.c
 b/src/udev/udev-builtin-usb_id.c
  index ab0d96e..0223421 100644
  --- a/src/udev/udev-builtin-usb_id.c
  +++ b/src/udev/udev-builtin-usb_id.c
  @@ -28,6 +28,7 @@
   #include ctype.h
   #include fcntl.h
   #include errno.h
  +#include inttypes.h
 
   #include udev.h
 
  @@ -153,15 +154,15 @@ static int dev_if_packed_info(struct udev_device
 *dev, char *ifs_str, size_t len
   int pos = 0;
   unsigned strpos = 0;
   struct usb_interface_descriptor {
  -u_int8_tbLength;
  -u_int8_tbDescriptorType;
  -u_int8_tbInterfaceNumber;
  -u_int8_tbAlternateSetting;
  -u_int8_tbNumEndpoints;
  -u_int8_tbInterfaceClass;
  -u_int8_tbInterfaceSubClass;
  -u_int8_tbInterfaceProtocol;
  -u_int8_tiInterface;
  +uint8_tbLength;
  +uint8_tbDescriptorType;
  +uint8_tbInterfaceNumber;
  +uint8_tbAlternateSetting;
  +uint8_tbNumEndpoints;
  +uint8_tbInterfaceClass;
  +uint8_tbInterfaceSubClass;
  +uint8_tbInterfaceProtocol;
  +uint8_tiInterface;
   } __attribute__((packed));
 
   if (asprintf(filename, %s/descriptors,
 udev_device_get_syspath(dev))  0)
  @@ -179,21 +180,21 @@ static int dev_if_packed_info(struct udev_device
 *dev, char *ifs_str, size_t len
 
   ifs_str[0] = '\0';
   while (pos  size  strpos+7  len-2) {
  -struct usb_interface_descriptor *desc;
  +struct usb_interface_descriptor desc;
   char if_str[8];
 
  -desc = (struct usb_interface_descriptor *) buf[pos];
  -if (desc-bLength  3)
  +memcpy(desc, buf[pos], sizeof(desc));
 Copying it seems suboptimal. But is this actually an aliasing
 violation? buf is a char array, and [1] says: a character type
 may alias any other type.

 Common misunderstanding about strict aliasing. if accessing as char * yes,
but not the other way around. See the C11 standard which makes it clear
(don't have page number off the top of my head...)

 [1]
 https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825

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




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

Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Le 04/03/2015 16:27, Michael Biebl a écrit :

2015-03-04 15:41 GMT+01:00 Lennart Poettering lenn...@poettering.net:

Well, just removing the symlink is kinda pointless. It might still be pulled
in by anything else that implicitly depepends on /tmp.

What unit is supposed to pull in tmp.mount explicitly? If a generic
unit did that, this sounds like a bug.


It seems to be systemd-timesyncd.service. I still don't have an answer 
why it's sometimes activated in my kvm env (and rightly, with condition 
virtualized failing) and most of the time none. I'll try to spend some 
time on that before the end of week.


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

Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 03, 2015 at 05:18:00PM +, Jay Faulkner wrote:
 
 On Mar 3, 2015, at 8:55 AM, Topi Miettinen 
 toiwo...@gmail.commailto:toiwo...@gmail.com wrote:
 
 On 03/03/15 01:28, Jay Faulkner wrote:
 Hey,
 
 Lennart reviewed this in IRC and suggested I refactor the change in this
 manner. Now, we have an array of capability:sys call pairs, and iterate
 through that and then only add the seccomp filter if the capability
 doesn’t exist.
 
 The new patch is attached, and available
 here: https://github.com/jayofdoom/systemd/pull/5.patch.
Applied, with some changes. Please test that it still works for you.

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

Re: [systemd-devel] systemd-networkd and bonding config

[Mikhail Morfikov]

 Alternatively, if you're attached to the name bond0, you might be able
 to something like this (not tested with systemd-networkd):
 
 /etc/modprobe.d/rename-bond.conf:
 
 install bonding /usr/sbin/modprobe --ignore-install bonding \
   $CMDLINE_OPTS; /usr/sbin/ip link set dev bond0 down; \
   /usr/sbin/ifrename -c /dev/null -i bond0 -n FOO
 /dev/null
 

It doesn't work. It just removed bond interfaces completely (it
doesn't matter whether I use bond0 or bond1): 

root:~# networkctl
IDX LINK TYPE   OPERATIONAL SETUP
  1 lo   loopback   carrier configured
  2 eth1 ether  off configuring
  3 ifb0 ether  off unmanaged
  4 ifb1 ether  off unmanaged
  5 wlan0wlan   degradedconfiguring
  6 br_lxc   ether  no-carrier  configured

6 links listed.

Maybe I just stay with the bond1 interface.


pgpU2SChggEgT.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] core/socket: Add REMOTE_IP environment variable for Accept=true

[Shawn Landden]

Fix handling of abstract unix domain sockets too.
---
 TODO |  2 --
 man/systemd.socket.xml   |  5 -
 src/core/service.c   | 24 
 src/shared/socket-util.c | 25 +++--
 4 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/TODO b/TODO
index ae32388..780084a 100644
--- a/TODO
+++ b/TODO
@@ -164,8 +164,6 @@ Features:
 * as soon as we have kdbus, and sender timestamps, revisit coalescing multiple 
parallel daemon reloads:
   http://lists.freedesktop.org/archives/systemd-devel/2014-December/025862.html
 
-* set $REMOTE_IP (or $REMOTE_ADDR/$REMOTE_PORT) environment variable when 
doing per-connection socket activation. use format introduced by xinetd or CGI 
for this
-
 * the install state probably shouldn't get confused by generated units, think 
dbus1/kdbus compat!
 
 * in systemctl list-unit-files: show the install value the presets would 
suggest for a service in a third column
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 3938345..8796d7b 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -357,7 +357,10 @@
 daemons designed for usage with
 
citerefentryrefentrytitleinetd/refentrytitlemanvolnum8/manvolnum/citerefentry
 to work unmodified with systemd socket
-activation./para/listitem
+activation./para
+paraFor IPv4 and IPv6 connections the varnameREMOTE_IP/varname
+environment variable will be set with remote IP and port seperated by a
+colon (for SOCK_RAW the port is the IP protocol)./para/listitem
   /varlistentry
 
   varlistentry
diff --git a/src/core/service.c b/src/core/service.c
index a89ff3f..0942072 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1119,6 +1119,30 @@ static int service_spawn(
 goto fail;
 }
 
+if (s-accept_socket.unit) {
+union sockaddr_union pn;
+socklen_t pnlen = sizeof(pn);
+_cleanup_free_ char *remote_addr = NULL;
+
+r = getpeername(s-socket_fd, pn.sa, pnlen);
+if (r  0) {
+r = -errno;
+goto fail;
+}
+
+if (pn.sa.sun_family == AF_INET ||
+pn.sa.sun_family == AF_INET6) {
+r = sockaddr_pretty(pn.sa, pnlen, true, remote_addr);
+if (r  0)
+goto fail;
+
+if (asprintf(our_env + n_env++, REMOTE_IP=%s, 
remote_addr)  0) {
+r = -ENOMEM;
+goto fail;
+}
+}
+}
+
 final_env = strv_env_merge(2, UNIT(s)-manager-environment, our_env, 
NULL);
 if (!final_env) {
 r = -ENOMEM;
diff --git a/src/shared/socket-util.c b/src/shared/socket-util.c
index 74d90fa..dbe2bf7 100644
--- a/src/shared/socket-util.c
+++ b/src/shared/socket-util.c
@@ -522,19 +522,32 @@ int sockaddr_pretty(const struct sockaddr *_sa, socklen_t 
salen, bool translate_
 return -ENOMEM;
 
 } else if (sa-un.sun_path[0] == 0) {
+void *i;
 /* abstract */
 
-/* FIXME: We assume we can print the
- * socket path here and that it hasn't
- * more than one NUL byte. That is
- * actually an invalid assumption */
-
+/* see unix(7), abstract is wierd */
+i = memchr(sa-un.sun_path + 1, '\0', 
sizeof(sa-un.sun_path) - 1);
+if (i)
+for (i = (char *)i + 1;
+ (char *)i  
sa-un.sun_path[sizeof(sa-un.sun_path)];
+ i = (char *)i + 1)
+if (*(char *)i != '\0') {
+p = strdup(abstract 
unprintable);
+if (!p)
+return -ENOMEM;
+
+goto end;
+}
+
+/* no non-NUL bytes after second NUL (if any) */
 p = new(char, sizeof(sa-un.sun_path)+1);
 if (!p)
 return -ENOMEM;
 
 p[0] = '@';
 memcpy(p+1, sa-un.sun_path+1, 
sizeof(sa-un.sun_path)-1);
+
+/* make printable if there was no second NUL (i == 
NULL) */
 p[sizeof(sa-un.sun_path)] = 0;
 
 } else {
@@ -549,7 +562,7 @@ int sockaddr_pretty(const struct sockaddr *_sa, socklen_t 
salen, bool translate_
 

Re: [systemd-devel] systemd-networkd and bonding config

[Mikhail Morfikov]

 The logic here is that when we create a new bond we will create it
 with these settings, but we will not change the settings of a
 preexisting bond, as that may have been created by somebody else we
 don't know about so we figure better leave it alone.
 
 The confusing part here is that the kernel will create bond0 with
 default settings, and we will then not touch that. Ideally there would
 be a kernel config switch to make it not create default devices like
 that, but for the moment I think the best solution is to simply call
 your bond something else. So if you put bond1 everywhere instead
 things should JustWork(TM).

I performed some tests, and I was able to run my system without bond
interfaces. So I think there's nothing that could trigger creation of
these kind of interfaces. The next thing I did was to create a .netdev
file that set bond0 interface (+ the rest of config files), and
here's the log:

# journalctl -b | grep -i bond
Mar 05 05:04:12 morfikownia kernel: bonding: Ethernet Channel Bonding Driver: 
v3.7.1 (April 27, 2011)
Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0   : netdev 
ready
Mar 05 05:04:12 morfikownia kernel: IPv6: ADDRCONF(NETDEV_UP): bond0: link is 
not ready
Mar 05 05:04:12 morfikownia kernel: bonding: bond0: Enslaving wlan0 as an 
active interface with an up link
Mar 05 05:04:12 morfikownia kernel: IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link 
becomes ready
Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0   : bond0  
 : could not bring up interface: Invalid argument
Mar 05 05:04:12 morfikownia kernel: bonding: bond0: Enslaving eth1 as an active 
interface with an up link
Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0   : gained 
carrier
Mar 05 05:04:19 morfikownia systemd-networkd[862]: bond0   : DHCPv4 
address 192.168.1.113/24 via 192.168.1.1
Mar 05 05:04:19 morfikownia systemd-networkd[862]: bond0   : link 
configured

As you can see, there's nothing before it, so I don't understand why the
bond0 interface has some problems. Anyway, I changed the files and set
bond1 instead of bond0, and here's the log:

root:~# journalctl -b | grep -i bond
Mar 05 05:09:18 morfikownia kernel: bonding: Ethernet Channel Bonding Driver: 
v3.7.1 (April 27, 2011)
Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting MII monitoring 
interval to 1000
Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting up delay to 5000
Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting down delay to 5000
Mar 05 05:09:18 morfikownia systemd-networkd[945]: bond1   : netdev 
ready
Mar 05 05:09:19 morfikownia kernel: bonding: bond1: Enslaving wlan0 as an 
active interface with a down link
Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1   : gained 
carrier
Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1   : bond1  
 : could not bring up interface: Invalid argument
Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1   : lost 
carrier
Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1   : DHCPv4 
connection considered system critical, ignoring request to reconfigure it.
Mar 05 05:09:19 morfikownia kernel: bonding: bond1: Enslaving eth1 as an active 
interface with a down link
Mar 05 05:09:20 morfikownia kernel: bonding: bond1: link status up for 
interface wlan0, enabling it in 0 ms
Mar 05 05:09:20 morfikownia kernel: bonding: bond1: link status definitely up 
for interface wlan0, 0 Mbps full duplex
Mar 05 05:09:20 morfikownia kernel: bonding: bond1: first active interface up!
Mar 05 05:09:20 morfikownia systemd-networkd[945]: bond1   : gained 
carrier
Mar 05 05:09:22 morfikownia systemd-networkd[945]: bond1   : DHCPv4 
address 192.168.1.150/24 via 192.168.1.1
Mar 05 05:09:22 morfikownia systemd-networkd[945]: bond1   : link 
configured

It's a little bit longer, and as you can see there's just bond1 info
and nothing concerning bond0. Also the MAC address changed in this
point -- it looks like the bond0 interface caused that problem.

I thougt that the only one interface was created, but there were
two of them.

The bond0 interface looks like this:

root:~# cat /proc/net//bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (round-robin)
MII Status: down
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

and the other one:

root:~# cat /proc/net//bonding/bond1
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 1000
Up Delay (ms): 5000
Down Delay (ms): 5000

Slave Interface: wlan0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: c0:cb:38:01:f0:f5
Slave queue ID: 0

Slave Interface: eth1
MII Status: down
Speed: 10 Mbps
Duplex: half
Link Failure Count: 0
Permanent HW addr: 3c:4a:92:00:4c:5b
Slave queue ID: 0

and the bond1 works as 

[systemd-devel] is there a plan for NIC teaming support ?

[Branko]

I have a need to put my NICs in RAID0 so to speak, but according to 
materials I have found on net I can't use NIC bonding driver because I 
would need LACP (IEEE whatever) aware L2 switch, so I was refered to 
teaming driver, which should be ( if those folks is to be believed) 
replacing bond driver in future.


Since systemd doesn't support teaming ( teaming module + libeteam), I 
had to scotchstape it together under systemd and it was major PITA.


libteam doesn't seem to complicated to be included as a module in 
systemd, which should take away most of the headaches...




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

Re: [systemd-devel] [PATCH] fix strict aliasing violations in src/udev/udev-builtin-usb_id.c

[Shawn Landden]

Oh wait, I c, yes I had same question.

On Wed, Mar 4, 2015 at 8:07 PM, Shawn Landden sh...@churchofgit.com wrote:

 On Wed, Mar 4, 2015 at 7:58 PM, Zbigniew Jędrzejewski-Szmek 
 zbys...@in.waw.pl wrote:

 On Tue, Mar 03, 2015 at 04:21:30PM -0800, Shawn Landden wrote:
  also switch to inttypes.h
  ---
   src/udev/udev-builtin-usb_id.c | 35 ++-
   1 file changed, 18 insertions(+), 17 deletions(-)
 
  diff --git a/src/udev/udev-builtin-usb_id.c
 b/src/udev/udev-builtin-usb_id.c
  index ab0d96e..0223421 100644
  --- a/src/udev/udev-builtin-usb_id.c
  +++ b/src/udev/udev-builtin-usb_id.c
  @@ -28,6 +28,7 @@
   #include ctype.h
   #include fcntl.h
   #include errno.h
  +#include inttypes.h
 
   #include udev.h
 
  @@ -153,15 +154,15 @@ static int dev_if_packed_info(struct udev_device
 *dev, char *ifs_str, size_t len
   int pos = 0;
   unsigned strpos = 0;
   struct usb_interface_descriptor {
  -u_int8_tbLength;
  -u_int8_tbDescriptorType;
  -u_int8_tbInterfaceNumber;
  -u_int8_tbAlternateSetting;
  -u_int8_tbNumEndpoints;
  -u_int8_tbInterfaceClass;
  -u_int8_tbInterfaceSubClass;
  -u_int8_tbInterfaceProtocol;
  -u_int8_tiInterface;
  +uint8_tbLength;
  +uint8_tbDescriptorType;
  +uint8_tbInterfaceNumber;
  +uint8_tbAlternateSetting;
  +uint8_tbNumEndpoints;
  +uint8_tbInterfaceClass;
  +uint8_tbInterfaceSubClass;
  +uint8_tbInterfaceProtocol;
  +uint8_tiInterface;
   } __attribute__((packed));
 
   if (asprintf(filename, %s/descriptors,
 udev_device_get_syspath(dev))  0)
  @@ -179,21 +180,21 @@ static int dev_if_packed_info(struct udev_device
 *dev, char *ifs_str, size_t len
 
   ifs_str[0] = '\0';
   while (pos  size  strpos+7  len-2) {
  -struct usb_interface_descriptor *desc;
  +struct usb_interface_descriptor desc;
   char if_str[8];
 
  -desc = (struct usb_interface_descriptor *) buf[pos];
  -if (desc-bLength  3)
  +memcpy(desc, buf[pos], sizeof(desc));
 Copying it seems suboptimal. But is this actually an aliasing
 violation? buf is a char array, and [1] says: a character type
 may alias any other type.

 Common misunderstanding about strict aliasing. if accessing as char *
 yes, but not the other way around. See the C11 standard which makes it
 clear (don't have page number off the top of my head...)

 [1]
 https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825

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




 --
 Shawn Landden




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

Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Just for the record: I didn't try on trunk yet, only systemd v219 that 
we ship in vivid.


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

[systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Hey,

It seems that we discovered an issue if a service declares some 
relationship with a .mount unit.
For instance, having tmp.mount disable (and nothing mounting /tmp as 
tmpfs in fstab):


foo.service:
[Unit]
After=tmp.mount

[Service]
ExecStart=/bin/echo foo

[Install]
WantedBy=multi-user.target


Then, enable foo.service
Many reboots will have /tmp not mounted, but after some reboots (mostly 
 5), we can get:


tmpfs on /tmp type tmpfs (rw)
status on tmp.mount:
   Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor 
preset: enabled)

   Active: active (mounted) since Wed 2015-03-04 08:54:37 CET; 18min ago

rebooting systemd with debug logs, only one mention of foo.service, but 
we clearly see that tmp.mount is executed, even disabled:
Mar 04 08:54:37 autopkgtest systemd[1]: Deleting job tmp.mount/stop as 
dependency of job systemd-timesyncd.service/stop
Mar 04 08:54:37 autopkgtest systemd[1]: Deleting job foo.service/start 
as dependency of job tmp.mount/stop


Mar 04 08:54:37 autopkgtest systemd[1]: Installed new job 
tmp.mount/start as 50
Mar 04 08:54:37 autopkgtest systemd[1]: 
ConditionPathIsSymbolicLink=!/tmp succeeded for tmp.mount.
Mar 04 08:54:37 autopkgtest systemd[1]: About to execute: /bin/mount 
tmpfs /tmp -n -t tmpfs -o mode=1777,strictatime

Mar 04 08:54:37 autopkgtest systemd[1]: Forked /bin/mount as 171
Mar 04 08:54:37 autopkgtest systemd[1]: tmp.mount changed dead - mounting
Mar 04 08:54:37 autopkgtest systemd[1]: Mounting Temporary Directory...

Mar 04 08:54:37 autopkgtest systemd[1]: tmp.mount changed mounting - 
mounting-done
Mar 04 08:54:37 autopkgtest systemd[1]: Job tmp.mount/start finished, 
result=done

Mar 04 08:54:37 autopkgtest systemd[1]: Mounted Temporary Directory.


It seems then that any relationship (at least After/Conflicts) to a 
mount unit from a enabled service will trigger that mount unit to executes.


Did anyone else have seen something similar?
Cheers,
Didier

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

Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Andrei Borzenkov]

On Wed, Mar 4, 2015 at 11:21 AM, Didier Roche didro...@ubuntu.com wrote:
 Hey,

 It seems that we discovered an issue if a service declares some relationship
 with a .mount unit.
 For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
 in fstab):

 foo.service:
 [Unit]
 After=tmp.mount

 [Service]
 ExecStart=/bin/echo foo

 [Install]
 WantedBy=multi-user.target


 Then, enable foo.service
 Many reboots will have /tmp not mounted, but after some reboots (mostly 
 5), we can get:

 tmpfs on /tmp type tmpfs (rw)
 status on tmp.mount:
Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor preset:
 enabled)

It says enabled here, although I'm not sure what vendor preset means.

Active: active (mounted) since Wed 2015-03-04 08:54:37 CET; 18min ago

 rebooting systemd with debug logs, only one mention of foo.service, but we
 clearly see that tmp.mount is executed, even disabled:
 Mar 04 08:54:37 autopkgtest systemd[1]: Deleting job tmp.mount/stop as
 dependency of job systemd-timesyncd.service/stop
 Mar 04 08:54:37 autopkgtest systemd[1]: Deleting job foo.service/start as
 dependency of job tmp.mount/stop

 Mar 04 08:54:37 autopkgtest systemd[1]: Installed new job tmp.mount/start as
 50
 Mar 04 08:54:37 autopkgtest systemd[1]: ConditionPathIsSymbolicLink=!/tmp
 succeeded for tmp.mount.
 Mar 04 08:54:37 autopkgtest systemd[1]: About to execute: /bin/mount tmpfs
 /tmp -n -t tmpfs -o mode=1777,strictatime
 Mar 04 08:54:37 autopkgtest systemd[1]: Forked /bin/mount as 171
 Mar 04 08:54:37 autopkgtest systemd[1]: tmp.mount changed dead - mounting
 Mar 04 08:54:37 autopkgtest systemd[1]: Mounting Temporary Directory...

 Mar 04 08:54:37 autopkgtest systemd[1]: tmp.mount changed mounting -
 mounting-done
 Mar 04 08:54:37 autopkgtest systemd[1]: Job tmp.mount/start finished,
 result=done
 Mar 04 08:54:37 autopkgtest systemd[1]: Mounted Temporary Directory.


 It seems then that any relationship (at least After/Conflicts) to a mount
 unit from a enabled service will trigger that mount unit to executes.

 Did anyone else have seen something similar?
 Cheers,
 Didier

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

Re: [systemd-devel] [PATCH] networkd: Make DHCP client ID creation configurable

[Tom Gundersen]

Great stuff! Applied.

Thanks!

Tom

On Tue, Mar 3, 2015 at 7:49 PM, Jan Janssen medhe...@web.de wrote:
 ---
  man/systemd.network.xml  |  8 
  src/network/networkd-dhcp4.c | 16 
  src/network/networkd-network-gperf.gperf |  1 +
  src/network/networkd-network.c   |  9 +
  src/network/networkd.h   | 11 +++
  5 files changed, 45 insertions(+)

 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index 60252e5..3522551 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -564,6 +564,14 @@
/listitem
  /varlistentry
  varlistentry
 +  termvarnameClientIdentifier=/varname/term
 +  listitem
 +paraDHCP client identifier to use. Either 
 literalmac/literal
 +to use the MAC address of the link or literalduid/literal
 +(the default) to use a RFC4361-complient Client ID./para
 +  /listitem
 +/varlistentry
 +varlistentry
termvarnameVendorClassIdentifier=/varname/term
listitem
  paraThe vendor class identifier used to identify vendor
 diff --git a/src/network/networkd-dhcp4.c b/src/network/networkd-dhcp4.c
 index c3d0e3d..3832190 100644
 --- a/src/network/networkd-dhcp4.c
 +++ b/src/network/networkd-dhcp4.c
 @@ -661,5 +661,21 @@ int dhcp4_configure(Link *link) {
  return r;
  }

 +switch (link-network-dhcp_client_identifier) {
 +case DHCP_CLIENT_ID_DUID:
 +/* Library defaults to this. */
 +break;
 +case DHCP_CLIENT_ID_MAC:
 +r = sd_dhcp_client_set_client_id(link-dhcp_client,
 + ARPHRD_ETHER,
 + (const uint8_t *) 
 link-mac,
 + sizeof (link-mac));
 +if (r  0)
 +return r;
 +break;
 +default:
 +assert_not_reached(Unknown client identifier type.);
 +}
 +
  return 0;
  }
 diff --git a/src/network/networkd-network-gperf.gperf 
 b/src/network/networkd-network-gperf.gperf
 index b0c23a7..93df83a 100644
 --- a/src/network/networkd-network-gperf.gperf
 +++ b/src/network/networkd-network-gperf.gperf
 @@ -58,6 +58,7 @@ Route.Destination,   config_parse_destination,  
  0,
  Route.Source,config_parse_destination,   0,  
0
  Route.Metric,config_parse_route_priority,0,  
0
  Route.Scope, config_parse_route_scope,   0,  
0
 +DHCP.ClientIdentifier,   config_parse_dhcp_client_identifier,0,  
offsetof(Network, dhcp_client_identifier)
  DHCP.UseDNS, config_parse_bool,  0,  
offsetof(Network, dhcp_dns)
  DHCP.UseMTU, config_parse_bool,  0,  
offsetof(Network, dhcp_mtu)
  DHCP.UseHostname,config_parse_bool,  0,  
offsetof(Network, dhcp_hostname)
 diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
 index 0ba0c75..f7f6eaf 100644
 --- a/src/network/networkd-network.c
 +++ b/src/network/networkd-network.c
 @@ -103,6 +103,7 @@ static int network_load_one(Manager *manager, const char 
 *filename) {
  network-dhcp_routes = true;
  network-dhcp_sendhost = true;
  network-dhcp_route_metric = DHCP_ROUTE_METRIC;
 +network-dhcp_client_identifier = DHCP_CLIENT_ID_DUID;

  network-llmnr = LLMNR_SUPPORT_YES;

 @@ -600,6 +601,14 @@ int config_parse_dhcp(
  return 0;
  }

 +static const char* const dhcp_client_identifier_table[_DHCP_CLIENT_ID_MAX] = 
 {
 +[DHCP_CLIENT_ID_MAC] = mac,
 +[DHCP_CLIENT_ID_DUID] = duid
 +};
 +
 +DEFINE_PRIVATE_STRING_TABLE_LOOKUP_FROM_STRING(dhcp_client_identifier, 
 DCHPClientIdentifier);
 +DEFINE_CONFIG_PARSE_ENUM(config_parse_dhcp_client_identifier, 
 dhcp_client_identifier, DCHPClientIdentifier, Failed to parse client 
 identifier type);
 +
  static const char* const llmnr_support_table[_LLMNR_SUPPORT_MAX] = {
  [LLMNR_SUPPORT_NO] = no,
  [LLMNR_SUPPORT_YES] = yes,
 diff --git a/src/network/networkd.h b/src/network/networkd.h
 index e75746f..8bdc2be 100644
 --- a/src/network/networkd.h
 +++ b/src/network/networkd.h
 @@ -83,6 +83,13 @@ typedef enum LinkOperationalState {
  _LINK_OPERSTATE_INVALID = -1
  } LinkOperationalState;

 +typedef enum DCHPClientIdentifier {
 +DHCP_CLIENT_ID_MAC,
 +DHCP_CLIENT_ID_DUID,
 +_DHCP_CLIENT_ID_MAX,
 +_DHCP_CLIENT_ID_INVALID = -1,
 +} DCHPClientIdentifier;
 +
  struct FdbEntry {

Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Le 04/03/2015 09:29, Andrei Borzenkov a écrit :

On Wed, Mar 4, 2015 at 11:21 AM, Didier Roche didro...@ubuntu.com wrote:


tmpfs on /tmp type tmpfs (rw)
status on tmp.mount:
Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor preset:
enabled)

It says enabled here, although I'm not sure what vendor preset means.


The first one is disabled, which is the current state. vendor preset 
is what the preset set it by default, but we don't use it (yet) on 
debian/ubuntu. Only the first status is important there and confirms 
that tmp.mount is disabled.


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

Re: [systemd-devel] [PATCH 1/1] sd-dhcp6-client: delay setting the DUID and don't fail constructor

[Tom Gundersen]

Nicely done. Applied.

Though, I must say that a missing /etc/machine-id sounds like a pretty
serious problem, so not sure adding workarounds for that makes sense
(but that's anyway not part of this patch).

Cheers,

Tom

On Tue, Mar 3, 2015 at 9:06 PM, Thomas Haller thal...@redhat.com wrote:
 sd_dhcp6_client_new() tried to set the DUID based on the machine id.
 If the host has no /etc/machine-id, the constructor would fail
 making it impossible to create an sd_dhcp6_client instance.

 Relax this and create a DUID only later as needed. This way a caller
 caller can workaround a missing machine-id file and set a DUID of his
 choosing via sd_dhcp6_client_set_duid().
 ---
  src/libsystemd-network/sd-dhcp6-client.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

 diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
 b/src/libsystemd-network/sd-dhcp6-client.c
 index a432bbf..3db1cb0 100644
 --- a/src/libsystemd-network/sd-dhcp6-client.c
 +++ b/src/libsystemd-network/sd-dhcp6-client.c
 @@ -158,6 +158,13 @@ int sd_dhcp6_client_set_mac(sd_dhcp6_client *client, 
 const uint8_t *addr,
  return 0;
  }

 +static int client_ensure_duid(sd_dhcp6_client *client)
 +{
 +if (client-duid_len != 0)
 +return 0;
 +return dhcp_identifier_set_duid_en(client-duid, client-duid_len);
 +}
 +
  int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, uint16_t type, uint8_t 
 *duid,
   size_t duid_len)
  {
 @@ -378,6 +385,7 @@ static int client_send_message(sd_dhcp6_client *client, 
 usec_t time_now) {
  if (r  0)
  return r;

 +assert (client-duid_len);
  r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
  client-duid_len, client-duid);
  if (r  0)
 @@ -1108,6 +1116,10 @@ int sd_dhcp6_client_start(sd_dhcp6_client *client)
  if (r  0)
  return r;

 +r = client_ensure_duid(client);
 +if (r  0)
 +return r;
 +
  r = dhcp6_network_bind_udp_socket(client-index, NULL);
  if (r  0)
  return r;
 @@ -1205,7 +1217,6 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client 
 *client) {
  int sd_dhcp6_client_new(sd_dhcp6_client **ret)
  {
  _cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
 -int r;
  size_t t;

  assert_return(ret, -EINVAL);
 @@ -1222,11 +1233,6 @@ int sd_dhcp6_client_new(sd_dhcp6_client **ret)

  client-fd = -1;

 -/* initialize DUID */
 -r = dhcp_identifier_set_duid_en(client-duid, client-duid_len);
 -if (r  0)
 -return r;
 -
  client-req_opts_len = ELEMENTSOF(default_req_opts);

  client-req_opts = new0(be16_t, client-req_opts_len);
 --
 1.9.3

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

[systemd-devel] systemd-networkd 219 chokes on can device

[Mads]

I have an Atom NM10-based industrial PC with three e1000e devices and a 
PEAK can device (PCI ID 001c:0008). After updating from 216 to 219, 
systemd-networkd is unable to get my e1000e-devices up and running. I 
don't have any configuration for can0 within /etc/systemd/network.


Two files in /etc/systemd/network, 10-eth0.network and 10-eth1.network. 
System booted with net.ifnames=0. (I use a oneshot .service with some ip 
commands to up the can0-interface that worked with version 216. I can 
provide this .service if needed.)


# cat /etc/systemd/network/10-eth*
[Match]
Name=eth0

[Network]
Address=10.20.0.3/24
Gateway=10.20.0.1

[Match]
Name=eth1

[Network]
Address=10.30.0.3/24
Gateway=10.30.0.1




Here's the log from systemd-networkd both during boot (timestamp 
09:48:34) and when upping the can0 device and typing `systemctl restart 
systemd-networkd´ (timestamp 09:50:53).


# journalctl -b -u systemd-networkd
-- Logs begin at ma. 2015-03-02 13:13:09 UTC, end at on. 2015-03-04 
09:50:53 UTC. --

mars 04 09:48:34 hmi02 systemd[1]: Starting Network Service...
mars 04 09:48:34 hmi02 systemd-networkd[149]: Enumeration completed
mars 04 09:48:34 hmi02 systemd[1]: Started Network Service.
mars 04 09:48:34 hmi02 systemd-networkd[149]: can0: gained 
carrier

mars 04 09:50:53 hmi02 systemd[1]: Starting Network Service...
mars 04 09:50:53 hmi02 systemd-networkd[233]: Enumeration completed
mars 04 09:50:53 hmi02 systemd[1]: Started Network Service.
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth1: Cannot 
configure IPv6 forwarding for interface: No such file or directory
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth0: Cannot 
configure IPv6 forwarding for interface: No such file or directory
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth1: eth1 
   : could not bring up interface: Address family not supported by 
protocol
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth0: eth0 
   : could not bring up interface: Address family not supported by 
protocol
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth1: eth1 
   : could not set route: Network is unreachable
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth1: link 
configured
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth0: eth0 
   : could not set route: Network is unreachable
mars 04 09:50:53 hmi02 systemd-networkd[233]: eth0: link 
configured



The log says link configured, but the interfaces (eth0 and eth1) are 
not in a RUNNING state even after running `systemctl restart 
systemd-networkd´


The best solution would of course be full CAN device support in systemd, 
but for now.. are there some way to make systemd-networkd completely 
ignore a network device, thus making systemd 219 able to bring my eth0 
and eth1-devices up and running?


# systemctl --version
systemd 219
+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP 
-LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS 
+KMOD -IDN



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

Re: [systemd-devel] systemd-networkd and bonding config

[Tom Gundersen]

Hi Mikhail,

On Sat, Feb 28, 2015 at 1:26 PM, Mikhail Morfikov mmorfi...@gmail.com wrote:
 I've just finished migration from /etc/init.d/networking script to
 systemd-networkd solution, and I just wanted to ask a couple of things.

 First, I have two interfaces -- one wire (eth1) and one wifi (wlan0),
 and I want them to be bonded into one bond0 interface. I had that
 solution when I was using sysvinit, and, so far, I haven't played with
 the network settings. After some reading, I managed to set the exact
 same setup and it works, more or less.

 Here are the questions:

 1. How to set a MAC address to the bond0 interface? So far, I created
 05-bond0.link file:

 # cat  /etc/systemd/network/05-bond0.link
 [Match]
 Driver=bonding
 Name=bond0

 [Link]
 MACAddress=3c:4a:92:00:4c:5b

 The MAC address is the MAC address of the eth1 interface. Is this the
 right way to do it?

You don't need to have a .link file for bonding devices. .link files
are a way to override the kernel defaults for network devices that we
don't create (i.e., wlan0/eth0 and typically other real hardware). For
virtual devices that we create we can just set the correct information
at creation time, which is done in .netdev files. But see below.

 2. I noticed that the bonding information is bugged for some reason, I
 mean, when you check it under:

 # cat /proc/net/bonding/bond0
 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

 Bonding Mode: load balancing (round-robin)
 MII Status: up
 MII Polling Interval (ms): 0
 Up Delay (ms): 0
 Down Delay (ms): 0

 Slave Interface: wlan0
 MII Status: up
 Speed: Unknown
 Duplex: Unknown
 Link Failure Count: 0
 Permanent HW addr: c0:cb:38:01:f0:f5
 Slave queue ID: 0

 Slave Interface: eth1
 MII Status: up
 Speed: 10 Mbps
 Duplex: half
 Link Failure Count: 0
 Permanent HW addr: 3c:4a:92:00:4c:5b
 Slave queue ID: 0

 it gives you the proper interfaces, but Up/Down Delay are set to 0
 and Link Failure Count doesn't count anything. The Bonding Mode is
 also wrong.

 This is the bonding file for networkd :

 # cat 20-bond0.netdev
 [NetDev]
 Description=Bonding interface
 Name=bond0
 Kind=bond
 MACAddress=3c:4a:92:00:4c:5b

 [Bond]
 Mode=active-backup
 MIIMonitorSec=200
 UpDelaySec=1000
 DownDelaySec=1000

 Is the information bugged, or should I check some other file in order to
 see the bonding settings?

The logic here is that when we create a new bond we will create it
with these settings, but we will not change the settings of a
preexisting bond, as that may have been created by somebody else we
don't know about so we figure better leave it alone.

The confusing part here is that the kernel will create bond0 with
default settings, and we will then not touch that. Ideally there would
be a kernel config switch to make it not create default devices like
that, but for the moment I think the best solution is to simply call
your bond something else. So if you put bond1 everywhere instead
things should JustWork(TM).

 3. I don't know why, but sometimes (at boot stage) I get the following
 error message:

 # journalctl -b -1 -u systemd-networkd
 -- Logs begin at Sun 2015-02-22 21:48:12 CET, end at Sat 2015-02-28 12:33:57 
 CET. --
 Feb 28 12:08:26 morfikownia systemd[1]: Starting Network Service...
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: bond0   : netdev 
 ready
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: br_lxc  : netdev 
 ready
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: Enumeration completed
 Feb 28 12:08:27 morfikownia systemd[1]: Started Network Service.
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: ifb0: lost 
 carrier
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: ifb1: lost 
 carrier
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: ifb0: gained 
 carrier
 Feb 28 12:08:27 morfikownia systemd-networkd[1165]: ifb1: gained 
 carrier
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: bond0   : bond0   
 : could not bring up interface: Invalid argument
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: br_lxc  : br_lxc  
 : could not bring up interface: Invalid argument
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: br_lxc  : link 
 configured
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: wlan0   : wlan0   
 : could not join netdev: Operation not permitted
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: wlan0   : failed
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: eth1: link 
 configured
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: lo  : link 
 configured
 Feb 28 12:08:28 morfikownia systemd-networkd[1165]: bond0   : gained 
 carrier
 Feb 28 12:08:34 morfikownia systemd-networkd[1165]: wlan0   : gained 
 carrier
 Feb 28 12:11:02 morfikownia systemd-networkd[1165]: wlan0   : lost 
 carrier

 But after the boot stage, when I restart the 

Re: [systemd-devel] Cannot acquire DHCP lease

[Tom Gundersen]

On Thu, Feb 26, 2015 at 7:31 PM, Jan Janssen medhe...@web.de wrote:
 Hi,
 since commit commit 5bac5235934fabe5a3e6a9d47f4812f81034c427, networkd
 cannot acquire DHCP leases on my router if I dual boot with windows.

 It seems to be that my router is borked since I do get leases after
 resetting it to factory defaults, but once booting into the other OS, DHCP
 doesn't work anymore (whichever OS acquired the lease first wins and can
 still get leases after reboots).
 I never used to have this issue until I switched to a new computer with a
 different network card (RTL-8110SC/8169SC). dhclient/dhcpcd also have this
 issue for me, but afaik they can change the clientid method to be used,
 though I never got to use it myself because networkd's implementation just
 worked for me, until it broke :(

 The debug logs don't show anything interesting; it's just stuck in an DHCP
 discover loop.

This sounds weird. Like the server is doing some verification of the
client identity and just ignoring the request if it finds
inconsistencies. At any rate, making this configurable makes sense so
people can get the same lease across several OSs or several dhcp
client implementations, so the patch you sent makes sense!

 5bac5235934fabe5a3e6a9d47f4812f81034c427 is the first bad commit
 commit 5bac5235934fabe5a3e6a9d47f4812f81034c427
 Author: Tom Gundersen t...@jklm.no
 Date:   Thu Jan 22 00:53:16 2015 +0100

 sd-dhcp-client: use RFC4361-complient ClientID by default

 In addition to the benefits listed in the RFC, this allows DHCP to work
 also in
 case several interfaces share the same MAC address on the same link
 (IPVLAN).

 Note that this will make the ClientID (so probably the assigned IP
 address)
 change on upgrades. If it is desired to avoid that we would have to
 remember and
 write back the ID (which the library supports, but networkd currently
 does not).

 :04 04 0f27d5041b1050e580a329c8c23fd12e1e2c552b
 f1cf96e838f0f4d91c774c3d82346b2ad94465ac M  src
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Lennart Poettering]

On Wed, 04.03.15 09:21, Didier Roche (didro...@ubuntu.com) wrote:

 Hey,
 
 It seems that we discovered an issue if a service declares some relationship
 with a .mount unit.
 For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
 in fstab):

tmp.mount is enabled statically via the
/usr/lib/systemd/system/local-fs.target.wants/tmp.mount symlink.

Also, note that system automatically creates the necessary deps to a
mount for a variety of cases when something below that mount is
referenced. 

Disabling a mount unit is not sufficient to not start it, if it
is referenced explicitly or implicitly by another unit.

Use systemctl show tmp.mount to see by which dependencies it was
pulled in.

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] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Le 04/03/2015 12:49, Lennart Poettering a écrit :

On Wed, 04.03.15 09:21, Didier Roche (didro...@ubuntu.com) wrote:


Hey,

It seems that we discovered an issue if a service declares some relationship
with a .mount unit.
For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
in fstab):

tmp.mount is enabled statically via the
/usr/lib/systemd/system/local-fs.target.wants/tmp.mount symlink.
We have a distro-patched in debian to remove this symlink. Note that 
otherwise, it wouldn't be started only on some boots and not on others, 
which shows that there is an erratic behavior.




Also, note that system automatically creates the necessary deps to a
mount for a variety of cases when something below that mount is
referenced.

Disabling a mount unit is not sufficient to not start it, if it
is referenced explicitly or implicitly by another unit.

Use systemctl show tmp.mount to see by which dependencies it was
pulled in.


Nice hint! So, on boots where tmp.mount is enabled, here is what 
systemctl show on the unit gives:

RequiredBy=systemd-timesyncd.service
Conflicts=umount.target
ConflictedBy=foo.service
Before=systemd-timesyncd.service foo.service local-fs.target umount.target

systemd-timesyncd.service though is condition failed:
Condition: start condition failed at Wed 2015-03-04 13:09:09 CET; 3min 
10s ago

   ConditionVirtualization=no was not met

So, even if the condition for an unit failed, the Requires= are started? 
I noted that on boot where the tmpfs isn't mounted, 
systemd-timesyncd.service stays inactive:

   Active: inactive (dead)
ExecMainStartTimestampMonotonic=0
ExecMainExitTimestampMonotonic=0

and if I try to start it (and we get the condition fail), the Requires 
(tmp.mount in that case) is started.


It seems there are 2 issues:
- systemd-timesyncd.service is seldomly activated on boot on those 
machines. (I'll dive into why)
- if an unit as a Condition failing, the Requirements of those units are 
still activated.


Is the last behavior expected?
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/1] sd-dhcp6-client: delay setting the DUID and don't fail constructor

[Lennart Poettering]

On Tue, 03.03.15 21:06, Thomas Haller (thal...@redhat.com) wrote:

 sd_dhcp6_client_new() tried to set the DUID based on the machine id.
 If the host has no /etc/machine-id, the constructor would fail
 making it impossible to create an sd_dhcp6_client instance.

We do not even allow bootups without /etc/machine-id.

If the file is missing then things really *should* fail.

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 1/1] sd-dhcp6-client: delay setting the DUID and don't fail constructor

[Thomas Haller]

On Wed, 2015-03-04 at 12:52 +0100, Lennart Poettering wrote:
 On Tue, 03.03.15 21:06, Thomas Haller (thal...@redhat.com) wrote:
 
  sd_dhcp6_client_new() tried to set the DUID based on the machine id.
  If the host has no /etc/machine-id, the constructor would fail
  making it impossible to create an sd_dhcp6_client instance.
 
 We do not even allow bootups without /etc/machine-id.
 
 If the file is missing then things really *should* fail.

Hi


I understand, and agree that it makes sense for systemd.

networkd will still fail, at bit later.



With this change, libsystemd-network might handle systems without
machine-id file -- as long as the user cares and sets an alternative
DUID via  sd_dhcp6_client_set_duid().

That is interesting for NetworkManager.


Thomas


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Lennart Poettering]

On Wed, 04.03.15 13:19, Didier Roche (didro...@ubuntu.com) wrote:

 Le 04/03/2015 12:49, Lennart Poettering a écrit :
 On Wed, 04.03.15 09:21, Didier Roche (didro...@ubuntu.com) wrote:
 
 Hey,
 
 It seems that we discovered an issue if a service declares some relationship
 with a .mount unit.
 For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
 in fstab):
 tmp.mount is enabled statically via the
 /usr/lib/systemd/system/local-fs.target.wants/tmp.mount symlink.

 We have a distro-patched in debian to remove this symlink. Note that
 otherwise, it wouldn't be started only on some boots and not on others,
 which shows that there is an erratic behavior.

Well, it's affected by jobs later queued in. You are using Conflicts
against the unit, apparently. Now, conflicts has different effects for
later queued jobs. depending on the mode setting the conflicting job
is either removed, or the unit stopped or the job fails.

 Use systemctl show tmp.mount to see by which dependencies it was
 pulled in.
 
 Nice hint! So, on boots where tmp.mount is enabled, here is what systemctl
 show on the unit gives:
 RequiredBy=systemd-timesyncd.service
 Conflicts=umount.target
 ConflictedBy=foo.service

What is this ConflictedBy actually about? Why?

Ihave the suspicion you assume conflicts= has different behaviour that
it actually means.

 Before=systemd-timesyncd.service foo.service local-fs.target umount.target
 
 systemd-timesyncd.service though is condition failed:
 Condition: start condition failed at Wed 2015-03-04 13:09:09 CET; 3min 10s
 ago
ConditionVirtualization=no was not met
 
 So, even if the condition for an unit failed, the Requires= are
 started? 

Yes. ConditionXYZ= only shortcuts the executon of the service, all its
deps are pulled in. The condition is checked at the time the unit is
about to be started, which means that at that time the dependencies
usually are fulfilled anyway already. 

Also see docs about this in the man page.

 I
 noted that on boot where the tmpfs isn't mounted, systemd-timesyncd.service
 stays inactive:
Active: inactive (dead)
 ExecMainStartTimestampMonotonic=0
 ExecMainExitTimestampMonotonic=0
 
 and if I try to start it (and we get the condition fail), the Requires
 (tmp.mount in that case) is started.
 
 It seems there are 2 issues:
 - systemd-timesyncd.service is seldomly activated on boot on those machines.
 (I'll dive into why)
 - if an unit as a Condition failing, the Requirements of those units are
 still activated.

Yes, absolutely, see man pages.

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] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Le 04/03/2015 13:40, Lennart Poettering a écrit :

On Wed, 04.03.15 13:19, Didier Roche (didro...@ubuntu.com) wrote:


Le 04/03/2015 12:49, Lennart Poettering a écrit :

On Wed, 04.03.15 09:21, Didier Roche (didro...@ubuntu.com) wrote:


Hey,

It seems that we discovered an issue if a service declares some relationship
with a .mount unit.
For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
in fstab):

tmp.mount is enabled statically via the
/usr/lib/systemd/system/local-fs.target.wants/tmp.mount symlink.

We have a distro-patched in debian to remove this symlink. Note that
otherwise, it wouldn't be started only on some boots and not on others,
which shows that there is an erratic behavior.

Well, it's affected by jobs later queued in. You are using Conflicts
against the unit, apparently. Now, conflicts has different effects for
later queued jobs. depending on the mode setting the conflicting job
is either removed, or the unit stopped or the job fails.


Use systemctl show tmp.mount to see by which dependencies it was
pulled in.

Nice hint! So, on boots where tmp.mount is enabled, here is what systemctl
show on the unit gives:
RequiredBy=systemd-timesyncd.service
Conflicts=umount.target
ConflictedBy=foo.service

What is this ConflictedBy actually about? Why?

Ihave the suspicion you assume conflicts= has different behaviour that
it actually means.


Ok, giving a little bit more context. So, we don't enable /tmp on tmpfs 
in debian/ubuntu (the symlink is removed as a distro patch). We had with 
sysvinit and upstart a failsafe mechanism if / is nearly full:
in that case /tmp is mounted as tmpfs and marked as overflow (some 
scripts in ubuntu looks for that name and warn the user), trying to boot 
the system as far as we can. The idea was to recreate this functionality 
under systemd (bug: 
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1392637).


* I was first proposing a generator for that: 
https://launchpadlibrarian.net/199267346/0001-Add-systemd-emergency-tmpfs-to-force-tmpfs-on-tmp.patch 
which would enable unconditionally (even if manually enabled by the 
sysadmin) the tmp.mount unit and add the overflow tag.
* Martin (see bug comments) thinks that the check is too early (on the 
ro filesystem as our root filesystem is mounted as read only) and maybe 
there is a fstab mount for /tmp with more spaces. There is also the 
issue that we are maybe on permanent read only images (like with snappy) 
and so, no free space, (and then /tmp would be mounted as tmpfs via 
enabling tmp.mount, but we don't want to mark is as overflow).
* For those reasons, we tried  to rather go with a service started later 
at boot time doing that check. I tried to do a quick one: 
http://paste.ubuntu.com/10523961/, and that's where we started to see 
tmp.mount being activated at some boots, and not on others (which 
triggered that email).


Any suggestion on how we should tackle this? (I don't really like the 
additional service approach and way more prefer the first declarative 
approach).






Before=systemd-timesyncd.service foo.service local-fs.target umount.target

systemd-timesyncd.service though is condition failed:
Condition: start condition failed at Wed 2015-03-04 13:09:09 CET; 3min 10s
ago
ConditionVirtualization=no was not met

So, even if the condition for an unit failed, the Requires= are
started?

Yes. ConditionXYZ= only shortcuts the executon of the service, all its
deps are pulled in. The condition is checked at the time the unit is
about to be started, which means that at that time the dependencies
usually are fulfilled anyway already.

Also see docs about this in the man page.


I
noted that on boot where the tmpfs isn't mounted, systemd-timesyncd.service
stays inactive:
Active: inactive (dead)
ExecMainStartTimestampMonotonic=0
ExecMainExitTimestampMonotonic=0

and if I try to start it (and we get the condition fail), the Requires
(tmp.mount in that case) is started.

It seems there are 2 issues:
- systemd-timesyncd.service is seldomly activated on boot on those machines.
(I'll dive into why)
- if an unit as a Condition failing, the Requirements of those units are
still activated.

Yes, absolutely, see man pages.


Ok, that makes sense (still need to look at why we are getting in those 
qemu instances systemd-timesyncd started at boot some times, not on others).


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

Re: [systemd-devel] systemd-networkd 219 chokes on can device

[Mads]

With the help of grawity on irc, I assembled this small patch file for a 
possible temporary workaround. Just hardcoded systemd-networkd to not 
touch the can0 interface.


--- a/src/network/networkd-manager.c2015-02-11 17:30:31.800897770 
+0100
+++ b/src/network/networkd-manager.c2015-03-04 15:06:42.091892185 
+0100

@@ -322,6 +322,10 @@

 switch (type) {
 case RTM_NEWLINK:
+
+if (strcmp(can0, name) == 0)
+return 0;
+
 if (!link) {
 /* link is new, so add it */
 r = link_add(m, message, link);
@@ -347,6 +351,9 @@
 break;

 case RTM_DELLINK:
+
+if (strcmp(can0, name) == 0)
+return 0;
 link_drop(link);
 netdev_drop(netdev);




Unfortunately, it doesn't fix the problem completely. The 
systemd-networkd log now appears during boot exactly like the log in my 
previous mail when I manually restarted the service (at timestamp 
09:50:53), so it doesn't try to link_add can0 anymore. But my eth0 and 
eth1 interfaces still doesn't go up (not after manually invoking 
`systemctl restart systemd-networkd´ either). They just get configured, 
not upped.


What does the workaround lack to make that work?

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