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

[Susant Sahani]

On 04/21/2015 09:54 PM, Lennart Poettering wrote:

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:


Sure I will make the changes.



 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


Susant
___
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

[Michael Olbrich]

On Tue, Apr 21, 2015 at 08:45:30PM +0200, Lennart Poettering 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!

Looks good. My test-cases work just fine.

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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

[Kay Sievers]

On Tue, Apr 21, 2015 at 8:45 PM, Lennart Poettering
 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] mounting loop

[Christian Hesse]

Christian Hesse  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 
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

[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] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=

[David Timothy Strauss]

On Tue, Apr 21, 2015 at 12:26 AM, Martin Pitt  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 v2 2/2] Add more firewire properties for sound, to be closer to USB and PCI

[systemd github import bot]

Patchset imported to github.
Pull request:


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

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

[Nick Owens]

hello tom,

On Mon, Apr 20, 2015 at 2:32 PM, Tom Gundersen  wrote:
> On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau
>  wrote:
>> On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens  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  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  
>>> wrote:
 On Wed, Mar 25, 2015 at 11:49 PM,   wrote:
> From: mischief 
>
> 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

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

[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

[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 1/3] journal: add int↔audit type name mapping

[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 -  > -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] Failure(s) Building Systemd with "--enable-resolved"

[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

[systemd-devel] systemd-nspawn trouble

[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] unit: When stopping due to BindsTo=, log which unit caused it

[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
>  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] Zombie process still exists after stopping gdm.service

[Daniel Drake]

On Mon, Apr 20, 2015 at 6:29 PM, Lennart Poettering
 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

[Spencer Baugh]

Lennart Poettering  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

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

[Lennart Poettering]

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.
>
> +  
> +TimeoutIdleSec=
> +Configures 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.
> +  
>  
>
>  
> 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 @@
>
>  
>
> +x-systemd.idle-timeout=
> +
> +Configures the idleness timeout of the
> +automount unit. See TimeoutIdleSec= in
> +
> systemd.automount5
> +for details.
> +  
> +
> +  
>  x-systemd.device-timeout=
>  
>  Configure 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",
> +"%sDirectoryMode: %04o\n"
> +"%sTimeoutIdleUSec: %s\n",
>  prefix, automount_state_to_string(a->state),
>  prefix, automoun

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

[Aaron_Wright]

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?

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

I'm not sure what to do about this one. Ideas?

Versions (Upgrading is not trivial. Patching is much easier.):

GNU ld (GNU Binutils for Ubuntu) 2.22
gcc-4.6.real (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3___
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

[Lennart Poettering]

On Tue, 21.04.15 01:30, Lennart Poettering (lenn...@poettering.net) wrote:

> > +if (b->arp_interval != 0) {
> > +r = sd_rtnl_message_append_u32(m, IFLA_BOND_ARP_INTERVAL, 
> > b->arp_interval / USEC_PER_MSEC);
> > +if (r < 0) {
> > +log_netdev_error(netdev,
> > + "Could not append 
> > IFLA_BOND_ARP_INTERVAL attribute: %s",
> > + strerror(-r));
> > +return r;
> > +}
> > +}
> 
> I'd really prefer if we wouldn't add new code using strerror().
> 
> Maybe it's time to introduce log_netdev_error_errno(), that is the
> combination of what log_error_errno() and log_netdev_error() do? We
> already have the anem for log_network_xyz()...

I added log_netdev_error_errno() now, and converted a good chunk of
the networkd code to use it. Would be great to get the rest converted
too!

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

[Lennart Poettering]

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] [PATCH] networkd: introduce vti6 tunnel

[Lennart Poettering]

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

[Lennart Poettering]

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

[Spencer Baugh]

Lennart Poettering  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

[Alban Crequy]

On Sat, Feb 28, 2015 at 5:40 PM, Lennart Poettering
 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

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

[Tom Gundersen]

On Tue, Apr 14, 2015 at 7:08 PM, Andrew Cooks  wrote:
> On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt  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] networkd man: fix man and config name.

[Tom Gundersen]

On Tue, Apr 21, 2015 at 1:16 PM, Susant Sahani  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 @@
>>> 
>>>
>>> 
>>> -LearnPacketIntvSec,=
>>> +LearnPacketIntervalSec,=
>>
>>
>> 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] [PATCH] networkd man: fix man and config name.

[Susant Sahani]

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 @@



-LearnPacketIntvSec,=
+LearnPacketIntervalSec,=


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

[Lennart Poettering]

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.

[Lennart Poettering]

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 @@
>
>  
>
> -LearnPacketIntvSec,=
> +LearnPacketIntervalSec,=

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

[Lennart Poettering]

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

> Lennart Poettering  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: introduce vti6 tunnel

[systemd github import bot]

Patchset imported to github.
Pull request:


--
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

[Susant Sahani]

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:  mtu 1500 qdisc noop state DOWN mode DEFAULT
group default
link/tunnel6 :: brd ::
12: ip6vti@wlan0:  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 @@
   vti
   An IPv4 over IPSec tunnel.
 
+  vti6
+  An IPv6 over IPSec tunnel.
+
   vxlan
   A virtual extensible LAN (vxlan), for connecting Cloud 
computing deployments.
 
@@ -441,7 +444,8 @@
 gretap,
 ip6gre,
 ip6gretap,
-vti, and
+vti,
+vti6, and
 ip6tnl and accepts
 the following keys:
 
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;
+}
+
+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",
+  

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

[systemd github import bot]

Patchset imported to github.
Pull request:


--
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.

[systemd github import bot]

Patchset imported to github.
Pull request:


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

[systemd github import bot]

Patchset imported to github.
Pull request:


--
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

[systemd github import bot]

Patchset imported to github.
Pull request:


--
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=

[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
 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

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

[Susant Sahani]

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 @@
   
 
   
-LearnPacketIntvSec,=
+LearnPacketIntervalSec,=
 
   Specifies the number of seconds between instances where the 
bonding
   driver sends learning packets to each slaves peer switch.
@@ -687,7 +687,7 @@
   
 
   
-FailOverMac=
+FailOverMACPolicy=
 
   Specifies 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 @@
   
 
   
-ArpValidate=
+ARPValidate=
 
   Specifies 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
   none,
@@ -716,7 +716,7 @@
   
 
   
-ArpIntervalSec=
+ARPIntervalSec=
 
   Specifies the ARP link monitoring frequency in milliseconds.
   A value of 0 disables ARP monitoring. The default value is 0.
@@ -725,10 +725,10 @@
   
 
   
-ArpIpTargets=
+ARPIPTargets=
 
   Specifies 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 @@
   
 
   
-ArpAllTargets=
+ARPAllTargets=
 
-  Specifies the quantity of ArpIpTargets that must be reachable
+  Specifies 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
   any,
   all
   
@@ -752,7 +752,7 @@
   
 
   
-PrimaryReselect=
+PrimaryReselectPolicy=
 
   Specifies the reselection policy for the primary slave.  This
   affects how the primary slave is chosen to become the active slave
@@ -791,16 +791,16 @@
   
 
   
-NumGratuitousARP=
+GratuitousARP=
 
   Specify 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.
   
 
   
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, match_host)
-Match.Virtualization, config_parse_net_condition, 
CONDITION_VIRTUALIZATION,  offsetof(NetDev, match_virt)
-Match.KernelCommandLine,  config_parse_net_condition, 
CONDITION_KERNEL_COMMAND_LINE, offsetof(NetDev, match_kernel)
-Match.Architecture,   config_parse_net_condition, 
CONDITION_ARCHITECTURE,offsetof(NetDev, match_arch)
-NetDev.Description,   config_parse_string,0,   
  offsetof(NetDev, description)
-NetDev.Name,  config_parse_ifname,0,   
  offsetof(NetDev, ifname)
-NetDev.Kind,  config_parse_netdev_kind,   0,   
  offsetof(NetDev, kind)
-NetDev.MTUBytes,

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

[Susant Sahani]

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:



+  
+LearnPacketIntvSec,=
+
+  Specifies 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.
+
+  



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


+  
+FailOverMac=
+
+  Specifies 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
+  none,
+  active,
+  follow
+  
+
+  


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?


+
+  
+ArpValidate=
+
+  Specifies 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
+  none,
+  active,
+  backup,
+  all
+  
+
+  


Uppercase "ARP" please, see above. ARPValidate=


+  
+ArpIntervalSec=
+
+  Specifies the ARP link monitoring frequency in milliseconds.
+  A value of 0 disables ARP monitoring. The default value is 0.
+  
+
+  


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


+  
+ArpIpTargets=
+
+  Specifies 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.
+  
+
+  


s/Arp/ARP/

s/Ip/IP/

Maybe append "Address"?


+
+  
+ArpAllTargets=
+
+  Specifies 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
+  any,
+  all
+  
+
+  


similar...


+
+  
+PrimaryReselect=
+
+  Specifies 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
+  always,
+  better,
+  failure
+  
+
+  


PrimaryReselectPolicy= or so?


+
+  
+ResendIGMP=
+
+  Specifies 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.
+  
+
+  


I like the that the "IGMP" name is upper case!


+  
+NumGratuitousARP=
+
+  Specify 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
+greater than 1. The valid range is (0 - 255). Default value is 1.
+These options affect only the active-backup mode
+  
+
+  


"Num"? Nah, please no unnecessary abbreviations.

The last sentence lacks a full stop.



+if (b->arp_interval != 0) {
+r = sd_rtnl_message_append_u32(m, IFLA_BOND_ARP_INTERVAL, 
b->arp_int

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

[Martin Pitt]

Hello Kyungmin,

Kyungmin Park [2015-04-21  9:21 +0900]:
> At mobile. some daemon is not doing exact daemon task. it acts like
> app. so it's kill-able based on priority. now it can't know it's idle
> or not. In the app-like daemon developer, they don't want to exit
> since performance reason. but in the view of system admin, it's
> resource waste. it's better to kill if it know it's idle.

I'm not at all convinced that this is a good strategy. For maximum
efficiency you *do* want to let apps stay in RAM/in the background as
long as you have enough memory, so that they don't need to
re-load/link/initialize when you call them again. So regular
time-based sweeps are too aggressive here and lead to unnecessary app
starts (which take a lot more CPU/battery than a simple context
switch).

On the other hand, if you start a new app and it doesn't get enough
RAM, you want/need to start killing existing background apps
oldest-to-newest (or perhaps biggest-to-smallest) until you have
enough RAM again, but that needs to happen immediately. You don't want
to wait until the next idle counter timer for this to happen.

Finally, waking up the device every 30 s to clean up "idle" apps takes
CPU/battery by itself.

So I see no use case for idle timer based cleanup. Can you please
explain why they are better than on-demand cleanup?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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