date:20150421

On Tue, 14.04.15 22:01, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

I added some more logging (so that automount_dispatch_expire() can
never fail without this being logged) and applied it!

I only gave this superficial testing though, please check if this all
still works fine for you now!

Thanks!

 ---
 Changes in v2:
  - addressed comments
  - check every MAX(a-timeout_idle_usec/10, USEC_PER_SEC) instead of every
5 seconds
 
  man/systemd.automount.xml |   8 ++
  man/systemd.mount.xml |   9 ++
  src/core/automount.c  | 221 
 --
  src/core/automount.h  |   6 +-
  src/core/dbus-automount.c |   1 +
  src/core/load-fragment-gperf.gperf.m4 |   1 +
  src/core/mount.c  |  20 +--
  src/fstab-generator/fstab-generator.c |  24 
  8 files changed, 262 insertions(+), 28 deletions(-)
 
 diff --git a/man/systemd.automount.xml b/man/systemd.automount.xml
 index b5b5885cdff2..9561590c5c89 100644
 --- a/man/systemd.automount.xml
 +++ b/man/systemd.automount.xml
 @@ -135,6 +135,14 @@
  creating these directories. Takes an access mode in octal
  notation. Defaults to 0755./para/listitem
/varlistentry
 +  varlistentry
 +termvarnameTimeoutIdleSec=/varname/term
 +listitemparaConfigures an idleness timeout. Once the mount has 
 been
 +idle for the specified time, systemd will attempt to unmount. Takes a
 +unit-less value in seconds, or a time span value such as 5min 20s.
 +Pass 0 to disable the timeout logic. The timeout is disabled by
 +default./para/listitem
 +  /varlistentry
  /variablelist
/refsect1
  
 diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml
 index fcb9a4416104..e102d27ab762 100644
 --- a/man/systemd.mount.xml
 +++ b/man/systemd.mount.xml
 @@ -148,6 +148,15 @@
/varlistentry
  
varlistentry
 +termoptionx-systemd.idle-timeout=/option/term
 +
 +listitemparaConfigures the idleness timeout of the
 +automount unit. See varnameTimeoutIdleSec=/varname in
 +
 citerefentryrefentrytitlesystemd.automount/refentrytitlemanvolnum5/manvolnum/citerefentry
 +for details./para/listitem
 +  /varlistentry
 +
 +  varlistentry
  termoptionx-systemd.device-timeout=/option/term
  
  listitemparaConfigure how long systemd should wait for a
 diff --git a/src/core/automount.c b/src/core/automount.c
 index ce484ff1cd16..1cf108524a80 100644
 --- a/src/core/automount.c
 +++ b/src/core/automount.c
 @@ -42,6 +42,7 @@
  #include bus-error.h
  #include formats-util.h
  #include process-util.h
 +#include async.h
  
  static const UnitActiveState state_translation_table[_AUTOMOUNT_STATE_MAX] = 
 {
  [AUTOMOUNT_DEAD] = UNIT_INACTIVE,
 @@ -50,6 +51,22 @@ static const UnitActiveState 
 state_translation_table[_AUTOMOUNT_STATE_MAX] = {
  [AUTOMOUNT_FAILED] = UNIT_FAILED
  };
  
 +struct expire_data {
 +int dev_autofs_fd;
 +int ioctl_fd;
 +};
 +
 +static inline void expire_data_free(struct expire_data *data) {
 +if (!data)
 +return;
 +
 +safe_close(data-dev_autofs_fd);
 +safe_close(data-ioctl_fd);
 +free(data);
 +}
 +
 +DEFINE_TRIVIAL_CLEANUP_FUNC(struct expire_data*, expire_data_free);
 +
  static int open_dev_autofs(Manager *m);
  static int automount_dispatch_io(sd_event_source *s, int fd, uint32_t 
 events, void *userdata);
  
 @@ -81,13 +98,16 @@ static void repeat_unmount(const char *path) {
  }
  }
  
 +static int automount_send_ready(Automount *a, Set *tokens, int status);
 +
  static void unmount_autofs(Automount *a) {
  assert(a);
  
  if (a-pipe_fd  0)
  return;
  
 -automount_send_ready(a, -EHOSTDOWN);
 +automount_send_ready(a, a-tokens, -EHOSTDOWN);
 +automount_send_ready(a, a-expire_tokens, -EHOSTDOWN);
  
  a-pipe_event_source = sd_event_source_unref(a-pipe_event_source);
  a-pipe_fd = safe_close(a-pipe_fd);
 @@ -112,6 +132,10 @@ static void automount_done(Unit *u) {
  
  set_free(a-tokens);
  a-tokens = NULL;
 +set_free(a-expire_tokens);
 +a-expire_tokens = NULL;
 +
 +a-expire_event_source = 
 sd_event_source_unref(a-expire_event_source);
  }
  
  static int automount_add_mount_links(Automount *a) {
 @@ -265,6 +289,7 @@ static int automount_coldplug(Unit *u, Hashmap 
 *deferred_work) {
  }
  
  static void automount_dump(Unit *u, FILE *f, const char *prefix) {
 +char time_string[FORMAT_TIMESPAN_MAX];
  Automount *a = AUTOMOUNT(u);
  
  assert(a);
 @@ -273,11 +298,13 @@ static void automount_dump(Unit *u, FILE *f, const char 
 *prefix) {
  %sAutomount State: %s\n
  %sResult: %s\n
  %sWhere: %s\n
 -%sDirectoryMode: %04o\n,
 +

Re: [systemd-devel] Zombie process still exists after stopping gdm.service

2015-04-21 Thread Daniel Drake

On Mon, Apr 20, 2015 at 6:29 PM, Lennart Poettering
lenn...@poettering.net wrote:
 Sure, we don't want to keep track of which processes we already
 killed, to distuingish them from the processes newly created in the
 time between our sending of SIGTERM and receiving SIGCHLD for the main
 process.

 We assume that if we get SIGCHLD for the main process that the daemon
 is down, and everything that is left over then is auxiliary stuff we
 can kill.

OK, doesn't sound unreasonable. Once we get to the end of this topic,
I'll submit a documentation patch to make that a bit clearer.

So, of the 3 signals (TERM, TERM, KILL) sent to gdm-simple-slave
within a total time of 0.01s, we have good explanations for the first
2.

The 3rd one (KILL) is still suspicious to me though. It is sent 0.4ms
after the preceding SIGTERM, here is what happens in the code:

1. gdm's main process exits due to the first SIGTERM. systemd becomes
aware in service_sigchld_event(), and responds as follows:

case SERVICE_STOP_SIGTERM:
case SERVICE_STOP_SIGKILL:
if (!control_pid_good(s))
service_enter_stop_post(s, f);

2. Inside service_enter_stop post, there is no command to execute, so we call:
service_enter_signal(s, SERVICE_FINAL_SIGTERM, SERVICE_SUCCESS);

3. service_enter_signal calls unit_kill_context() to send the second
SIGTERM. Looking at what happens inside unit_kill_context(): there is
no main process, nor control process, so we go straight to the cgroup
killing. The cgroup kill happens without error, and we reach the end
of the function:

return wait_for_exit;

wait_for_exit was not modified from its intial value (false) during
the course of the function, so false is returned here.

4. Back in service_enter_signal, since unit_kill_context returned
false, we do not arm the timer. Without hesitation systemd goes
directly and sends SIGKILL.

} else if (state == SERVICE_FINAL_SIGTERM)
service_enter_signal(s, SERVICE_FINAL_SIGKILL, SERVICE_SUCCESS)


I can understand that once the main PID goes away, systemd feels
welcome to get heavy handed with the remaining processes. But doing
SIGTERM and then immediately SIGKILL just a few microseconds later
seems strange - why not go straight for the SIGKILL?

There's a comment in unit_kill_context() which looks relevant here:

/* FIXME: For now, we will not wait for the
 * cgroup members to die, simply because
 * cgroup notification is unreliable. It
 * doesn't work at all in containers, and
 * outside of containers it can be confused
 * easily by leaving directories in the
 * cgroup. */

/* wait_for_exit = true; */

If that were uncommented, the above behaviour would be different.

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

Re: [systemd-devel] Setting up network interfaces for containers with --private-network

2015-04-21 Thread Spencer Baugh

Lennart Poettering lenn...@poettering.net writes:
 On Tue, 21.04.15 10:58, Spencer Baugh (sba...@catern.com) wrote:

  The MAC address is currently generated as hash value from the
  container name, it hence should be completely stable already as long
  as you keep using the same name for the container?
 
 Well, generally I want to know what MAC/IP address a machine/container
 will receive in advance of actually starting it. I could start it once
 and immediately stop it to see and record what MAC address is generated
 for a given name, or copy the code to generate the MAC address out of
 nspawn.c, but neither of those seem like good options.

 Sidenote: if this is about having stable names to refer to containers,
 note that nss-mycontainers adds those automatically. If enabled, then
 all local container names will be resolvable, automatically. It's
 often hence unnecessary to have fixed IP addresses for this at all.

It is about stable names, but I believe those names need to be usable
from off the host.

  I am interested in using networkd to do these things, but at the moment
  it doesn't seem to have the required level of power.
 
  what do you mean precisely with this?
 
 I mean that instead of writing another service (probably a shell script)
 to set up the interface on the host, using the PrivateNetwork= and
 JoinsNamespaceOf= trick, instead have networkd set up the interface on
 the host inside a network namespace and use the same kind of trick.

 Well, I mean how useful would this actually be? THis would only work
 for static configuration, everything more complex requires a daemon
 watching the interface continously and that's really hard to do for a
 set of network interfaces in a different network namespace.

All that I want to do is configuration that can be done at the time of
first creating the interface - like setting the MAC address. That is all
the script that I am using at the moment does, everything else is done
by networkd.

 Also, trivial static IP configuration is seldom sufficient, you at
 least need to also provide DNS configuration, and if you don't use
 DHCP or something similar then you need to configure that inside the
 container anyway. But if you do that you might as well configure the
 static IP addresses in it too, so what is gained by doing this from a
 networkd outside of the cotnainer?

 Or am I misunderstanding the role of networkd? It seems like if I am
 writing a service that represents the network interface and namespace
 for this container, I am doing something that networkd should
 ultimately do.

 Sure, absolutely. But our idea so far was that networkd should run
 inside the container to configure the container's network, and on the
 host to configure the host's network, but not to cross this boundary
 and have the host networkd configure the container's network.

Hmm, yes, but I think the problem is the configuration done at
interface-creation-time. It seems to me that that configuration
currently does not fit naturally in either the host networkd or the
container networkd.

 Set up the interface here just means create the interface with a
 specific MAC address, of course.

 Well, of course, we could beef up systemd-nspawn and allow it to take
 configurable IP or MAC addresses on the command line, and then it
 would become a second networkd, and we already have one of those...

Yes, but what else can configure the interfaces at creation time?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] networkd man: fix man and config name.

Rename bond confs and man as well.
---
 man/systemd.netdev.xml  |  28 
 src/network/networkd-netdev-gperf.gperf | 124 
 2 files changed, 76 insertions(+), 76 deletions(-)

diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index 3e65f2e..24e2d26 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -666,7 +666,7 @@
   /varlistentry
 
   varlistentry
-termvarnameLearnPacketIntvSec,=/varname/term
+termvarnameLearnPacketIntervalSec,=/varname/term
 listitem
   paraSpecifies the number of seconds between instances where the 
bonding
   driver sends learning packets to each slaves peer switch.
@@ -687,7 +687,7 @@
   /varlistentry
 
   varlistentry
-termvarnameFailOverMac=/varname/term
+termvarnameFailOverMACPolicy=/varname/term
 listitem
   paraSpecifies whether active-backup mode should set all slaves to
   the same MAC address at enslavement or, when enabled, perform 
special handling of the
@@ -701,10 +701,10 @@
   /varlistentry
 
   varlistentry
-termvarnameArpValidate=/varname/term
+termvarnameARPValidate=/varname/term
 listitem
   paraSpecifies whether or not ARP probes and replies should be
-  validated in any mode that supports arp monitoring, or whether
+  validated in any mode that supports ARP monitoring, or whether
   non-ARP traffic should be filtered (disregarded) for link
   monitoring purposes. Possible values are
   literalnone/literal,
@@ -716,7 +716,7 @@
   /varlistentry
 
   varlistentry
-termvarnameArpIntervalSec=/varname/term
+termvarnameARPIntervalSec=/varname/term
 listitem
   paraSpecifies the ARP link monitoring frequency in milliseconds.
   A value of 0 disables ARP monitoring. The default value is 0.
@@ -725,10 +725,10 @@
   /varlistentry
 
   varlistentry
-termvarnameArpIpTargets=/varname/term
+termvarnameARPIPTargets=/varname/term
 listitem
   paraSpecifies the IP addresses to use as ARP monitoring peers when
-  ArpIntervalSec is greater than 0. These are the targets of the ARP 
request
+  ARPIntervalSec is greater than 0. These are the targets of the ARP 
request
   sent to determine the health of the link to the targets.
   Specify these values in ipv4 dotted decimal format. At least one IP
   address must be given for ARP monitoring to function. The
@@ -739,12 +739,12 @@
   /varlistentry
 
   varlistentry
-termvarnameArpAllTargets=/varname/term
+termvarnameARPAllTargets=/varname/term
 listitem
-  paraSpecifies the quantity of ArpIpTargets that must be reachable
+  paraSpecifies the quantity of ARPIPTargets that must be reachable
   in order for the ARP monitor to consider a slave as being up.
   This option affects only active-backup mode for slaves with
-  ArpValidate enabled. Possible values are
+  ARPValidate enabled. Possible values are
   literalany/literal,
   literalall/literal
   /para
@@ -752,7 +752,7 @@
   /varlistentry
 
   varlistentry
-termvarnamePrimaryReselect=/varname/term
+termvarnamePrimaryReselectPolicy=/varname/term
 listitem
   paraSpecifies the reselection policy for the primary slave.  This
   affects how the primary slave is chosen to become the active slave
@@ -791,16 +791,16 @@
   /varlistentry
 
   varlistentry
-termvarnameNumGratuitousARP=/varname/term
+termvarnameGratuitousARP=/varname/term
 listitem
   paraSpecify the number of peer notifications (gratuitous ARPs and
 unsolicited IPv6 Neighbor Advertisements) to be issued after a
 failover event.  As soon as the link is up on the new slave
 a peer notification is sent on the  bonding device and each
 VLAN sub-device.  This is repeated at each link monitor interval
-(ArpIntervalSec or MIIMonitorSec, whichever is active) if the 
number is
+(ARPIntervalSec or MIIMonitorSec, whichever is active) if the 
number is
 greater than 1. The valid range is (0 - 255). Default value is 1.
-These options affect only the active-backup mode
+These options affect only the active-backup mode.
   /para
 /listitem
   /varlistentry
diff --git a/src/network/networkd-netdev-gperf.gperf 
b/src/network/networkd-netdev-gperf.gperf
index 72ab2f4..66ed2e0 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -18,65 +18,65 @@ struct ConfigPerfItem;
 %struct-type
 %includes
 %%
-Match.Host,   config_parse_net_condition, CONDITION_HOST,  
  offsetof(NetDev,

Re: [systemd-devel] networkd-218 seems to ignore .link files

2015-04-21 Thread Tom Gundersen

On Tue, Apr 14, 2015 at 7:08 PM, Andrew Cooks aco...@linux.com wrote:
 On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt jeng...@inai.de wrote:


 On Monday 2015-01-12 18:29, Tom Gundersen wrote:
  In systemd-218, I have configured the following testcase:
 
  /etc/systemd/network# ls -al
  total 20
  drwxr-xr-x 2 root root 4096 Jan 11 18:14 .
  drwxr-xr-x 5 root root 4096 Jan 11 16:23 ..
  -rw-r--r-- 1 root root   96 Jan 11 18:14 99a-ether.link
 
 Hm, isn't this just a problem of 99a-ether.link being ordered after
 99-default.link?

 Well, the manpage states: All link files are collectively
 sorted and processed in lexical order, with that, I would assume
 that 99a, being processed after 99, would override 99.

 It works for me when naming it 98-ether.link instead.

 Not in my case. I have a feeling networkd won't touch
 [08:00:27:0a:c5:b2]'s interface name because it has already
 been named by udev to enp0s3 before networkd got a chance to run.
 Could that be it?


 I'm having a similar problem while running systemd version-219. Did you work
 out what was wrong?

 My link file is ignored even when I symlink
 /etc/systemd/network/99-default.link to /dev/null. I don't see anything
 interesting in 'journalctl'.

 # udevadm info /sys/class/net/eth0
 P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0
 E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0
 E: ID_BUS=pci
 E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet
 Contror
 E: ID_MODEL_ID=0x8168
 E: ID_NET_DRIVER=r8169
 E: ID_NET_NAME_MAC=enx000db936008c
 E: ID_NET_NAME_PATH=enp1s0
 E: ID_OUI_FROM_DATABASE=PC Engines GmbH
 E: ID_PATH=pci-:01:00.0
 E: ID_PATH_TAG=pci-_01_00_0
 E: ID_PCI_CLASS_FROM_DATABASE=Network controller
 E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
 E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd.
 E: ID_VENDOR_ID=0x10ec
 E: IFINDEX=3
 E: INTERFACE=eth0
 E: SUBSYSTEM=net
 E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
 E: TAGS=:systemd:
 E: USEC_INITIALIZED=53326


 # networkctl status --no-pager eth0
 ��● 3: eth0
Link File: n/a
 Network File: n/a
 Type: ether
State: off (unmanaged)
 Path: pci-:01:00.0
   Driver: r8169
   Vendor: Realtek Semiconductor Co., Ltd.
Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH)
  MTU: 1500


 # cat /etc/systemd/network/01-mgmt.link
 [Match]
 Path=pci-:01:00.0
 Type=ether

Type must be the same as what is returned in DEVTYPE=, which I guess
is unset for this device. So drop this and it should work.

I see where the confusion stems from though, as we try to be helpful
and use a heuristic to print a Type in networkctl even when the kernel
does not expose a type. We probably should not do that, or allow the
same to be used in the .link matching logic (the heuristic is unlikely
to be perfect, so I hesitate a bit with the latter).

Cheers,

Tom

 [Link]
 Name=mgmt
 MACAddressPolicy=persistent

 ___
 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 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers

Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429373517-3749-4-git-send-email-mjg59%40srcf.ucam.org

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] udev: Fix ping timeout when settle timeout is 0

Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429400987-7868-1-git-send-email-nsoffer%40redhat.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] networkd man: fix man and config name.

Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429603445-3886-1-git-send-email-susant%40redhat.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journal: Introduce journal-netlogd

Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429520631-30735-1-git-send-email-susant%40redhat.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] networkd: introduce vti6 tunnel

This patch add support to create vti6 tunnel

test:

vt6.network
[Match]
Name=wlan0

[Network]
Tunnel=ip6vti

vti6.netdev
[NetDev]
Name=ip6vti
Kind=vti6

[Tunnel]
Local=2a00:ffde:4567:edde::4987
Remote=2001:473:fece:cafe::5179

ip link

11: ip6_vti0@NONE: NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT
group default
link/tunnel6 :: brd ::
12: ip6vti@wlan0: POINTOPOINT,NOARP mtu 1500 qdisc noop state DOWN
mode DEFAULT group default
link/tunnel6 2a00:ffde:4567:edde::4987 peer 2001:473:fece:cafe::5179
---
 man/systemd.netdev.xml   |  6 +++-
 src/libsystemd/sd-rtnl/rtnl-types.c  |  3 ++
 src/libsystemd/sd-rtnl/rtnl-types.h  |  1 +
 src/network/networkd-netdev-tunnel.c | 57 +++-
 src/network/networkd-netdev-tunnel.h |  1 +
 src/network/networkd-netdev.c|  2 ++
 src/network/networkd-netdev.h|  2 ++
 src/network/networkd-network.c   |  1 +
 8 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index 3e65f2e..b86dd43 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -155,6 +155,9 @@
   rowentryvarnamevti/varname/entry
   entryAn IPv4 over IPSec tunnel./entry/row
 
+  rowentryvarnamevti6/varname/entry
+  entryAn IPv6 over IPSec tunnel./entry/row
+
   rowentryvarnamevxlan/varname/entry
   entryA virtual extensible LAN (vxlan), for connecting Cloud 
computing deployments./entry/row
 /tbody
@@ -441,7 +444,8 @@
 literalgretap/literal,
 literalip6gre/literal,
 literalip6gretap/literal,
-literalvti/literal, and
+literalvti/literal,
+literalvti6/literal, and
 literalip6tnl/literal and accepts
 the following keys:/para
 
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c 
b/src/libsystemd/sd-rtnl/rtnl-types.c
index a5c9fdf..d211684 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -204,6 +204,7 @@ static const char* const 
nl_union_link_info_data_table[_NL_UNION_LINK_INFO_DATA_
 [NL_UNION_LINK_INFO_DATA_IP6GRETAP_TUNNEL] = ip6gretap,
 [NL_UNION_LINK_INFO_DATA_SIT_TUNNEL] = sit,
 [NL_UNION_LINK_INFO_DATA_VTI_TUNNEL] = vti,
+[NL_UNION_LINK_INFO_DATA_VTI6_TUNNEL] = vti6,
 [NL_UNION_LINK_INFO_DATA_IP6TNL_TUNNEL] = ip6tnl,
 };
 
@@ -238,6 +239,8 @@ static const NLTypeSystem 
rtnl_link_info_data_type_systems[_NL_UNION_LINK_INFO_D
   .types = 
rtnl_link_info_data_iptun_types },
 [NL_UNION_LINK_INFO_DATA_VTI_TUNNEL] =  { .max = 
ELEMENTSOF(rtnl_link_info_data_ipvti_types) - 1,
   .types = 
rtnl_link_info_data_ipvti_types },
+[NL_UNION_LINK_INFO_DATA_VTI6_TUNNEL] =  { .max = 
ELEMENTSOF(rtnl_link_info_data_ipvti_types) - 1,
+  .types = 
rtnl_link_info_data_ipvti_types },
 [NL_UNION_LINK_INFO_DATA_IP6TNL_TUNNEL] =  { .max = 
ELEMENTSOF(rtnl_link_info_data_ip6tnl_types) - 1,
  .types = 
rtnl_link_info_data_ip6tnl_types },
 
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.h 
b/src/libsystemd/sd-rtnl/rtnl-types.h
index 72773ea..de1544b 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.h
+++ b/src/libsystemd/sd-rtnl/rtnl-types.h
@@ -87,6 +87,7 @@ typedef enum NLUnionLinkInfoData {
 NL_UNION_LINK_INFO_DATA_IP6GRETAP_TUNNEL,
 NL_UNION_LINK_INFO_DATA_SIT_TUNNEL,
 NL_UNION_LINK_INFO_DATA_VTI_TUNNEL,
+NL_UNION_LINK_INFO_DATA_VTI6_TUNNEL,
 NL_UNION_LINK_INFO_DATA_IP6TNL_TUNNEL,
 _NL_UNION_LINK_INFO_DATA_MAX,
 _NL_UNION_LINK_INFO_DATA_INVALID = -1
diff --git a/src/network/networkd-netdev-tunnel.c 
b/src/network/networkd-netdev-tunnel.c
index 89ad3ee..6ffef1f 100644
--- a/src/network/networkd-netdev-tunnel.c
+++ b/src/network/networkd-netdev-tunnel.c
@@ -304,6 +304,43 @@ static int netdev_vti_fill_message_create(NetDev *netdev, 
Link *link, sd_rtnl_me
 return r;
 }
 
+static int netdev_vti6_fill_message_create(NetDev *netdev, Link *link, 
sd_rtnl_message *m) {
+Tunnel *t = VTI6(netdev);
+int r;
+
+assert(netdev);
+assert(link);
+assert(m);
+assert(t);
+assert(t-family == AF_INET6);
+
+r = sd_rtnl_message_append_u32(m, IFLA_VTI_LINK, link-ifindex);
+if (r  0) {
+log_netdev_error(netdev,
+ Could not append IFLA_IPTUN_LINK attribute: 
%s,
+ strerror(-r));
+return r;
+}
+
+r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_LOCAL, t-local.in6);
+if (r  0) {
+log_netdev_error(netdev,
+ Could not append IFLA_IPTUN_LOCAL attribute: 
%s,
+ strerror(-r));
+return r;
+}
+
+

Re: [systemd-devel] [systemd-commits] man/systemd.netdev.xml src/libsystemd src/network


I will fix these . thanks for review.

On 04/21/2015 05:00 AM, Lennart Poettering wrote:

On Mon, 20.04.15 15:27, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:



+  varlistentry
+termvarnameLearnPacketIntvSec,=/varname/term
+listitem
+  paraSpecifies the number of seconds between instances where the 
bonding
+  driver sends learning packets to each slaves peer switch.
+  The valid range is 1 - 0x7fff; the default value is 1. This 
Option
+  has effect only in balance-tlb and balance-alb modes./para
+/listitem
+  /varlistentry



We usually don't abbreviate options unnecessarily. Please use
Interval instead of Intv.


+  varlistentry
+termvarnameFailOverMac=/varname/term
+listitem
+  paraSpecifies whether active-backup mode should set all slaves to
+  the same MAC address at enslavement or, when enabled, perform 
special handling of the
+  bond's MAC address in accordance with the selected policy. The 
default policy is none.
+  Possible values are
+  literalnone/literal,
+  literalactive/literal,
+  literalfollow/literal
+  /para
+/listitem
+  /varlistentry


The option MACAddress= is currently spelt with an uppercase MAC. In
fact most options containing acronyms use uppercase naming. hence
FailOverMAC=.

That said, shouldn't this be FailOverMACMode= or FailOverMACPolicy= or so?


+
+  varlistentry
+termvarnameArpValidate=/varname/term
+listitem
+  paraSpecifies whether or not ARP probes and replies should be
+  validated in any mode that supports arp monitoring, or whether
+  non-ARP traffic should be filtered (disregarded) for link
+  monitoring purposes. Possible values are
+  literalnone/literal,
+  literalactive/literal,
+  literalbackup/literal,
+  literalall/literal
+  /para
+/listitem
+  /varlistentry


Uppercase ARP please, see above. ARPValidate=


+  varlistentry
+termvarnameArpIntervalSec=/varname/term
+listitem
+  paraSpecifies the ARP link monitoring frequency in milliseconds.
+  A value of 0 disables ARP monitoring. The default value is 0.
+  /para
+/listitem
+  /varlistentry


Good that Interval is spelt out this time. But s/Arp/ARP/ please.


+  varlistentry
+termvarnameArpIpTargets=/varname/term
+listitem
+  paraSpecifies the IP addresses to use as ARP monitoring peers when
+  ArpIntervalSec is greater than 0. These are the targets of the ARP 
request
+  sent to determine the health of the link to the targets.
+  Specify these values in ipv4 dotted decimal format. At least one IP
+  address must be given for ARP monitoring to function. The
+  maximum number of targets that can be specified is 16. The
+  default value is no IP addresses.
+  /para
+/listitem
+  /varlistentry


s/Arp/ARP/

s/Ip/IP/

Maybe append Address?


+
+  varlistentry
+termvarnameArpAllTargets=/varname/term
+listitem
+  paraSpecifies the quantity of ArpIpTargets that must be reachable
+  in order for the ARP monitor to consider a slave as being up.
+  This option affects only active-backup mode for slaves with
+  ArpValidate enabled. Possible values are
+  literalany/literal,
+  literalall/literal
+  /para
+/listitem
+  /varlistentry


similar...


+
+  varlistentry
+termvarnamePrimaryReselect=/varname/term
+listitem
+  paraSpecifies the reselection policy for the primary slave.  This
+  affects how the primary slave is chosen to become the active slave
+  when failure of the active slave or recovery of the primary slave
+  occurs. This option is designed to prevent flip-flopping between
+  the primary slave and other slaves.  Possible values are
+  literalalways/literal,
+  literalbetter/literal,
+  literalfailure/literal
+  /para
+/listitem
+  /varlistentry


PrimaryReselectPolicy= or so?


+
+  varlistentry
+termvarnameResendIGMP=/varname/term
+listitem
+  paraSpecifies the number of IGMP membership reports to be issued 
after
+  a failover event. One membership report is issued immediately after
+  the failover, subsequent packets are sent in each 200ms interval.
+  The valid range is (0 - 255). Defaults to 1. A value of 0
+  prevents the IGMP membership report from being issued in response
+  to the failover event.
+  /para
+/listitem
+  /varlistentry


I like the that the IGMP name is upper case!


+  varlistentry
+termvarnameNumGratuitousARP=/varname/term
+listitem
+  paraSpecify the

Re: [systemd-devel] [PATCH] networkd: introduce vti6 tunnel

Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429609568-17264-1-git-send-email-susant%40redhat.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=

2015-04-21 Thread Umut Tezduyar Lindskog

My two cents is feature can be implemented as long as we get support
from the application. For example sd-event has the builtin support to
quit when it is idle. Systemd can pass the exit-on-idle timeout to the
application via env variables so the event loop can configure itself
to quit.

I am not sure if glib event loop has this functionality already but I
would be very interested to have it. I am just waiting for kdbus.
Exiting on non-kdbus is still racy if we don't let systemd know
upfront.

Umut

On Mon, Apr 20, 2015 at 5:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote:

 If a service does not consume CPU during some time(can be configured
 by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the
 service will be stopped. This can be useful if the service provides
 some of activation methods.

 Hmm, I am not convinced this would be a good idea, sorry.

 The crux of the issue is that it is really hard to detect from the
 outside if a daemon is really idle. Only the daemon itself knows
 whether it is truly idle or not. I mean, it could just be waiting for
 some timer to elapse, or some other external event.

 I doubt this is really useful unless you have really really simple
 daemons that purely react on client requests and nothing else, and you
 know the codebase and that it is OK to terminate the daemon just
 because its CPU usage is zero. But if you know the codebase that well
 it would probably be a better idea to just add support for
 exit-on-idle directly to the daemon in question.

 exit-on-idle is really something that should be implemented *in* the
 daemon, and not done externally!

 Sorry,

 Lennart

 --
 Lennart Poettering, Red Hat
 ___
 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] Setting up network interfaces for containers with --private-network

2015-04-21 Thread Spencer Baugh

Lennart Poettering lenn...@poettering.net writes:

 On Mon, 20.04.15 22:50, Spencer Baugh (sba...@catern.com) wrote:
 Yes, in that case, it is of course very simple, but it is not at all
 configurable. I have one thing and one thing only that I want to
 configure: The IP address that a given container receives. This seems
 like a reasonable thing to want to configure; ultimately there have to
 be fixed IP addresses somewhere, and I have a use for containers that
 would benefit from having fixed IP addresses.
 
 The way I currently fix the IP address that the container receives is by
 fixing the MAC address of the veth; since I am using IPv6 and radvd, the
 IP address is deterministically generated from the MAC address. So it
 would be helpful if there was a way to do fix the MAC address in
 nspawn. Would you accept a patch to add an option to nspawn to specify a
 MAC address for the veth? Or is there a better way to go about this?

 The MAC address is currently generated as hash value from the
 container name, it hence should be completely stable already as long
 as you keep using the same name for the container?

Well, generally I want to know what MAC/IP address a machine/container
will receive in advance of actually starting it. I could start it once
and immediately stop it to see and record what MAC address is generated
for a given name, or copy the code to generate the MAC address out of
nspawn.c, but neither of those seem like good options.

 maybe the ipvlan stuff could work for you?

It's possible, but then I'd be back to the situation where I need to
write a script to keep bringing up the ipvlan devices before starting
the container. Unless ipvlan devices don't disappear when the namespace
disappears?

  Another option could be to use write a service that sets up the
  interface, uses PrivateNetwork= and then use JoinsNamespaceOf= on the
  container service towards that service, and turn off nspawn's own
  private networking switch. That way PID1 would already set up the
  joint namespace for your container, and ensure it is set up properly
  by your setup service. And as long as either the setup service or the
  container is running the network namespace will stay referenced.
 
 Hmm, that is an interesting approach... it would be nice to be able to
 have networkd be setting up the interface here, though.

 Well, it can, but only if you run it inside of the container. I am
 pretty sure the networkd of the host should not configure the
 interfaces inside of it...

 I am interested in using networkd to do these things, but at the moment
 it doesn't seem to have the required level of power.

 what do you mean precisely with this?

I mean that instead of writing another service (probably a shell script)
to set up the interface on the host, using the PrivateNetwork= and
JoinsNamespaceOf= trick, instead have networkd set up the interface on
the host inside a network namespace and use the same kind of trick.

Or am I misunderstanding the role of networkd? It seems like if I am
writing a service that represents the network interface and namespace
for this container, I am doing something that networkd should
ultimately do.

Set up the interface here just means create the interface with a
specific MAC address, of course.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it

2015-04-21 Thread Alban Crequy

On Sat, Feb 28, 2015 at 5:40 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 27.02.15 17:13, Lennart Poettering (lenn...@poettering.net) wrote:

 On Thu, 26.02.15 16:50, Martin Pitt (martin.p...@ubuntu.com) wrote:

  IMHO it would be prudent to skip adding the BindsTo= if at the time of
  creating the .mount unit the backing .device unit doesn't actually
  exist. In that case it's a mount which isn't managed by systemd, and
  we shouldn't touch it. We mostly want this BindsTo= for mounts where
  the .device units *do* exist, so that when they go away we can clean
  up the mount (mostly for hotpluggable devices and removable media).
  I'll have a deeper look ASAP.

 I ran into this myself the other day, and Kay, Daniel and I spent a
 lot of time to come up with a scheme how to deal with the race... And
 I think we have a nice scheme now and I started implementing it.

 The idea is that .device units will gain a third state: currently they
 are either dead or plugged, and the new state will be
 tentative. It is entered when a device is referenced in
 /proc/self/mountinfo or /proc/swap, even though it has not yet shown
 up via udev.

 This new state has will not result in BindsTo= getting active.

 This is implemented now. Please check if this fixes this issue for
 you.

Which commit implements this?

I have an issue on nspawn container shutdown with v219 that I didn't
have with v215. Systemd is trying to unmount the volumes bind mounted
by nspawn and it fails because /bin/umount does not exist in my
container. Systemd keeps trying to umount it in a busy loop. Reverting
06e9783e2cc12eb6514e80c7f0014295f59b (core/mount: add
dependencies to dynamically mounted mounts too) fixes my issue.

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

[systemd-devel] [PATCH v2 1/2] Don't use ALSA card id in ID_ID

2015-04-21 Thread Adam Goode

The ALSA id sysattr is generated by the sound subsystem and is not
a stable identifier. It is generated though some string manipulation
then made unique if there is a conflict. This means that it is
enumeration-dependent and shouldn't be used for ID_ID.

If ID_ID is supposed to be system-unique, it is not already since
for firewire it is generated from the guid and there are broken
firewire devices that have duplicate guids across devices.

This is tracked for PulseAudio at
https://bugs.freedesktop.org/show_bug.cgi?id=90129.
---
 rules/78-sound-card.rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
index 295f490..bd7a994 100644
--- a/rules/78-sound-card.rules
+++ b/rules/78-sound-card.rules
@@ -49,8 +49,8 @@ SUBSYSTEMS==firewire, GOTO=skip_pci
 SUBSYSTEMS==pci, ENV{ID_BUS}=pci, ENV{ID_VENDOR_ID}=$attr{vendor}, 
ENV{ID_MODEL_ID}=$attr{device}
 LABEL=skip_pci
 
-ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*, 
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}-$attr{id}
-ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==, 
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$attr{id}
+ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*, 
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}
+ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==, 
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}
 
 IMPORT{builtin}=path_id
 
-- 
2.2.0.rc0.207.ga3a616c

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

[systemd-devel] [PATCH v2 2/2] Add more firewire properties for sound, to be closer to USB and PCI

2015-04-21 Thread Adam Goode

USB and PCI soundcards have a nice set of ID_* properties. It would
be handy for firewire soundcards to have the same.
---
 rules/78-sound-card.rules | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
index bd7a994..04740e8 100644
--- a/rules/78-sound-card.rules
+++ b/rules/78-sound-card.rules
@@ -41,14 +41,17 @@ IMPORT{builtin}=hwdb
 SUBSYSTEMS==usb, IMPORT{builtin}=usb_id
 SUBSYSTEMS==usb, GOTO=skip_pci
 
-SUBSYSTEMS==firewire, ATTRS{vendor_name}==?*, ATTRS{model_name}==?*, \
-  ENV{ID_BUS}=firewire, ENV{ID_VENDOR}=$attr{vendor_name}, 
ENV{ID_MODEL}=$attr{model_name}
-SUBSYSTEMS==firewire, ATTRS{guid}==?*, ENV{ID_ID}=firewire-$attr{guid}
+SUBSYSTEMS==firewire, ATTRS{guid}==?*, \
+  ENV{ID_BUS}=firewire, ENV{ID_SERIAL}=$attr{guid}, 
ENV{ID_SERIAL_SHORT}=$attr{guid}, \
+  ENV{ID_VENDOR_ID}=$attr{vendor}, ENV{ID_MODEL_ID}=$attr{model}, \
+  ENV{ID_VENDOR}=$attr{vendor_name}, ENV{ID_MODEL}=$attr{model_name}
 SUBSYSTEMS==firewire, GOTO=skip_pci
 
 SUBSYSTEMS==pci, ENV{ID_BUS}=pci, ENV{ID_VENDOR_ID}=$attr{vendor}, 
ENV{ID_MODEL_ID}=$attr{device}
 LABEL=skip_pci
 
+# Define ID_ID if ID_BUS and ID_SERIAL are set. This will work for both
+# USB and firewire.
 ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*, 
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}
 ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==, 
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}
 
-- 
2.2.0.rc0.207.ga3a616c

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

Re: [systemd-devel] [PATCH v2 2/2] Add more firewire properties for sound, to be closer to USB and PCI

Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429652737-7322-2-git-send-email-agoode%40google.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-nspawn trouble

2015-04-21 Thread Tobias Hunger

Hi!

Now that systemd 219 is finally available in arch I am playing with
systemd-nspawn again.

I was trying to run systemd-nspawn --ephemeral, but that failed
since I had a read-only image in /var/lib/machines. Why is that not
allowed? systemd-nspawn does create its own snapshot of that one after
all (which can be read-write). Why does the base image have to be
read-write, too?

Then I have trouble with systemd-nspawn --network-veth: The host0
interface won't come up and stays in degraded state. On the host i get
the following line in the journal:

systemd-networkd[509]: ve-XXX : Could not enable IP masquerading:
Protocol not available

I have an nftables based firewall up and running, so maybe networkd is
expecting iptables to be in use?

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

Re: [systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs

2015-04-21 Thread Nick Owens

hello tom,

On Mon, Apr 20, 2015 at 2:32 PM, Tom Gundersen t...@jklm.no wrote:
On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau
michael.marin...@coreos.com wrote:
On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens misch...@offblast.org wrote:
hi, sorry for the delay.

from
http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html:

By default, it will wait for all links it is aware of and which are
managed by systemd-networkd.service(8) to be fully configured or
failed, *and for at least one link to gain a carrier.*.

the import part here is the end of the sentence. without this patch,
systemd-networkd-wait-online will block until all configured
interfaces have carrier.. you can reproduce this by running
systemd-networkd in qemu with two ethernet interfaces, and issue 'info
network' and then 'set_link if down' to simulate no carrier. then
you can run systemd-networkd-wait-online, and observe that it will
block until both interfaces are up, not just one.

nick

On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov arvidj...@gmail.com
wrote:
On Wed, Mar 25, 2015 at 11:49 PM, misch...@offblast.org wrote:
From: mischief misch...@offblast.org

when checking interface status, systemd-networkd-wait-online
will continue to wait if any interface is still configuring or
being processed by udev. this patch allows it to return if any
one interface is degraded/routable, as per the manual.

But current behavior is exactly what manual says: By default, it will
wait for all links it is aware of and which are managed by
systemd-networkd.service(8) to be fully configured or failed. Or do I
miss something?

It is worth noting that there may be some issues with tracking
interface states in networkd, there appear to be ways to get an
interface stuck in a 'configuring' state despite the fact that the
interface has no network config and/or has no carrier.

Do you have any more info on this? Can you reproduce with current git?
There was a fix after the last release which should fix a problem with
enumerating devices.

the original issue was discussed at
https://github.com/coreos/bugs/issues/279. i just tested commit
cffacc741cb79f63999720525ceaa65aae01a542.

https://github.com/coreos/init/blob/master/systemd/network/zz-default.network
is our default for networkd. it seems logical that given this config,
systemd-networkd-wait-online would wait for all of the dhcp
interfaces, no matter how many.

however, i'm not sure what use case there is for this. it seems like
there's no way to wait for any one nic to be routeable/configured
without knowing its name ahead of time.

another instance of this problem is having a bridge like

[NetDev]
Name=br0
Kind=bridge

and run 'systemctl restart systemd-networkd;
/usr/bin/systemd-networkd-wait-online'. systemd-networkd-wait-online
will not return. is this intended behavior?

Cheers,

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

Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=

2015-04-21 Thread David Timothy Strauss

On Tue, Apr 21, 2015 at 12:26 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 So I see no use case for idle timer based cleanup. Can you please
 explain why they are better than on-demand cleanup?

We do it on Pantheon's infrastructure because many daemons have a
resource footprint that is more than just allocated memory, like
waking themselves up for cache cleanup or inefficient polling on
sockets. We shut down socket-activated applications after an hour of
idle time, and it dramatically frees up server resources for active
daemons.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/3] journal: add int↔audit type name mapping

2015-04-21 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Apr 20, 2015 at 04:39:41PM +0200, Lennart Poettering wrote:
 On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
   
  +src/journal/audit_type-list.txt:
  +   $(AM_V_at)$(MKDIR_P) $(dir $@)
  +   $(AM_V_GEN)$(CPP) $(CFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) -dM -include 
  linux/audit.h - /dev/null | grep -vE 'AUDIT_(FIRST|LAST)_.*MSG' | $(SED) 
  -r -n 's/^#define\s+AUDIT_(\w+)\s+([0-9]{4})\s*$$/\1\t\2/p' | sort -k2 $@
 
 We add some more in missing.h, so this should probably be added, too, here?
Added.
 
  +#include audit-type.h
  +
  +static const struct audit_type_name *
  +lookup_audit_type(register const char *str, register unsigned int
  len);
 
 Weird line break...
I think your mail client must have wrapped it. It is one line here.

  +const char *audit_type_to_string(int type);
 
 is this one actually implemented?
It is generated in Makefile.am.

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

Re: [systemd-devel] mounting loop

2015-04-21 Thread Christian Hesse

Christian Hesse l...@eworm.de on Mon, 2015/04/20 09:25:
 Hello everybody,
 
 with systemd 219 mounting a filesystem image in loopback mode fails. Using
 these command:
 
 # truncate -s 1G /tmp/test.img
 # mkfs.ext4 /tmp/test.img
 [...]
 # mount -o loop /tmp/test.img /mnt/tmp
 
 systemd umounts the image as it thinks it is inactive:
 
 Apr 20 08:54:28 leda systemd[1]: Unit mnt-tmp.mount is bound to inactive
 unit. Stopping, too.
 Apr 20 08:54:28 leda systemd[1]: Unmounting /mnt/tmp...
 Apr 20 08:54:28 leda systemd[1]: Unmounted /mnt/tmp.
 
 However manually assigning a loop device and mounting that works just fine:
 
 # losetup -f /tmp/test.img
 # losetup -a
 /dev/loop0: [0034]:695793 (/tmp/test.img)
 # mount /dev/loop0 /mnt/tmp
 
 I think this is not the intended behavior, no? Any chance to fix that?

Looks like the issue is fixed with this upstream commit:

From 628c89cc68ab96fce2de7ebba5933725d147aecc Mon Sep 17 00:00:00 2001
From: Lennart Poettering lenn...@poettering.net
Date: Fri, 27 Feb 2015 21:55:08 +0100
Subject: core: rework device state logic

-- 
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c  ./sig*/b/42*2-3)*42);}


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

[systemd-devel] journald problems

2015-04-21 Thread Michał Zegan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I have just removed my journal files and restarted journald. I then
generated sealing keys, saved the verification key. The system worked
for maybe an hour or less, I had to power it off, then it was
restarted. I tried to verify the journal.
This is what happened:

PASS: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/system.journal


 390398: tag failed verification


 File corruption detected at
/var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1000.journal:3903
98
(of 8388608 bytes, 44%).
 FAIL:
/var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1000.journal
(Bad message)

 3987a0: tag failed verification


 File corruption detected at
/var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1002.journal:3987
a0
(of 8388608 bytes, 44%).
 FAIL:
/var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1002.journal
(Bad message)

 3903a0: tag failed verification


 File corruption detected at
/var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1001.journal:3903
a0
(of 8388608 bytes, 44%).
 FAIL:
/var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1001.journal
(Bad message)

What is happening here? It always happens after sealing, no matter
what I am doing, all new journal files are corrupted and show this
message.

Systemd version 219, system is archlinux, kernel 3.19.3-3-ARCH, and
filesystem is btrfs if at all important.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVNs77AAoJEHb1CzgxXKwYldcP/jGnuCyN1hcQvUHgc4ZS+CkW
gCEf59TteLYO/7yVQnrAs4gHFJ6WJlFw8+2L1Lt9gpts2h41oQxyPjhfa6578kSB
2ZC+9McpjLqMctn+hBt3GcPyi/vpr7QAm29sBoPpbCl8hCQQeRbGg5dfUnV0q7ot
ueXiO2VMW2wYDz3/0gmqCf7Fh+ChWdBTNAZFrTMqP1hLw0xTukazpNFGm8sStgcp
TC2p3JlLmmdCXHxPTGnxFj4jVWuYIOzDajh5GZUPlhmlBy48TKSzF+T3ri6zkOr5
+lyDC1fho5P7shdSN07OlGLSeg6JXC193gBB8WEhUwTs29fZzjyChke0dHVq/WSj
2pYpSr5cncxiUnwR5HTAhBRKHctKP8/5Rqmgu9GCEpy52mtuDsHUQQVbckjMaOYj
9Bz1y+pLNVi5v9AeD3wv/TnxEKeIYd4lwfs9pSutrF/KDo3XxPzys+jgbQvDrxVn
zbiKW9X8gc0r6P9qQ5p1jcBndW3dstQExNqGSZCgrCckymDxiSzfhjKQe8G/rD/O
29By4j9vbhHRq/gVpo0MWdnn8I1PCAxpqrftxCLmkEUNCgNAn+xIzwe+G6ppmAv7
4ZnbYfvLAz4Fj0g4QmswCXZB+DEqowrHK5N89BWxRSiY19A87l7BeFDzIFytOfkC
LHhedmjVTZXNvgTZXyeE
=VsvH
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] automount: add expire support

2015-04-21 Thread Kay Sievers

On Tue, Apr 21, 2015 at 8:45 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 14.04.15 22:01, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

 I added some more logging (so that automount_dispatch_expire() can
 never fail without this being logged) and applied it!

 I only gave this superficial testing though, please check if this all
 still works fine for you now!

I added 120 seconds for the EFI FAT /boot mount:
  
http://cgit.freedesktop.org/systemd/systemd/commit/?id=163ab2961268232e1cb49e990a8ccefe24b7649f

  $ journalctl -b -u boot.mount
  Apr 22 00:49:22 ank systemd[1]: Mounting EFI System Partition...
  Apr 22 00:49:22 ank systemd[1]: Mounted EFI System Partition.
  Apr 22 00:51:24 ank systemd[1]: Unmounting EFI System Partition...
  Apr 22 00:51:24 ank systemd[1]: Unmounted EFI System Partition.
  Apr 22 00:51:48 ank systemd[1]: Mounting EFI System Partition...
  Apr 22 00:51:48 ank systemd[1]: Mounted EFI System Partition.
  Apr 22 00:53:51 ank systemd[1]: Unmounting EFI System Partition...
  Apr 22 00:53:51 ank systemd[1]: Unmounted EFI System Partition.

Michael, thanks a lot for adding that feature.

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

Re: [systemd-devel] networkd-218 seems to ignore .link files

On Tue, 21.04.15 11:42, Andrew Cooks (aco...@linux.com) wrote:

   # cat /etc/systemd/network/01-mgmt.link
   [Match]
   Path=pci-:01:00.0
   Type=ether
  
   [Link]
   Name=mgmt
   MACAddressPolicy=persistent
 
  Consider testing the .link file with udevadm test-builtin
  net_setup_link...
 
 Thanks, this is exactly what I needed to find the problem.
 
 There were two issues with my .link file:
 I needed to call my local override 100-mgmt.link instead of 01-mgmt.link.
 IMHO, the ordering of the .link files is somewhat unfortunate, even though
 the documentation did try to explain it.
 
 Secondly, the Path in the [Match] section was wrong. The examples use
 pci-:xx:yy.0-* and 'udevadm info /sys/class/net/enp1s0' shows
 'ID_PATH=pci-:01:00.0' (exactly what I used, as the man page
 instructs), but it only started working when I tried
 'Path=*:01:00.0*'.

Hmm, that's really weird. This should work without the *, too.

Are really *both* the trailing and starting * necessary?

Could you please file a bug about this in fdo bz? This is something to
fix, and we shouldn't forget about it.

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] networkd man: fix man and config name.

2015-04-21 Thread Tom Gundersen

On Tue, Apr 21, 2015 at 1:16 PM, Susant Sahani sus...@redhat.com wrote:


 On 04/21/2015 04:33 PM, Lennart Poettering wrote:

 On Tue, 21.04.15 13:34, Susant Sahani (sus...@redhat.com) wrote:

 Rename bond confs and man as well.
 ---
   man/systemd.netdev.xml  |  28 
   src/network/networkd-netdev-gperf.gperf | 124
 
   2 files changed, 76 insertions(+), 76 deletions(-)

 diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
 index 3e65f2e..24e2d26 100644
 --- a/man/systemd.netdev.xml
 +++ b/man/systemd.netdev.xml
 @@ -666,7 +666,7 @@
 /varlistentry

 varlistentry
 -termvarnameLearnPacketIntvSec,=/varname/term
 +termvarnameLearnPacketIntervalSec,=/varname/term


 Hmm, why is there a trailing comma here?


 oops ... I guess Tom fixed it while committing . Thanks !

Yup, I noticed. So fixed and pushed.

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

Re: [systemd-devel] Setting up network interfaces for containers with --private-network

On Mon, 20.04.15 22:50, Spencer Baugh (sba...@catern.com) wrote:

 Lennart Poettering lenn...@poettering.net writes:
  On Mon, 20.04.15 15:25, Spencer Baugh (sba...@catern.com) wrote:
  So far I'd recommend running networkd on the host and in the
  container. If you run it on the host, then it will automatically
  configure the hos side of each of nspawn's veth links with a new IP
  range, and be a DHCP server on it, as well as do IP
  masquerading. Connectivity will hence just work, if you use networkd
  in most cases.
 
 This is in the case where I use --network-bridge, right? Because
 otherwise there is no veth to be automatically configured.

No, not with --network-bridge, but with --network-veth, i.e. -n or
what systemd-nspawn@.service uses by default.

 Yes, in that case, it is of course very simple, but it is not at all
 configurable. I have one thing and one thing only that I want to
 configure: The IP address that a given container receives. This seems
 like a reasonable thing to want to configure; ultimately there have to
 be fixed IP addresses somewhere, and I have a use for containers that
 would benefit from having fixed IP addresses.
 
 The way I currently fix the IP address that the container receives is by
 fixing the MAC address of the veth; since I am using IPv6 and radvd, the
 IP address is deterministically generated from the MAC address. So it
 would be helpful if there was a way to do fix the MAC address in
 nspawn. Would you accept a patch to add an option to nspawn to specify a
 MAC address for the veth? Or is there a better way to go about this?

The MAC address is currently generated as hash value from the
container name, it hence should be completely stable already as long
as you keep using the same name for the container?

maybe the ipvlan stuff could work for you?

  Another option could be to use write a service that sets up the
  interface, uses PrivateNetwork= and then use JoinsNamespaceOf= on the
  container service towards that service, and turn off nspawn's own
  private networking switch. That way PID1 would already set up the
  joint namespace for your container, and ensure it is set up properly
  by your setup service. And as long as either the setup service or the
  container is running the network namespace will stay referenced.
 
 Hmm, that is an interesting approach... it would be nice to be able to
 have networkd be setting up the interface here, though.

Well, it can, but only if you run it inside of the container. I am
pretty sure the networkd of the host should not configure the
interfaces inside of it...

 I am interested in using networkd to do these things, but at the moment
 it doesn't seem to have the required level of power.

what do you mean precisely with 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] networkd man: fix man and config name.

On Tue, 21.04.15 13:34, Susant Sahani (sus...@redhat.com) wrote:

 Rename bond confs and man as well.
 ---
  man/systemd.netdev.xml  |  28 
  src/network/networkd-netdev-gperf.gperf | 124 
 
  2 files changed, 76 insertions(+), 76 deletions(-)
 
 diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
 index 3e65f2e..24e2d26 100644
 --- a/man/systemd.netdev.xml
 +++ b/man/systemd.netdev.xml
 @@ -666,7 +666,7 @@
/varlistentry
  
varlistentry
 -termvarnameLearnPacketIntvSec,=/varname/term
 +termvarnameLearnPacketIntervalSec,=/varname/term

Hmm, why is there a trailing comma here?

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] networkd man: fix man and config name.




On 04/21/2015 04:33 PM, Lennart Poettering wrote:

On Tue, 21.04.15 13:34, Susant Sahani (sus...@redhat.com) wrote:


Rename bond confs and man as well.
---
  man/systemd.netdev.xml  |  28 
  src/network/networkd-netdev-gperf.gperf | 124 
  2 files changed, 76 insertions(+), 76 deletions(-)

diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index 3e65f2e..24e2d26 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -666,7 +666,7 @@
/varlistentry

varlistentry
-termvarnameLearnPacketIntvSec,=/varname/term
+termvarnameLearnPacketIntervalSec,=/varname/term


Hmm, why is there a trailing comma here?


oops ... I guess Tom fixed it while committing . Thanks !



Lennart



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

Re: [systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it

2015-04-21 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Apr 21, 2015 at 03:54:35PM +0200, Alban Crequy wrote:
 On Sat, Feb 28, 2015 at 5:40 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Fri, 27.02.15 17:13, Lennart Poettering (lenn...@poettering.net) wrote:
 
  On Thu, 26.02.15 16:50, Martin Pitt (martin.p...@ubuntu.com) wrote:
 
   IMHO it would be prudent to skip adding the BindsTo= if at the time of
   creating the .mount unit the backing .device unit doesn't actually
   exist. In that case it's a mount which isn't managed by systemd, and
   we shouldn't touch it. We mostly want this BindsTo= for mounts where
   the .device units *do* exist, so that when they go away we can clean
   up the mount (mostly for hotpluggable devices and removable media).
   I'll have a deeper look ASAP.
 
  I ran into this myself the other day, and Kay, Daniel and I spent a
  lot of time to come up with a scheme how to deal with the race... And
  I think we have a nice scheme now and I started implementing it.
 
  The idea is that .device units will gain a third state: currently they
  are either dead or plugged, and the new state will be
  tentative. It is entered when a device is referenced in
  /proc/self/mountinfo or /proc/swap, even though it has not yet shown
  up via udev.
 
  This new state has will not result in BindsTo= getting active.
 
  This is implemented now. Please check if this fixes this issue for
  you.
 
 Which commit implements this?
 
 I have an issue on nspawn container shutdown with v219 that I didn't
 have with v215. Systemd is trying to unmount the volumes bind mounted
 by nspawn and it fails because /bin/umount does not exist in my
 container. Systemd keeps trying to umount it in a busy loop. Reverting
 06e9783e2cc12eb6514e80c7f0014295f59b (core/mount: add
 dependencies to dynamically mounted mounts too) fixes my issue.
There was a bunch of fixes on top. See 5bd4b173605142, 628c89cc68ab96fce2d,
496068a8288084ab3.

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

Re: [systemd-devel] Failure(s) Building Systemd with --enable-resolved

2015-04-21 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Apr 21, 2015 at 08:39:35AM -0700, aaron_wri...@selinc.com wrote:
 I've been getting a few problems building systemd with --enable-resolved
 . Any help would be very welcomed. I don't have any problems when 
 compiling with --disable-resolved.
 
 The first problem I got was this:
 
   CCLD   libnss_resolve.la
 libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset 
 used with constant zero length parameter; this could be due to transposed 
 parameters
 /tmp/cc03x1nN.ltrans6.ltrans.o: In function `bus_error_name_to_errno.4725
 ':
 cc03x1nN.ltrans6.o:(.text+0x12bb): undefined reference to 
 `__stop_BUS_ERROR_MAP'
 cc03x1nN.ltrans6.o:(.text+0x12c2): undefined reference to 
 `__start_BUS_ERROR_MAP'
 collect2: ld returned 1 exit status
 
 I got around this be removing -flto from OUR_CFLAGS in the Makefile. 
 How is that change going to impact systemd? Is there a better way to work 
 around this problem?
Afaik nobody has measured that. It will certainly make your compilation
times much shorter :)

 After I got pass the first error, I now get this:
 
   CC src/resolve/resolved-dns-cache.o
 src/resolve/resolved-dns-scope.c: In function ?dns_scope_tcp_socket?:
 src/resolve/resolved-dns-scope.c:260:56: error: ?IP_UNICAST_IF? undeclared 
 (first use in this function)
 src/resolve/resolved-dns-scope.c:260:56: note: each undeclared identifier 
 is reported only once for each function it appears in
It was in kernel 3.4. What kernel headers are you using?

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

Re: [systemd-devel] [PATCH] networkd: introduce vti6 tunnel

On Tue, 21.04.15 15:16, Susant Sahani (sus...@redhat.com) wrote:

  
 +static int netdev_vti6_fill_message_create(NetDev *netdev, Link *link, 
 sd_rtnl_message *m) {
 +Tunnel *t = VTI6(netdev);
 +int r;
 +
 +assert(netdev);
 +assert(link);
 +assert(m);
 +assert(t);
 +assert(t-family == AF_INET6);
 +
 +r = sd_rtnl_message_append_u32(m, IFLA_VTI_LINK, link-ifindex);
 +if (r  0) {
 +log_netdev_error(netdev,
 + Could not append IFLA_IPTUN_LINK 
 attribute: %s,
 + strerror(-r));
 +return r;
 +}

I have now added log_netdev_error_errno(), which takes the error
number as parameter, and opens it up for %m. Hence please rewrite the
7 lines above as these 2:

if (r  0)
return log_netdev_error_errno(netdev, r, Could not append 
IFLA_IPTUN_LINK attribute: %m);

 +r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_LOCAL, 
 t-local.in6);
 +if (r  0) {
 +log_netdev_error(netdev,
 + Could not append IFLA_IPTUN_LOCAL 
 attribute: %s,
 + strerror(-r));
 +return r;
 +}

Similar here.

 +r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_REMOTE, 
 t-remote.in6);
 +if (r  0) {
 +log_netdev_error(netdev,
 + Could not append IFLA_IPTUN_REMOTE 
 attribute: %s,
 + strerror(-r));
 +return r;
 +}

Similar here.

  
  static void vti_init(NetDev *n) {
 -Tunnel *t = VTI(n);
 +Tunnel *t;
  
  assert(n);
 +
 +if (n-kind == NETDEV_KIND_VTI)
 +t =  VTI(n);

Spurious space.

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] networkd-218 seems to ignore .link files

On Tue, 21.04.15 14:47, Tom Gundersen (t...@jklm.no) wrote:

  I'm having a similar problem while running systemd version-219. Did you work
  out what was wrong?
 
  My link file is ignored even when I symlink
  /etc/systemd/network/99-default.link to /dev/null. I don't see anything
  interesting in 'journalctl'.
 
  # udevadm info /sys/class/net/eth0
  P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0
  E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0
  E: ID_BUS=pci
  E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet
  Contror
  E: ID_MODEL_ID=0x8168
  E: ID_NET_DRIVER=r8169
  E: ID_NET_NAME_MAC=enx000db936008c
  E: ID_NET_NAME_PATH=enp1s0
  E: ID_OUI_FROM_DATABASE=PC Engines GmbH
  E: ID_PATH=pci-:01:00.0
  E: ID_PATH_TAG=pci-_01_00_0
  E: ID_PCI_CLASS_FROM_DATABASE=Network controller
  E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
  E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd.
  E: ID_VENDOR_ID=0x10ec
  E: IFINDEX=3
  E: INTERFACE=eth0
  E: SUBSYSTEM=net
  E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
  E: TAGS=:systemd:
  E: USEC_INITIALIZED=53326
 
 
  # networkctl status --no-pager eth0
  ��● 3: eth0
 Link File: n/a
  Network File: n/a
  Type: ether
 State: off (unmanaged)
  Path: pci-:01:00.0
Driver: r8169
Vendor: Realtek Semiconductor Co., Ltd.
 Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH)
   MTU: 1500
 
 
  # cat /etc/systemd/network/01-mgmt.link
  [Match]
  Path=pci-:01:00.0
  Type=ether
 
 Type must be the same as what is returned in DEVTYPE=, which I guess
 is unset for this device. So drop this and it should work.
 
 I see where the confusion stems from though, as we try to be helpful
 and use a heuristic to print a Type in networkctl even when the kernel
 does not expose a type. We probably should not do that, or allow the
 same to be used in the .link matching logic (the heuristic is unlikely
 to be perfect, so I hesitate a bit with the latter).

What precisely is the heuristic? To assume that things are ethernet if
not otherwise specified? Honestly, I think that's good enough, and
probably widely accepted. If this goes wrong I am pretty sure that's
something to fix in the driver, by simply exposing the type then...

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] Setting up network interfaces for containers with --private-network

On Tue, 21.04.15 10:58, Spencer Baugh (sba...@catern.com) wrote:

  The MAC address is currently generated as hash value from the
  container name, it hence should be completely stable already as long
  as you keep using the same name for the container?
 
 Well, generally I want to know what MAC/IP address a machine/container
 will receive in advance of actually starting it. I could start it once
 and immediately stop it to see and record what MAC address is generated
 for a given name, or copy the code to generate the MAC address out of
 nspawn.c, but neither of those seem like good options.

Sidenote: if this is about having stable names to refer to containers,
note that nss-mycontainers adds those automatically. If enabled, then
all local container names will be resolvable, automatically. It's
often hence unnecessary to have fixed IP addresses for this at all.

  maybe the ipvlan stuff could work for you?
 
 It's possible, but then I'd be back to the situation where I need to
 write a script to keep bringing up the ipvlan devices before starting
 the container. Unless ipvlan devices don't disappear when the namespace
 disappears?

Nope, this is the same for ipvlan, macvlan, veth links.

  I am interested in using networkd to do these things, but at the moment
  it doesn't seem to have the required level of power.
 
  what do you mean precisely with this?
 
 I mean that instead of writing another service (probably a shell script)
 to set up the interface on the host, using the PrivateNetwork= and
 JoinsNamespaceOf= trick, instead have networkd set up the interface on
 the host inside a network namespace and use the same kind of trick.

Well, I mean how useful would this actually be? THis would only work
for static configuration, everything more complex requires a daemon
watching the interface continously and that's really hard to do for a
set of network interfaces in a different network namespace.

Also, trivial static IP configuration is seldom sufficient, you at
least need to also provide DNS configuration, and if you don't use
DHCP or something similar then you need to configure that inside the
container anyway. But if you do that you might as well configure the
static IP addresses in it too, so what is gained by doing this from a
networkd outside of the cotnainer?

 Or am I misunderstanding the role of networkd? It seems like if I am
 writing a service that represents the network interface and namespace
 for this container, I am doing something that networkd should
 ultimately do.

Sure, absolutely. But our idea so far was that networkd should run
inside the container to configure the container's network, and on the
host to configure the host's network, but not to cross this boundary
and have the host networkd configure the container's network.

 Set up the interface here just means create the interface with a
 specific MAC address, of course.

Well, of course, we could beef up systemd-nspawn and allow it to take
configurable IP or MAC addresses on the command line, and then it
would become a second networkd, and we already have one of those...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] man/systemd.netdev.xml src/libsystemd src/network