Re: [systemd-devel] ipv6 configuration error

[Tom Gundersen]

On Fri, May 27, 2016 at 5:11 PM, Michał Zegan 
wrote:

> Hello, I have encountered a very interesting problem: I have a wired
> ipv4 network configured via systemd-network, and an ipv6 sit tunnel.
> The problem is it does not start. trying to restart systemd-networkd
> gives the error like both local and remote addresses of the tunnel are
> incompatible. I assume that means there is no interface matching those
> ipv4 addresses. I know that eth0 interface is configured *after* this
> sit one, and it is configured via dhcp, so it is quite possible. What is
> happening?
>

Hi Michał,

Could you configure it manually (using ip(8) or something) and paste the
output of `ip link` and `ip addr`, and also attach the networkd
configuration you tried to use (would be great of course if you could make
it as minimal as possible, but still showing your problem).

Cheers,

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

Re: [systemd-devel] Where is DHCP Address stored?

[Tom Gundersen]

On Sat, Nov 28, 2015 at 4:42 PM, J Decker <d3c...@gmail.com> wrote:
> On Sat, Nov 28, 2015 at 7:36 AM, Tom Gundersen <t...@jklm.no> wrote:
>> On Sat, Nov 28, 2015 at 4:33 PM, J Decker <d3c...@gmail.com> wrote:
>>> Okay maybe it's not stored anywhere
>>>
>>> I was just having a plethora of network issues after updating.
>>>
>>> After finding others were reporting issues with the linux kernel 4.2.5
>>> I rollback to the prior stable 4.1.6... that resolved some of the
>>> issues; but I was still getting a spam of messages every few seconds.
>>> I reverted to systemd-227 and these stopped.
>>
>> Distro?
>
> Arch; did an update lastnight/this morning when my networking fell apart.

As far as I can tell the fixes for these issues are upstream, but not
backported. You could try with current git, or ask downstream to
backport.

>>> Nov 28 07:18:14 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:14 tower2 systemd-networkd[354]: br0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:19 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:19 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:19 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:19 tower2 systemd-networkd[354]: br0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:25 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:25 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:25 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:25 tower2 systemd-networkd[354]: br0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:30 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:30 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:30 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:30 tower2 systemd-networkd[354]: br0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:35 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:35 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:35 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:35 tower2 systemd-networkd[354]: br0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>> Nov 28 07:18:41 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
>>> client on NDisc request failed: Invalid argument
>>>
>>>
>>>
>>> On Sat, Nov 28, 2015 at 4:18 AM, J Decker <d3c...@gmail.com> wrote:
>>>> I recently updated my system, and am probably using systemd-228
>>>>
>>>> When the network starts, the device I have configured as DHCP
>>>> [Match]
>>>> Name=eth0
>>>>
>>>> [Network]
>>>> DHCP=ipv4
>>>> Tunnel=he-ipv6
>>>>
>>>> comes up with the old address and no default route set.  If I disable
>>>> that and manually run dhcpcd eth0 I get a valid IP and a default route
>>>> that is an entirely different network than I get from systemd... so it
>>>> must be saving the old address somewhere; but I cannot find any
>>>> reference to that lease/state file.
>>> ___
>>> 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] Where is DHCP Address stored?

[Tom Gundersen]

On Sat, Nov 28, 2015 at 4:33 PM, J Decker  wrote:
> Okay maybe it's not stored anywhere
>
> I was just having a plethora of network issues after updating.
>
> After finding others were reporting issues with the linux kernel 4.2.5
> I rollback to the prior stable 4.1.6... that resolved some of the
> issues; but I was still getting a spam of messages every few seconds.
> I reverted to systemd-227 and these stopped.

Distro?

> Nov 28 07:18:14 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:14 tower2 systemd-networkd[354]: br0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:19 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:19 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:19 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:19 tower2 systemd-networkd[354]: br0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:25 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:25 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:25 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:25 tower2 systemd-networkd[354]: br0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:30 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:30 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:30 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:30 tower2 systemd-networkd[354]: br0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:35 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:35 tower2 systemd-networkd[354]: he-ipv6: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:35 tower2 systemd-networkd[354]: eno1: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:35 tower2 systemd-networkd[354]: br0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
> Nov 28 07:18:41 tower2 systemd-networkd[354]: eth0: Starting DHCPv6
> client on NDisc request failed: Invalid argument
>
>
>
> On Sat, Nov 28, 2015 at 4:18 AM, J Decker  wrote:
>> I recently updated my system, and am probably using systemd-228
>>
>> When the network starts, the device I have configured as DHCP
>> [Match]
>> Name=eth0
>>
>> [Network]
>> DHCP=ipv4
>> Tunnel=he-ipv6
>>
>> comes up with the old address and no default route set.  If I disable
>> that and manually run dhcpcd eth0 I get a valid IP and a default route
>> that is an entirely different network than I get from systemd... so it
>> must be saving the old address somewhere; but I cannot find any
>> reference to that lease/state file.
> ___
> 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] DHCPC Events?

[Tom Gundersen]

This is not really exposed nicely. There is a C library sd-network, which
will give you the events you want, but it is not yet public (you can still
copy it out of git of course).
On Nov 12, 2015 05:24, "J Decker"  wrote:

> Should I have not said specifically Arch linux?
> Is it something that can't be done?
> It is something that should be so obvious it doesn't merit an answer?
>
>
>
> On Fri, Nov 6, 2015 at 1:56 PM, J Decker  wrote:
> > I have Arch Linux setup as my router.
> > It's on a connection that can change the IP that I'm given, when that
> > happens I need to rerun firewall rules and rebuild my ipv6 tunnel.
> > How do I run some script or something when the address changes (or
> > when it's initially given in the case of boot?)
> >
> > Also there seems to be no way to specify default ipv6 route for next
> > hop... ie 'ip -6 route replace ::/0 dev he-ipv6'
> > It's been a couple months I've been limping along so I forget; I
> > vaguely remember that this should have been setup in the configuration
> > scripts; but it didn't work unless I did it this way.  The iniital
> > method I think was 'add' instead of 'replace' which no longer works (I
> > think something changed in the kernel that affected that; but I don't
> > know).
> ___
> 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] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

[Tom Gundersen]

On Tue, Nov 10, 2015 at 2:29 PM, Jordan Hargrave  wrote:
> On Tue, Nov 10, 2015 at 4:53 AM, Kay Sievers  wrote:
>> On Tue, Nov 10, 2015 at 5:49 AM, Jordan Hargrave  wrote:
>>> Cleaned up linux coding style
>>>
>>> This patch will integrate some of the features of biosdevname into systemd.
>>> The code detects the port and index for detecting NIC partitions. This 
>>> creates
>>> a new environment variable, ID_NET_NAME_PARTITION of the format
>>> _
>>>
>>> The patch will also decode SMBIOS slot number for NIC, and store in the 
>>> variable
>>> ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method for naming
>>> ports on a multi-port card plugged into a slot.
>>
>> Again, I don't think systemd should carry an SMBIOS parser.
>>
>> Sorry,
>> Kay
>
> From a customer usability standpoint, having the slot numbers as part
> of systemd would be a very useful feature.

Sure, but I think Kay's point was that the needed info should be
exposed from the kernel in a sysattr, not be parsed from udev. Any
reason this cannot be done that way?

>  The current method only
> works for single-port NICs in a slot.  Multi-port NICs, especially
> ones with SR-IOV or multiple partitions get garbled names like

Just to make sure we are on the same page, when you say "garbled" you
mean that the naming scheme is not the one you want, but there are no
bugs here, right?

> enp4s0
> enp4s1
> enp4s0d1
> enp4s0f1
> enp4s0f2
> enp4s0f3
> enp4s0f4
> enp4s0f5
> enp4s0f6
> enp4s0f7
> enp4s0f1d1
> enp4s0f2d1
> enp4s0f3d1
> enp4s0f4d1
> enp4s0f5d1
> enp4s0f6d1
> enp4s0f7d1
> enp4s1d1
> enp68s0f0
> enp68s0f1
> enp69s0f0
> enp69s0f1
>
> That's another annoying thing with systemd names, the bus number is
> *decimal*.  lspci is in hex, so the customer has to do a conversion to
> figure out even what PCI device that is.

I guess too late to change that now.

> All enp4 are a dual-port NIC in Slot 3 with 8 SR-IOV devices.

Hm, there are 17 devices listed, shouldn't there be 16 based on your
description?

> All enp68xx and enp69xxx are a single quad-port NIC in slot 2.
> Systemd breaks here if trying to name using slot numbers with the
> existing method.  As there are 4 devices under the slot with same
> device numbers, systemd would name them
> ens2f0
> ens2f1
> ens2f0
> ens2f1
>
> Which causes name collision.  I was able to verify this as either they
> got named:
> ens2f0
> ens2f1
> enp69s0f0
> enp69s0f1
>
> or
> enp68s0f0
> enp68s0f1
> ens2f0
> ens2f1
>
> at startup.
>
> That's the best feature of biosdevname, being able to tell which slot
> the NIC is located just from the name.  Systemd still has some
> limitations and/or bugs in this regard.

So how would your proposed naming scheme look in the examples you
gave? Is the information needed to generate the name taken from the
device in question or any of its parent devices (but never from its
siblings or other devices) and hence independent of probe-ordering?

Cheers,

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

Re: [systemd-devel] Secret machine-id for RFC 7217 stable addresses

[Tom Gundersen]

Hi Lubomir,

Sorry not to have responded to this earlier, but as I was just
reminded of this, here are my take:

On Mon, Sep 7, 2015 at 7:49 PM, Lubomir Rintel  wrote:
> the RFC 7217 specifies an algorithm for generating an IPv6 host address
> that stays stable in a particular network but changes when the machine
> enters another network to prevent tracking [1]. It works by hashing a
> tuple of various parameters one of which is "secret_key" -- a secret
> value specific to a particular machine.
>
> [1] https://tools.ietf.org/html/rfc7217#section-5
>
> This sounds a bit like machine-id, unfortunately given it's world
> readable and available via DBus (and possibly on a network?) it doesn'tseem 
> to be secret enough.
>
> I'm wondering if it would make sense to reuse some of the tooling?
> Would it make sense to extend systemd-machine-id-setup(1) to generate
> one more identifier or maybe add another tool to set up the secret id?

A priori, it would perhaps have been nice to consider the real
machine-id on disk to be "secret", and only ever expose a hash of it,
but that ship has sailed I'm afraid. We could of course introduce a
second machine-id as you propose, but before doing that I'd like to
fully understand if that really solves the problem.

If I understand correctly, most of the point of RFC7217 is achieved
even if the secret key is known. The important point is to have a good
hashing function, and in that case knowing the secret key will not let
you discover any of the other parameters (which are the ones you
really want to hide).

Moreover, if the point is privacy, if an attacker has access (in some
way) to the machine-id, there is no point in him going after the
interface identifier as he can already identify the client.

Given those two facts, might it not be sufficient to use the
machine-id as the secret key after all? Or am I missing something?

Cheers,

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

Re: [systemd-devel] Persistent virtio device name removal

[Tom Gundersen]

Hi Michael,

A follow-up on this, we finally figured out a way to make virtio
netdev naming persistent [0], so this will work again as of the next
release. It's a shame we had to go back and forth on this, but I hope
it does not cause you too much headaches.

Cheers,

Tom

[0]: 
<https://github.com/systemd/systemd/commit/54683f0f9b97a8f88aaf4fbb45b4d729057b101c>

On Fri, Jul 4, 2014 at 1:31 AM, Tom Gundersen <t...@jklm.no> wrote:
> On Fri, Jul 4, 2014 at 12:55 AM, Michael Marineau
> <michael.marin...@coreos.com> wrote:
>> Working on bumping to 215 over here in CoreOS land, but I've got a
>> question regarding the removal of persistent device names for virtio
>> devices since changing the network device names creates a difficult
>> upgrade path from 212. The commit was:
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf81e792f3c0aed54edf004c1c95cc6f6d81d0ee
>> "udev: persistent naming - we cannot use virtio numbers as they are not 
>> stable"
>>
>> The commit doesn't say what the issue was, in what situations are the
>> virtio numbers not stable?
>
> They suffer from the same problem as the ethX enumeration. In many
> cases they appear to be stable (as drivers typically get loaded in the
> same order etc), but there is nothing ensuring it, so we can't rely on
> that.
>
> Cheers,
>
> Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Configurability for systemd logging API

[Tom Gundersen]

On Thu, Jul 30, 2015 at 8:16 AM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
 Such messages correspond to specific data structures.
 * The log origin and log level are repeated there while the recorded
   information might occasionally not be detailed enough.
   I find that such details can be better handled by the software build 
 system.
 …
 I appreciate you wanting to help, but this is not helpful.

 Thanks for your feedback.


 Please post patches if you have suggestions for improvements.

 I find that the change acceptance is unclear for fine-tuning of this software
 also around message log programming interfaces.
 Which design approaches do you find acceptable for further considerations?

Sorry, I really can't follow. If you post a patch we can take it from there.

Cheers,

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

Re: [systemd-devel] kdbus, udev and systemd in the initramfs

[Tom Gundersen]

On Wed, Jul 29, 2015 at 2:23 PM, Michael Biebl mbi...@gmail.com wrote:
 2015-07-29 5:40 GMT+02:00 Tom Gundersen t...@jklm.no:
 On Wed, Jul 29, 2015 at 1:21 AM, Michael Biebl mbi...@gmail.com wrote:
 something I was wondering regarding kdbus and udev.
 If udev wants to drop the netlink transport and instead rely on kdbus,
 would this mean, systemd becomes mandatory in the initramfs to setup
 kdbus before udev is run?

 _If_ udev drops netlink entirely, then yes someone would need to set
 up kdbus. How this will all look has not been finally decided yet
 though.

 Is this documented somewhere, what kind of setup needs to be done for
 kdbus?

Well, kdbus itself is extensively documented in the kernel man pages
[0], but I'm not aware of any step-by-step documentation for how to
make an alternative kdbus userspace implementation. Probably your best
bet is to look at the systemd code.

 How complicated is it, to get kdbus up and running with a
 minimal environment like the initramfs?

In principle, not hugely complicated. However, probably not worth the
effort unless you have a good reason to. Wouldn't it be simpler to
just use systemd (even if just as a wrapper around your current
scripts)?

Either way, I probably wouldn't put any serious amount of work into
this just for the sake of udev quite yet. We still don't know
precisely how it will shake out. In general though, I would expect
that one day you'll want kdbus in the initramfs for one reason or
another.

Cheers,

Tom

[0]: http://www.freedesktop.org/software/systemd/kdbus/kdbus.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Configurability for systemd logging API

[Tom Gundersen]

Hi Markus,

On Wed, Jul 29, 2015 at 8:54 PM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
 Programs from the systemd software library output also some log messages
 as it is usual for such server applications.

 Such messages correspond to specific data structures.
 * The log origin and log level are repeated there while the recorded
   information might occasionally not be detailed enough.
   I find that such details can be better handled by the software build system.

 * The involved text repetition results in improvement possibilities
   depending on preferred design directions.
   Some substrings could be eventually shared between message variants
   if this aspect can be selected as an optimisation goal
   for the corresponding generation of executable software.
   https://en.wikipedia.org/wiki/Longest_common_subsequence_problem

I appreciate you wanting to help, but this is not helpful. Please post
patches if you have suggestions for improvements.

Cheers,

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

Re: [systemd-devel] kdbus, udev and systemd in the initramfs

[Tom Gundersen]

On Wed, Jul 29, 2015 at 5:40 AM, Tom Gundersen t...@jklm.no wrote:
 On Wed, Jul 29, 2015 at 1:21 AM, Michael Biebl mbi...@gmail.com wrote:
 something I was wondering regarding kdbus and udev.
 If udev wants to drop the netlink transport and instead rely on kdbus,
 would this mean, systemd becomes mandatory in the initramfs to setup
 kdbus before udev is run?

 _If_ udev drops netlink entirely, then yes someone would need to set
 up kdbus. How this will all look has not been finally decided yet
 though.

Actually, the problem might not even be netlink (as you may not have
anything using libudev in your intrd), but then the problem will be
the custom udev control protocol which would surely also be swapped
out if netlink is.

 Will it still be possible in the future to run udev  without systemd
 in the initramfs?

 Maybe, but I, for one, don't see this as a long-term goal. Having the
 same software in the initrd as on the real system seems much more
 reasonable to me.

 Cheers,

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

Re: [systemd-devel] kdbus, udev and systemd in the initramfs

[Tom Gundersen]

On Wed, Jul 29, 2015 at 1:21 AM, Michael Biebl mbi...@gmail.com wrote:
 something I was wondering regarding kdbus and udev.
 If udev wants to drop the netlink transport and instead rely on kdbus,
 would this mean, systemd becomes mandatory in the initramfs to setup
 kdbus before udev is run?

_If_ udev drops netlink entirely, then yes someone would need to set
up kdbus. How this will all look has not been finally decided yet
though.

 Will it still be possible in the future to run udev  without systemd
 in the initramfs?

Maybe, but I, for one, don't see this as a long-term goal. Having the
same software in the initrd as on the real system seems much more
reasonable to me.

Cheers,

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

Re: [systemd-devel] [PATCH] Remove accelerometer helper

[Tom Gundersen]

On Sat, Jun 27, 2015 at 10:02 PM, Kay Sievers k...@vrfy.org wrote:
 On Fri, May 22, 2015 at 3:42 PM, Bastien Nocera had...@hadess.net wrote:
 It's moved to the iio-sensor-proxy D-Bus service.
 ---
  .gitignore |   1 -
  Makefile.am|  15 --
  rules/61-accelerometer.rules   |   3 -
  src/udev/accelerometer/Makefile|   1 -
  src/udev/accelerometer/accelerometer.c | 303 

 https://github.com/systemd/systemd/pull/387

This was now merged, so distros should be aware that they need to pick
up iio-sensor-proxy with the next systemd release.

Cheers,

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

Re: [systemd-devel] systemd-nspawn: cannot join existing macvlan

[Tom Gundersen]

On Thu, Jun 18, 2015 at 9:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Sat, 30.05.15 19:55, Kai Krakow (hurikha...@gmail.com) wrote:

 The next issue with your argument is: AFAIR nspawn doesn't create a macvlan
 interface based on the machine name. You have to pass the name of a physical
 interface which transports this macvlan. The man page at least states that
 you use an existing physical interface:

 True, I was a bit confused there...


 --network-macvlan=
 Create a macvlan interface of the specified Ethernet network
 interface and add it to the container. A macvlan interface is a
 virtual interface that adds a second MAC address to an existing
 physical Ethernet link. The interface in the container will be named
 after the interface on the host, prefixed with mv-. Note that
 --network-macvlan= implies --private-network. This option may be
 used more than once to add multiple network interfaces to the
 container.

 Trying to nspawn a macvlan without giving a physical device results in no
 such device:

 # systemd-nspawn --boot --link-journal=try-guest --machine=gentoo-mysql-base
 --network-macvlan=
 systemd-nspawn: option '--network-macvlan' requires an argument

 # systemd-nspawn --boot --link-journal=try-guest --machine=test --network-
 macvlan=test
 Spawning container test on /var/lib/machines/test.
 Press ^] three times within 1s to kill container.
 Failed to resolve interface test: No such device

 So your assumption about macvlan seems to be incorrect. The other network
 types may be based off the machine name but it doesn't work this way with
 macvlan.

 Yeah, nspawn creates a n interface mv-foo from a network interface
 foo on the host.

 So I wonder what the purpose of macvlan is if you can only create one
 machine using macvlan on my single physical link - and that's it?

 I am not sure I follow. The mv-foo interface will be part of the
 container, not the host. That means if you run 10 containers, all with
 --network-macvlan=foo, then they each will have an interface called
 mv-foo, but with a different ifindex each. Or are you suggesting
 that that's currently broken?

 I think the logic is wrong here in systemd-nspawn. Instead of trying to
 create the host-side macvlan itself it should insist of it being there
 already (to have one well-defined state to start with, and only optionally
 create it by itself). Then, it can join multiple machines to the same
 macvlan.

 I don't grok this?

 the same macvlan?

 I'm using the following networkd config on the host to define this well-
 defined state, enabling the host to also communicate through macvlan:

 # cat /etc/systemd/network/10-macvlan.{netdev,network}
 [NetDev]
 Name=mv-enp5s0
 Kind=macvlan

 [MACVLAN]
 Mode=bridge
 #
 [Match]
 Name=en*

 [Network]
 MACVLAN=mv-enp5s0
 LinkLocalAddressing=no
 DHCP=no

 If I remove this I am able to start one of the containers, but not two or
 more. If I use this I am not able to start any macvlan container.

 I have the suspicion that the confusion here stems from the fact that
 nspawn creates the macvlan iface on the host first, then moves it into
 the container.

Hm, you sure about this? I thought we create the macvlan device
directly in the network namespace. There should be no possible
name-conflict with devices on the host...

 but if you already have an iface by that name on the
 host, then it cannot create the macvlan under that name.

 I figure we can fix that by creating the iface under a random name
 first on the host, then move it into the container, and then rename it
 to the right name afterwarads.

 A work-around would be to name the .netdev iface of yours something
 else than mv-enp5s0, call it waldi or so, so that it doesn't
 conflict with the name for the contaainer in the short time-frame that
 the iface nspawn creates exists on the host...

 Can you verify if such a change fixes your issue? If so, we can
 randomoize the name initially, as sugegsted above.

 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] Regression: loop device detach errors in 220

[Tom Gundersen]

Thanks for the report.

This should hopefully be fixed by https://github.com/systemd/systemd/pull/65

Cheers,

Tom

On Wed, Jun 3, 2015 at 5:34 PM, Jan Janssen medhe...@web.de wrote:
 Hi,

 systemd-shutdown in 220 has errors when detaching loop devices:

 systemd-shutdown[1]: Failed to detach loop devices: Invalid argument
 cgroup: option or name mismatch, new: 0x0 , old: 0x4 systemd
 systemd-shutdown[1]: Failed to detach loop devices: Invalid argument
 systemd-shutdown[1]: Failed to detach loop devices: Invalid argument
 systemd-shutdown[1]: Failed to finalize _ loop devices, ignoring

 https://bugs.archlinux.org/task/45111

 c32eb440bab953a0169cd207dfef5cad16dfb340 is the first bad commit
 Author: Tom Gundersen t...@jklm.no
 Date:   Tue Apr 14 16:25:06 2015 +0200

 libudev: make libudev-enumerate a thin wrapper around sd-device

 :100644 100644 837fd36381315029171562b344dca8620528d327
 68d8252b84c13591cf8e0b0e15a99780f5dd0309 M  Makefile.am
 :04 04 c54e32bc21e34cc28693fbf653c4128a0383d3d7
 11e1eeec94338e9294e25e720007c35f229d24cf M  src

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

Re: [systemd-devel] [PATCH] mount-setup: create /run/systemd/netif/links/ before accessing

[Tom Gundersen]

On Mon, Jun 1, 2015 at 9:16 PM, Robert Schwebel
r.schwe...@pengutronix.de wrote:
 systemd-timesyncd breaks with

   Starting Network Time Synchronization...
   [FAILED] Failed to start Network Time Synchronization.

 when we have timesyncd activated and systemd-networkd not. Create
 directory before using it.

Hm, this is surely the wrong fix. PID1 should not know about
networkd/timesyncd. Either this should be created by a tmpfiles
fragment, or timesyncd should learn not to care about missing
networkd.

-t

 ---
  src/core/mount-setup.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
 index ba96741e9549..25412a1c42d3 100644
 --- a/src/core/mount-setup.c
 +++ b/src/core/mount-setup.c
 @@ -393,6 +393,8 @@ int mount_setup(bool loaded_policy) {
  mkdir_label(/run/systemd, 0755);
  mkdir_label(/run/systemd/system, 0755);
  mkdir_label(/run/systemd/inaccessible, );
 +   mkdir_label(/run/systemd/netif, 0755);
 +   mkdir_label(/run/systemd/netif/links, 0755);

  return 0;
  }
 ___
 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] mount: use libmount to monitor mountinfo utab

[Tom Gundersen]

On Tue, Jun 2, 2015 at 1:53 PM, Karel Zak k...@redhat.com wrote:
 On Mon, Jun 01, 2015 at 05:06:56PM +0200, Tom Gundersen wrote:
  -(void) 
  sd_event_source_set_description(m-mount_utab_event_source, 
  mount-utab-dispatch);
  +sd_event_source_set_description(m-mount_event_source, 
  mount-monitor-dispatch);

 This should be cast to (void) unless you check the return.

 Frankly, I don't like it. It's old-style programming garbage. For
 compiler it's probably irrelevant construction and for developers
 (code readers) we have better things like warn_unused_result.

The policy in systemd is that as a general rule we check the return
value of functions, only if it truly does not matter do we explicitly
indicate this by casting to void. This is as much for readers of the
code (who can then distinguish between accidentally forgetting to
check the return and intentionally ignoring it) as for static checkers
(Coverity in particular will complain).

 I have removed many of these (void) from util-linux and nobody
 complains.

 If you really want to force people to check return code than mark
 function by warn_unused_result and if you still want to ignore the
 result for these functions in some situations then you can use
 something like:

I don't think warn_unused_result is the right thing to do btw, that is
about the provider enforcing checking of result whereas our policy is
as a consumer (both of our internal functions and external libraries).

 # define ignore_result(x) __extension__ ({ \
 __typeof__(x) __dummy __attribute__((__unused__)) = (x);
 (void) __dummy; \
 })


 the result is more readable and obvious:

ignore_result( sd_event_source_set_description(foo, bar ) );


 Sometimes we use this macro to keep silent some crazy glibc functions.


 Anyway, if (void) is really systemd coding style then I'm going to
 update the patch. No problem ;-)

Thanks!

Cheers,

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

Re: [systemd-devel] sd-device: fix invalid property strv pointers

[Tom Gundersen]

On Mon, Jun 1, 2015 at 11:39 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 With our 220 package I still get a broken environment in udev
 callouts, even with Tom's recent fix 0e3e605 applied.

 Curiously it works for devices like lo which don't have a lot of
 properties, but for real wlan devices I get invalid environment
 variables. With some debugging applied (http://paste.ubuntu.com/11492452/)
 this is visible in the bogus strings that udev_device_get_properties_envp()
 returns: http://paste.ubuntu.com/11492458/

 I tracked that down to invalid memory handling in
 device_update_properties_bufs(). Patch attached with detailled
 explanation.

Thanks for figuring this out Martin. The patch looks good to me,
though maybe we should use NULSTR_FOREACH for the second loop?

Go ahead and push.

Cheers,

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

Re: [systemd-devel] [PATCH] mount: use libmount to monitor mountinfo utab

[Tom Gundersen]

Hi Karel,

On Mon, Jun 1, 2015 at 2:07 PM, Karel Zak k...@redhat.com wrote:
 The current implementation directly monitor /proc/self/mountinfo and
 /run/mount/utab files. It's really not optimal because utab file is
 private libmount stuff without any official guaranteed semantic.

 The libmount since v2.26 provides API to monitor mount kernel 
 userspace changes. This patch replaces the current implementation with
 libmount based solution.

 Now the manager.h includes libmount.h, so $MOUNT_CFLAGS has been
 necessary to add to many tests CFLAGS.

 Note that mnt_monitor_event_cleanup() in v2.26 is broken, so the patch
 uses mnt_monitor_next_change(). It's exactly the same solution which
 uses the current libmount HEAD (mnt_monitor_event_cleanup() is API
 shorcut only).


Tiny nitpick below, otherwise look good to me.

Cheers,

Tom

 ---
  Makefile.am|  33 --
  configure.ac   |   2 +-
  src/core/manager.c |   2 +-
  src/core/manager.h |   5 ++-
  src/core/mount.c   | 100 
 -
  5 files changed, 49 insertions(+), 93 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index ed5135d..3815e72 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -1352,7 +1352,8 @@ systemd_SOURCES = \

  systemd_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  systemd_LDADD = \
 libsystemd-core.la \
 @@ -1554,7 +1555,8 @@ test_engine_SOURCES = \

  test_engine_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_engine_LDADD = \
 libsystemd-core.la \
 @@ -1565,7 +1567,8 @@ test_job_type_SOURCES = \

  test_job_type_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_job_type_LDADD = \
 libsystemd-core.la \
 @@ -1609,7 +1612,8 @@ test_unit_name_SOURCES = \

  test_unit_name_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_unit_name_LDADD = \
 libsystemd-core.la \
 @@ -1620,7 +1624,8 @@ test_unit_file_SOURCES = \

  test_unit_file_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_unit_file_LDADD = \
 libsystemd-core.la \
 @@ -1838,7 +1843,8 @@ test_tables_CPPFLAGS = \

  test_tables_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_tables_LDADD = \
 libsystemd-logs.la \
 @@ -1973,7 +1979,8 @@ test_cgroup_mask_SOURCES = \
 src/test/test-cgroup-mask.c

  test_cgroup_mask_CPPFLAGS = \
 -   $(AM_CPPFLAGS)
 +   $(AM_CPPFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_cgroup_mask_CFLAGS = \
 $(AM_CFLAGS) \
 @@ -2022,7 +2029,8 @@ test_path_SOURCES = \
 src/test/test-path.c

  test_path_CFLAGS = \
 -   $(AM_CFLAGS)
 +   $(AM_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_path_LDADD = \
 libsystemd-core.la
 @@ -2031,7 +2039,8 @@ test_execute_SOURCES = \
 src/test/test-execute.c

  test_execute_CFLAGS = \
 -   $(AM_CFLAGS)
 +   $(AM_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_execute_LDADD = \
 libsystemd-core.la
 @@ -2061,7 +2070,8 @@ test_sched_prio_SOURCES = \
 src/test/test-sched-prio.c

  test_sched_prio_CPPFLAGS = \
 -   $(AM_CPPFLAGS)
 +   $(AM_CPPFLAGS) \
 +   $(MOUNT_CFLAGS)

  test_sched_prio_CFLAGS = \
 $(AM_CFLAGS) \
 @@ -2133,7 +2143,8 @@ systemd_analyze_SOURCES = \

  systemd_analyze_CFLAGS = \
 $(AM_CFLAGS) \
 -   $(SECCOMP_CFLAGS)
 +   $(SECCOMP_CFLAGS) \
 +   $(MOUNT_CFLAGS)

  systemd_analyze_LDADD = \
 libsystemd-core.la \
 diff --git a/configure.ac b/configure.ac
 index 48cedb5..74ec386 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -454,7 +454,7 @@ AM_CONDITIONAL(HAVE_BLKID, [test $have_blkid = yes])

  # 
 --
  have_libmount=no
 -PKG_CHECK_MODULES(MOUNT, [ mount = 2.20 ],
 +PKG_CHECK_MODULES(MOUNT, [ mount = 2.26 ],
  [AC_DEFINE(HAVE_LIBMOUNT, 1, [Define if libmount is available]) 
 have_libmount=yes], have_libmount=no)
  if test x$have_libmount = xno; then
  AC_MSG_ERROR([*** libmount support required but libraries not found])
 diff --git a/src/core/manager.c b/src/core/manager.c
 index b931b0d..6881bb2 100644
 --- a/src/core/manager.c
 +++ b/src/core/manager.c
 @@ -567,7 +567,7 @@ int manager_new(ManagerRunningAs running_as, bool 
 test_run, Manager **_m) {

  m-idle_pipe[0] = m-idle_pipe[1] = m-idle_pipe[2] = 
 m-idle_pipe[3] = -1;

 -m-pin_cgroupfs_fd = m-notify_fd = m-signal_fd = m-time_change_fd 
 = m-dev_autofs_fd = m-private_listen_fd = m-kdbus_fd = m-utab_inotify_fd 
 = -1;
 +m-pin_cgroupfs_fd = m-notify_fd = m-signal_fd = 

Re: [systemd-devel] udev --daemon is broken again

[Tom Gundersen]

On Sun, May 31, 2015 at 8:45 PM, Abdó Roig-Maranges abdo.r...@gmail.com wrote:

 Andrei Borzenkov writes:

 Was not it fixed by
 693d371d30fee1da58365121801445b404416ada?

 No.

 The first time it broke was due to the udev manager wanting to be used by a
 single process, and was fixed in 040e689654ef08c63.

 Then it broke again by the commit you point 693d371d30fee1da58, due to the 
 fact
 that the sd-event event loop does not like to be passed across forks. This
 breakage still remains in git.

Indeed, I failed at rebasing. Thanks for the report. Will fix!

Cheers,

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

Re: [systemd-devel] udev --daemon is broken again

[Tom Gundersen]

On Sun, May 31, 2015 at 9:45 PM, Tom Gundersen t...@jklm.no wrote:
 On Sun, May 31, 2015 at 8:45 PM, Abdó Roig-Maranges abdo.r...@gmail.com 
 wrote:

 Andrei Borzenkov writes:

 Was not it fixed by
 693d371d30fee1da58365121801445b404416ada?

 No.

 The first time it broke was due to the udev manager wanting to be used by a
 single process, and was fixed in 040e689654ef08c63.

 Then it broke again by the commit you point 693d371d30fee1da58, due to the 
 fact
 that the sd-event event loop does not like to be passed across forks. This
 breakage still remains in git.

This should now be fixed, please let me know if that is not the case.

Cheers,

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

Re: [systemd-devel] Questions about socket activated services

[Tom Gundersen]

On Sat, May 30, 2015 at 3:36 PM, cee1 fykc...@gmail.com wrote:
 Which service type should a socket activated service be?
 1. For systemd-udevd.service and systemd-journald.service, they are notify 
 type
 2. For dbus.service, it is simple type

A service can be of type 'simple' if all that other services care
about that order themselves after it is that the sockets are available
(which they will always be as they are started by PID1 early on).
However, if the service in question does more work at startup that
other services want to wait for, then it needs to be of type 'notify',
and notify PID1 once it is ready. In the case of udev the work it
needs to do at startup is to apply permission to static device nodes
(you want to guarantee that this has finished before starting
follow-up services), if it had not been for that udev too could have
been of type 'simple'.

HTH,

Tom

 Does socket activation handles the timeout case?
 E.g. A.service connects to B.socket, but B.service spends a long time
 to be ready, may cause A.service receives ETIMEDOUT?

 When the service is activated, systemd will still listen to the socket
 but do nothing for incoming data, right?

 BTW, netstat -lp shows only systemd is listening to a socket, but not
 show the one who also is listening to the socket, e.g.
 
 unix  2  [ ACC ] SEQPACKET  LISTENING 326  1/systemd
  /run/udev/control
 
 Curious why?



 --
 Regards,

 - cee1
 ___
 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] 'udevadm settle' brakes lvm on top of imsm raid

[Tom Gundersen]

On Thu, May 28, 2015 at 10:10 AM, Oleg Samarin osamari...@gmail.com wrote:
 Hi!

 I have an imsm raid-1 device /dev/md126 assembled of /dev/sda and /dev/sdb.
 I have a lvm group on top of /dev/md126p2 with some logical volumes. All
 this work fine with Fedora 21.

 I'm trying to fresh install Fedora 22 in some of lvm logical volume. I boot
 with Fedora USB live media and run Install to hard disk. But anaconda does
 not see any existing lvm volumes so I can not choose them as a destination.

 I've created a bug https://bugzilla.redhat.com/show_bug.cgi?id=1178181 on
 this issue.

 After some discovering I found that the reason of this issue is that
 anaconda brakes lvm:

 before launching anaconda pvdisplay reports there are two physical volumes
 /dev/md126p2 and /dev/sdc2 (/dev/sdc is an SSD that does not belong any raid
 and contains a separate lvm volume group)

 after launching anaconda pvdisplay reports another two physical volumes
 /dev/sdb2 and /dev/sdc2, that is wrong, because /dev/sdb is a part of
 /dev/md126 raid.

 journalctl shows:

 May 28 02:44:08 localhost systemd[1]: Stopping LVM2 PV scan on device
 259:1...
 May 28 02:44:08 localhost systemd[1]: Stopped LVM2 PV scan on device 259:1.
 May 28 02:44:08 localhost audit[1]: audit-1131 pid=1 uid=0 auid=4294967295
 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=lvm2-pvscan@259:1
 comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=?
 res=success'
 May 28 02:44:09 localhost kernel:  sde:
 May 28 02:44:09 localhost kernel:  sda: sda1 sda2
 May 28 02:44:09 localhost systemd[1]: Starting LVM2 PV scan on device 8:2...
 May 28 02:44:09 localhost kernel:  sdb: sdb1 sdb2

 Seems lvm stops using /dev/md126p2 and starts using /dev/sdb2 at this moment

 I can see in anaconda program.log that it ran 'udevadm settle' at this
 moment:

 02:44:07,141 INFO program: ...done [9] (exit code: 0)
 02:44:09,290 INFO program: Running... udevadm settle --timeout=300
 02:44:09,305 DEBUG program: Return code: 0
 02:44:09,306 INFO program: Running... udevadm settle --timeout=300
 02:44:09,315 DEBUG program: Return code: 0

 So 'udevadm settle' breaks lvm from using '/dev/md126p2'. Futher lvm rescans
 force it to use /dev/sdb2 instead.

 The attached storage.log contains a trace of udev events of this. All other
 logs are available
 in https://bugzilla.redhat.com/show_bug.cgi?id=1178181

 What is wrong? How to force lvm to use /dev/md126p2 instead of /dev/sdb2
 after starting anaconda?

This seems unlikely to be udevadm settle's fault. All it does is wait
for udev to process events, you may think of it as sleep 5 or
something like that. It can obviously affect the timing of things, but
as Lennart said the underlying problem is surely elsewhere...

Cheers,

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

Re: [systemd-devel] [PATCH] missing: add more IFLA_VXLAN_* defines

[Tom Gundersen]

Applied. Thanks!

Tom

On Tue, May 26, 2015 at 7:48 AM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
 Otherwise building faild with kernel headers  v3.16
 ---
  configure.ac |  2 +-
  src/shared/missing.h | 11 +--
  2 files changed, 10 insertions(+), 3 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 48cedb5ab61a..0818dd80cf0c 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -334,7 +334,7 @@ AC_CHECK_DECLS([IFLA_INET6_ADDR_GEN_MODE,
  IFLA_PHYS_PORT_ID,
  IFLA_BOND_AD_INFO,
  IFLA_VLAN_PROTOCOL,
 -IFLA_VXLAN_LOCAL6,
 +IFLA_VXLAN_REMCSUM_NOPARTIAL,
  IFLA_IPTUN_6RD_RELAY_PREFIXLEN,
  IFLA_BRIDGE_VLAN_INFO,
  IFLA_BRPORT_UNICAST_FLOOD,
 diff --git a/src/shared/missing.h b/src/shared/missing.h
 index 8ca6f8edb62c..919400949138 100644
 --- a/src/shared/missing.h
 +++ b/src/shared/missing.h
 @@ -713,7 +713,7 @@ static inline int setns(int fd, int nstype) {
  #define IFLA_VLAN_MAX   (__IFLA_VLAN_MAX - 1)
  #endif

 -#if !HAVE_DECL_IFLA_VXLAN_LOCAL6
 +#if !HAVE_DECL_IFLA_VXLAN_REMCSUM_NOPARTIAL
  #define IFLA_VXLAN_UNSPEC 0
  #define IFLA_VXLAN_ID 1
  #define IFLA_VXLAN_GROUP 2
 @@ -732,7 +732,14 @@ static inline int setns(int fd, int nstype) {
  #define IFLA_VXLAN_PORT 15
  #define IFLA_VXLAN_GROUP6 16
  #define IFLA_VXLAN_LOCAL6 17
 -#define __IFLA_VXLAN_MAX 18
 +#define IFLA_VXLAN_UDP_CSUM 18
 +#define IFLA_VXLAN_UDP_ZERO_CSUM6_TX 19
 +#define IFLA_VXLAN_UDP_ZERO_CSUM6_RX 20
 +#define IFLA_VXLAN_REMCSUM_TX 21
 +#define IFLA_VXLAN_REMCSUM_RX 22
 +#define IFLA_VXLAN_GBP 23
 +#define IFLA_VXLAN_REMCSUM_NOPARTIAL 24
 +#define __IFLA_VXLAN_MAX 25

  #define IFLA_VXLAN_MAX  (__IFLA_VXLAN_MAX - 1)
  #endif
 --
 2.1.4

 ___
 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] Adding additional network interfaces dynamically, after networkd startup finishes

[Tom Gundersen]

On Wed, May 27, 2015 at 2:03 PM, Peter Lemenkov lemen...@gmail.com wrote:
 Hello All!
 My network is managed via systemd-networkd. I'm trying to create
 additional network bridge after another one service (VPN) is started.

 Right now I'm having a ExecStartPost directive, which creates
 /run/systemd/network, creates a necessary netdev/link/network files
 here, and restarts networkd (/bin/systemctl restart
 systemd-networkd.service).

 I wonder if it's a correct way to dynamically create network
 interfaces? Is it possible to ask networkd to re-read its
 configuration w/o restarting? Maybe D-Bus commands or something?

There is no correct way of doing this at the moment. It is next on my
list of features to work on.

Cheers,

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

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 5:11 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers to 
 finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent changes
 in udev around this commit, but any version before that commit is fast
 and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

It appears a few people see this, but I was not able to reproduce. If
anyone could reproduce with this patch applied [0], it would be most
helpful (and post the output of journalctl -b -u systemd-udevd).

Cheers,

Tom

[0]: http://paste.fedoraproject.org/226122/74140114/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Wed, May 27, 2015 at 6:16 PM, Filipe Brandenburger
filbran...@google.com wrote:
 Hi Tom,

 On Wed, May 27, 2015 at 8:45 AM, Tom Gundersen t...@jklm.no wrote:
 It appears a few people see this, but I was not able to reproduce. If
 anyone could reproduce with this patch applied [0], it would be most
 helpful (and post the output of journalctl -b -u systemd-udevd).

 Done.

 Console output from udev in initramfs:
 http://paste.fedoraproject.org/226145/43216143/

 And the output of the journalctl command you asked:
 http://paste.fedoraproject.org/226146/43274324/

 I have this on Arch Linux with mkinitcpio. Using latest systemd from
 git plus your patch.

Thanks, that explains it (and teaches me how to reproduce)!

Cheers,

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

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Wed, May 27, 2015 at 6:23 PM, Tom Gundersen t...@jklm.no wrote:
 On Wed, May 27, 2015 at 6:16 PM, Filipe Brandenburger
 filbran...@google.com wrote:
 Hi Tom,

 On Wed, May 27, 2015 at 8:45 AM, Tom Gundersen t...@jklm.no wrote:
 It appears a few people see this, but I was not able to reproduce. If
 anyone could reproduce with this patch applied [0], it would be most
 helpful (and post the output of journalctl -b -u systemd-udevd).

 Done.

 Console output from udev in initramfs:
 http://paste.fedoraproject.org/226145/43216143/

 And the output of the journalctl command you asked:
 http://paste.fedoraproject.org/226146/43274324/

 I have this on Arch Linux with mkinitcpio. Using latest systemd from
 git plus your patch.

 Thanks, that explains it (and teaches me how to reproduce)!

This should be fixed by 86c3bece38bcf55da6387d20c6f01da9ad0284dc.
Thanks for the help in debugging this, and sorry for the
inconvenience.

Cheers,

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

Re: [systemd-devel] [PATCH] fix extraneous space in equality check

[Tom Gundersen]

Applied. Thanks!

Tom

On Wed, May 27, 2015 at 9:02 PM, Jonathan Boulle
jonathan.bou...@coreos.com wrote:
 ---
  src/core/main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/core/main.c b/src/core/main.c
 index c39815b10675..212ab901b18f 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1496,7 +1496,7 @@ int main(int argc, char *argv[]) {
  setsid();

  /* Move out of the way, so that we won't block unmounts */
 -assert_se(chdir(/)  == 0);
 +assert_se(chdir(/) == 0);

  /* Reset the console, but only if this is really init and we
   * are freshly booted */
 --
 1.9.3

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

Re: [systemd-devel] [PATCH] Fix systemd.resource-control(5) volume number.

[Tom Gundersen]

On Wed, May 27, 2015 at 9:47 PM, Patrick Donnelly batr...@batbytes.com wrote:
 Signed-off-by: Patrick Donnelly batr...@batbytes.com

We don't use s-o-b in systemd, so dropped this when applying. Also
adjusted the subject line a bit (for future reference).

Thanks for the patch! Pushed.

Cheers,

Tom
 ---
  man/systemd.slice.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml
 index f0bac41..a501327 100644
 --- a/man/systemd.slice.xml
 +++ b/man/systemd.slice.xml
 @@ -90,7 +90,7 @@
  slice specific configuration options are configured in
  the [Slice] section. Currently, only generic resource control settings
  as described in
 -
 citerefentryrefentrytitlesystemd.resource-control/refentrytitlemanvolnum7/manvolnum/citerefentry
  are allowed.
 +
 citerefentryrefentrytitlesystemd.resource-control/refentrytitlemanvolnum5/manvolnum/citerefentry
  are allowed.
  /para

  paraUnless varnameDefaultDependencies=false/varname
 --
 Patrick Donnelly

 ___
 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] crda broken with systemd 220

[Tom Gundersen]

On Tue, May 26, 2015 at 11:53 AM, Michał Bartoszkiewicz
mbartoszkiew...@gmail.com wrote:
 Hello,

 it seems that udev from systemd 220 does passes empty environment to a
 process spawned by a RUN rule.
 execve(/usr/sbin/crda, [/usr/sbin/crda], [/* 0 vars */]) = 0
 This breaks crda, as it expects to see COUNTRY in its environment.

Thanks for the report! This should now be fixed in git. Let me know if
that is not the case.

Cheers,

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

Re: [systemd-devel] [PATCH] treewide: fix typos

[Tom Gundersen]

Applied. Thanks!

Tom

On Tue, May 26, 2015 at 7:17 PM, Torstein Husebø torst...@huseboe.net wrote:
 ---
  NEWS| 4 ++--
  man/journal-remote.conf.xml | 2 +-
  src/libsystemd/sd-bus/bus-control.c | 2 +-
  src/libsystemd/sd-bus/bus-creds.c   | 6 +++---
  src/shared/architecture.c   | 2 +-
  src/shared/architecture.h   | 2 +-
  src/shared/capability.h | 2 +-
  src/shared/fdset.c  | 2 +-
  src/shared/util.c   | 2 +-
  9 files changed, 12 insertions(+), 12 deletions(-)

 diff --git a/NEWS b/NEWS
 index f72f502129..ee533b4363 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -3997,7 +3997,7 @@ CHANGES WITH 191:
  * HandleSleepKey= in logind.conf has been split up into
HandleSuspendKey= and HandleHibernateKey=. The old setting
is not available anymore. X11 and the kernel are
 -  distuingishing between these keys and we should too. This
 +  distinguishing between these keys and we should too. This
also means the inhibition lock for these keys has been split
into two.

 @@ -4743,7 +4743,7 @@ CHANGES WITH 43:

  * Various functionality updates to libsystemd-login.so

 -* Track class of PAM logins to distuingish greeters from
 +* Track class of PAM logins to distinguish greeters from
normal user logins.

  Contributions from: Kay Sievers, Lennart Poettering, Michael
 diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
 index a7b2227182..fc60258d0b 100644
 --- a/man/journal-remote.conf.xml
 +++ b/man/journal-remote.conf.xml
 @@ -83,7 +83,7 @@
varlistentry
  termvarnameServerKeyFile=/varname/term

 -listitemparaSSL key in PEM format/para/listitem
 +listitemparaSSL key in PEM format./para/listitem
/varlistentry

varlistentry
 diff --git a/src/libsystemd/sd-bus/bus-control.c 
 b/src/libsystemd/sd-bus/bus-control.c
 index fa4c28174d..43ddfc651d 100644
 --- a/src/libsystemd/sd-bus/bus-control.c
 +++ b/src/libsystemd/sd-bus/bus-control.c
 @@ -429,7 +429,7 @@ static int bus_populate_creds_from_items(
  c-mask |= SD_BUS_CREDS_PPID;
  } else if (item-pids.pid == 1) {
  /* The structure doesn't
 - * really distuingish the case
 + * really distinguish the case
   * where a process has no
   * parent and where we don't
   * know it because it could
 diff --git a/src/libsystemd/sd-bus/bus-creds.c 
 b/src/libsystemd/sd-bus/bus-creds.c
 index fed66823c7..4d67619cf8 100644
 --- a/src/libsystemd/sd-bus/bus-creds.c
 +++ b/src/libsystemd/sd-bus/bus-creds.c
 @@ -303,7 +303,7 @@ _public_ int sd_bus_creds_get_ppid(sd_bus_creds *c, pid_t 
 *ppid) {
  if (!(c-mask  SD_BUS_CREDS_PPID))
  return -ENODATA;

 -/* PID 1 has no parent process. Let's distuingish the case of
 +/* PID 1 has no parent process. Let's distinguish the case of
   * not knowing and not having a parent process by the returned
   * error code. */
  if (c-ppid == 0)
 @@ -989,7 +989,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
 pid_t pid, pid_t tid) {
  if (missing  SD_BUS_CREDS_EXE) {
  r = get_process_exe(pid, c-exe);
  if (r == -ESRCH) {
 -/* Unfortunately we cannot really distuingish
 +/* Unfortunately we cannot really distinguish
   * the case here where the process does not
   * exist, and /proc/$PID/exe being unreadable
   * because $PID is a kernel thread. Hence,
 @@ -1101,7 +1101,7 @@ int bus_creds_add_more(sd_bus_creds *c, uint64_t mask, 
 pid_t pid, pid_t tid) {
  }

  /* In case only the exe path was to be read we cannot
 - * distuingish the case where the exe path was unreadable
 + * distinguish the case where the exe path was unreadable
   * because the process was a kernel thread, or when the
   * process didn't exist at all. Hence, let's do a final check,
   * to be sure. */
 diff --git a/src/shared/architecture.c b/src/shared/architecture.c
 index 884abdd3ea..8e72e7a36a 100644
 --- a/src/shared/architecture.c
 +++ b/src/shared/architecture.c
 @@ -35,7 +35,7 @@ int uname_architecture(void) {
   * 1:1. Instead we try to clean it up and break down the
   * confusion on x86 and arm in particular.
   *
 - * We do not try to distuingish CPUs not CPU features, but
 + * We do not try to distinguish CPUs not CPU features, but
   * actual architectures, i.e. that 

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 5:11 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers to 
 finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent changes
 in udev around this commit, but any version before that commit is fast
 and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

FWIW, I'm looking into this.

Cheers,

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

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 9:04 PM, Christian Hesse l...@eworm.de wrote:
 Martin Pitt martin.p...@ubuntu.com on Tue, 2015/05/26 17:11:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
 to finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent
 changes in udev around this commit, but any version before that commit is
 fast and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

 I do see this as well. And probably we have an upstream bug [0] already.

 Wondering whether or not my report about inotify_add_watch() failed: Bad
 file descriptor [1] is related. Do you see that as well?
 BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
 udev_watch.c?

This is unrelated.

Cheers,

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

Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish

[Tom Gundersen]

On Tue, May 26, 2015 at 9:04 PM, Christian Hesse l...@eworm.de wrote:
 Martin Pitt martin.p...@ubuntu.com on Tue, 2015/05/26 17:11:
 Hello Tom, all,

 with 220 I get a severe boot time regression:

   $ systemd-analyze
   Startup finished in 30.751s (kernel) + 11.706s (userspace) = 42.458s

 which used to be

   $ systemd-analyze
   Startup finished in 703ms (kernel) + 890ms (userspace) = 1.593s

 (this is a VM)

 It seems udevd --daemon spends 30 seconds timing out in the initramfs:

   [0.384519] systemd-udevd[55]: starting version 220
   [   30.736381] systemd-udevd[56]: timeout, giving up waiting for workers
 to finish

 and then some more in the real root:

$ systemd-analyze blame
  10.826s dev-vda1.device
  10.067s systemd-tmpfiles-setup-dev.service
  10.031s systemd-sysctl.service
  10.019s systemd-journald.service
  10.005s sys-fs-fuse-connections.mount
  10.001s tmp.mount

 (full journal at http://paste.ubuntu.com/11372265/, but it's not very
 useful)

 I bisected this to

   http://cgit.freedesktop.org/systemd/systemd/commit/?id=e237d8c
   udevd: move file descriptors to Manager

 this is hard to revert individually as there are lots of other recent
 changes in udev around this commit, but any version before that commit is
 fast and doesn't give that timeout error.

 Current trunk as of commit 185abfc3 still has that problem, so it
 wasn't fixed by one of the recent udev commits.

 Does anyone else see this too? Any idea what causes this?

 I do see this as well. And probably we have an upstream bug [0] already.

Oh, and this bug report is probably unrelated. It is an old one (that
I could never reproduce), and the relevant parts were reworked
(probably causing the current issues).

-t

 Wondering whether or not my report about inotify_add_watch() failed: Bad
 file descriptor [1] is related. Do you see that as well?
 BTW, is it expected to have fd_inotify in udevd.c and inotify_fd in
 udev_watch.c?

 [0] https://bugs.freedesktop.org/show_bug.cgi?id=90051
 [1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032213.html
 --
 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);}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] inotify_add_watch() failed: Bad file descriptor

[Tom Gundersen]

On Tue, May 26, 2015 at 10:14 AM, Christian Hesse l...@eworm.de wrote:
 Hello everybody,

 with systemd v220 I see inotify errors from udevd. I get this once:

 systemd-udevd: inotify_add_watch(9, /dev/sr0, 10) failed: Bad file descriptor

 And a lot of these:

 systemd-udevd: inotify_add_watch(9, /dev/dm-[0-9]+, 10) failed: Bad file
 descriptor

This was fixed by David in 185abfc3d6b4e8f804a3f7216cd8b0459593af87.

Cheers,

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

Re: [systemd-devel] [PATCH 1/2] build-sys: always include src/boot/efi in tarballs

[Tom Gundersen]

Applied. Thanks!

Tom

On Mon, May 25, 2015 at 11:18 AM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 currently it would only be included if configure was ran with --enable-gnuefi
 ---
  Makefile.am | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 70d4dc0..9420879 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -2601,6 +2601,8 @@ EFI_FORMAT = -O binary
  else
  EFI_FORMAT = --target=efi-app-$(EFI_ARCH)
  endif
 +endif
 +endif

  # 
 --
  systemd_boot_headers = \
 @@ -2616,13 +2618,16 @@ systemd_boot_sources = \
 src/boot/efi/pefile.c \
 src/boot/efi/boot.c

 +EXTRA_DIST += $(systemd_boot_sources) $(systemd_boot_headers)
 +
 +if ENABLE_EFI
 +if HAVE_GNUEFI
  systemd_boot_objects = $(addprefix 
 $(top_builddir)/,$(systemd_boot_sources:.c=.o))
  systemd_boot_solib = $(top_builddir)/src/boot/efi/systemd_boot.so
  systemd_boot = systemd-boot$(EFI_MACHINE_TYPE_NAME).efi

  bootlib_DATA = $(systemd_boot)
  CLEANFILES += $(systemd_boot_objects) $(systemd_boot_solib) $(systemd_boot)
 -EXTRA_DIST += $(systemd_boot_sources) $(systemd_boot_headers)

  $(top_builddir)/src/boot/efi/%.o: $(top_srcdir)/src/boot/efi/%.c $(addprefix 
 $(top_srcdir)/,$(systemd_boot_headers))
 @$(MKDIR_P) $(top_builddir)/src/boot/efi/
 @@ -2636,6 +2641,8 @@ $(systemd_boot_solib): $(systemd_boot_objects)
  $(systemd_boot): $(systemd_boot_solib)
 $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc $(EFI_FORMAT) $ $@
 +endif
 +endif

  # 
 --
  stub_headers = \
 @@ -2653,13 +2660,16 @@ stub_sources = \
 src/boot/efi/linux.c \
 src/boot/efi/stub.c

 +EXTRA_DIST += $(stub_sources) $(stub_headers)
 +
 +if ENABLE_EFI
 +if HAVE_GNUEFI
  stub_objects = $(addprefix $(top_builddir)/,$(stub_sources:.c=.o))
  stub_solib = $(top_builddir)/src/boot/efi/stub.so
  stub = linux$(EFI_MACHINE_TYPE_NAME).efi.stub

  bootlib_DATA += $(stub)
  CLEANFILES += $(stub_objects) $(stub_solib) $(stub)
 -EXTRA_DIST += $(stub_sources) $(stub_headers)

  $(top_builddir)/src/boot/efi/%.o: $(top_srcdir)/src/boot/efi/%.c $(addprefix 
 $(top_srcdir)/,$(stub_headers))
 @$(MKDIR_P) $(top_builddir)/src/boot/efi/
 --
 2.4.1

 ___
 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] swap: use swapon -o

[Tom Gundersen]

Applied. Thanks!

Tom

On Mon, May 25, 2015 at 12:11 PM, Karel Zak k...@redhat.com wrote:
 This patch simplify swapon usage in systemd. The command swapon(8)
 since util-linux v2.26 supports -o list. The idea is exactly the
 same like for mount(8). The -o specifies options in fstab-compatible
 way. For systemd it means that it does not have to care about things
 like discard or another swapon specific options.

 swapon -o options-from-fstab

 For backward compatibility the code cares about Priority: swap unit
 field (for a case when Priority: is set, but pri= in the Options: is
 missing).

 References: 
 http://lists.freedesktop.org/archives/systemd-devel/2014-October/023576.html
 ---
 V2:
  - update README
  - add hint to systemd.swap man page
  - don't care about pri= in systed-fstab-generator at all
  - add warning about duplicate priority configuration
  - use warning rather than notice for non-parsable pri=

  README|  2 +-
  man/systemd.swap.xml  |  3 ++-
  src/core/swap.c   | 43 
 +++
  src/fstab-generator/fstab-generator.c | 28 ---
  4 files changed, 26 insertions(+), 50 deletions(-)

 diff --git a/README b/README
 index 039110e..2b8c68e 100644
 --- a/README
 +++ b/README
 @@ -136,7 +136,7 @@ REQUIREMENTS:
  During runtime, you need the following additional
  dependencies:

 -util-linux = v2.25 required
 +util-linux = v2.26 required
  dbus = 1.4.0 (strictly speaking optional, but recommended)
  dracut (optional)
  PolicyKit (optional)
 diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml
 index 5016f45..c398677 100644
 --- a/man/systemd.swap.xml
 +++ b/man/systemd.swap.xml
 @@ -177,7 +177,8 @@

  listitemparaSwap priority to use when activating the swap
  device or file. This takes an integer. This setting is
 -optional./para/listitem
 +optional and ignored when priotiry is set by optionpri=/option 
 in the
 +varnameOptions=/varname option./para/listitem
/varlistentry

varlistentry
 diff --git a/src/core/swap.c b/src/core/swap.c
 index 12ebf84..193c8c3 100644
 --- a/src/core/swap.c
 +++ b/src/core/swap.c
 @@ -717,8 +717,8 @@ fail:
  }

  static void swap_enter_activating(Swap *s) {
 -_cleanup_free_ char *discard = NULL;
 -int r, priority = -1;
 +_cleanup_free_ char *opts = NULL;
 +int r;

  assert(s);

 @@ -726,13 +726,21 @@ static void swap_enter_activating(Swap *s) {
  s-control_command = s-exec_command + SWAP_EXEC_ACTIVATE;

  if (s-from_fragment) {
 -fstab_filter_options(s-parameters_fragment.options, 
 discard\0, NULL, discard, NULL);
 +int priority = -1;

 -priority = s-parameters_fragment.priority;
 -if (priority  0) {
 -r = fstab_find_pri(s-parameters_fragment.options, 
 priority);
 +r = fstab_find_pri(s-parameters_fragment.options, 
 priority);
 +if (r  0)
 +log_warning_errno(r, Failed to parse swap priority 
 \%s\, ignoring: %m, s-parameters_fragment.options);
 +else if (r == 1  s-parameters_fragment.priority = 0)
 +log_warning(Duplicate swap priority configuration 
 by Priority and Options fields.);
 +
 +if (r = 0  s-parameters_fragment.priority = 0) {
 +if (s-parameters_fragment.options)
 +r = asprintf(opts, %s,pri=%i, 
 s-parameters_fragment.options, s-parameters_fragment.priority);
 +else
 +r = asprintf(opts, pri=%i, 
 s-parameters_fragment.priority);
  if (r  0)
 -log_notice_errno(r, Failed to parse swap 
 priority \%s\, ignoring: %m, s-parameters_fragment.options);
 +goto fail;
  }
  }

 @@ -740,24 +748,9 @@ static void swap_enter_activating(Swap *s) {
  if (r  0)
  goto fail;

 -if (priority = 0) {
 -char p[DECIMAL_STR_MAX(int)];
 -
 -sprintf(p, %i, priority);
 -r = exec_command_append(s-control_command, -p, p, NULL);
 -if (r  0)
 -goto fail;
 -}
 -
 -if (discard  !streq(discard, none)) {
 -const char *discard_arg;
 -
 -if (streq(discard, all))
 -discard_arg = --discard;
 -else
 -discard_arg = strjoina(--discard=, discard);
 -
 -r = exec_command_append(s-control_command, discard_arg, 
 NULL);
 +if (s-parameters_fragment.options || opts) {
 +r = exec_command_append(s-control_command, -o,
 +

Re: [systemd-devel] [PATCH 2/2] build-sys: don't dist generated files

[Tom Gundersen]

Applied, with minor fix. Please verify that it still works for you!

Tom

On Mon, May 25, 2015 at 11:18 AM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 ---
  Makefile.am | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 9420879..4933e6f 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -1259,8 +1259,7 @@ DISTCLEANFILES = \

  EXTRA_DIST += \
 $(gperf_gperf_m4_sources) \
 -   $(gperf_gperf_sources) \
 -   $(gperf_txt_sources:-list.txt=-from-name.gperf)
 +   $(gperf_gperf_sources)

  CLEANFILES += \
 $(gperf_txt_sources)
 @@ -4652,7 +4651,9 @@ libsystemd_journal_internal_la_SOURCES = \
 src/journal/mmap-cache.h \
 src/journal/compress.c \
 src/journal/audit-type.h \
 -   src/journal/audit-type.c \
 +   src/journal/audit-type.c
 +
 +nodist_libsystemd_journal_internal_la_SOURCES = \
 src/journal/audit_type-to-name.h

  gperf_txt_sources += \
 @@ -5665,7 +5666,9 @@ systemd_resolved_SOURCES = \
 src/resolve/resolved-dns-stream.h \
 src/resolve/resolved-dns-stream.c \
 src/resolve/dns-type.c \
 -   src/resolve/dns-type.h \
 +   src/resolve/dns-type.h
 +
 +nodist_systemd_resolved_SOURCES = \
 src/resolve/dns_type-from-name.h \
 src/resolve/dns_type-to-name.h

 @@ -5766,7 +5769,9 @@ systemd_resolve_host_SOURCES = \
 src/resolve/resolved-dns-domain.c \
 src/resolve/resolved-dns-domain.h \
 src/resolve/dns-type.c \
 -   src/resolve/dns-type.h \
 +   src/resolve/dns-type.h
 +
 +nodist_systemd_resolve_host_SOURCES = \
 src/resolve/dns_type-from-name.h \
 src/resolve/dns_type-to-name.h

 --
 2.4.1

 ___
 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] build-sys: fix headers installation

[Tom Gundersen]

Applied. Thanks!

Tom

On Mon, May 25, 2015 at 1:35 PM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 ---
  Makefile.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/Makefile.am b/Makefile.am
 index 4933e6f..8e38010 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3128,7 +3128,7 @@ pkginclude_HEADERS += \
 src/systemd/sd-bus.h \
 src/systemd/sd-bus-protocol.h \
 src/systemd/sd-bus-vtable.h \
 -   src/systemd/sd-event.h
 +   src/systemd/sd-event.h \
 src/systemd/sd-login.h \
 src/systemd/sd-id128.h \
 src/systemd/sd-daemon.h
 --
 2.4.1

 ___
 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 6/6] udevd: event - port spawn_wait() to sd-event

[Tom Gundersen]

This allows us to drop the special sigterm handling in spawn_wait()
as this will now be passed directly to the worker event loop.

We now log failing processe at 'warning' leve, otherwise the
behavior is unchanged.
---
 src/test/test-udev.c|   7 --
 src/udev/udev-event.c   | 177 +---
 src/udev/udev.h |   2 -
 src/udev/udevadm-test.c |   8 ---
 src/udev/udevd.c|   8 ---
 5 files changed, 94 insertions(+), 108 deletions(-)

diff --git a/src/test/test-udev.c b/src/test/test-udev.c
index 23b7faa..f3953fe 100644
--- a/src/test/test-udev.c
+++ b/src/test/test-udev.c
@@ -120,11 +120,6 @@ int main(int argc, char *argv[]) {
 
 sigfillset(mask);
 sigprocmask(SIG_SETMASK, mask, sigmask_orig);
-event-fd_signal = signalfd(-1, mask, SFD_NONBLOCK|SFD_CLOEXEC);
-if (event-fd_signal  0) {
-fprintf(stderr, error creating signalfd\n);
-goto out;
-}
 
 /* do what devtmpfs usually provides us */
 if (udev_device_get_devnode(dev) != NULL) {
@@ -153,8 +148,6 @@ int main(int argc, char *argv[]) {
3 * USEC_PER_SEC, USEC_PER_SEC,
NULL);
 out:
-if (event != NULL  event-fd_signal = 0)
-close(event-fd_signal);
 mac_selinux_finish();
 
 return err ? EXIT_FAILURE : EXIT_SUCCESS;
diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c
index 2fa26a4..b8c79b1 100644
--- a/src/udev/udev-event.c
+++ b/src/udev/udev-event.c
@@ -32,7 +32,14 @@
 
 #include udev.h
 #include rtnl-util.h
+#include event-util.h
 #include formats-util.h
+#include process-util.h
+
+typedef struct Spawn {
+const char *cmd;
+pid_t pid;
+} Spawn;
 
 struct udev_event *udev_event_new(struct udev_device *dev) {
 struct udev *udev = udev_device_get_udev(dev);
@@ -45,7 +52,6 @@ struct udev_event *udev_event_new(struct udev_device *dev) {
 event-udev = udev;
 udev_list_init(udev, event-run_list, false);
 udev_list_init(udev, event-seclabel_list, false);
-event-fd_signal = -1;
 event-birth_usec = now(CLOCK_MONOTONIC);
 return event;
 }
@@ -540,102 +546,107 @@ static void spawn_read(struct udev_event *event,
 result[respos] = '\0';
 }
 
-static int spawn_wait(struct udev_event *event,
-  usec_t timeout_usec,
-  usec_t timeout_warn_usec,
-  const char *cmd, pid_t pid) {
-struct pollfd pfd[1];
-int err = 0;
+static int on_spawn_timeout(sd_event_source *s, uint64_t usec, void *userdata) 
{
+Spawn *spawn = userdata;
 
-pfd[0].events = POLLIN;
-pfd[0].fd = event-fd_signal;
+assert(spawn);
 
-while (pid  0) {
-int timeout;
-int timeout_warn = 0;
-int fdcount;
+kill_and_sigcont(spawn-pid, SIGKILL);
 
-if (timeout_usec  0) {
-usec_t age_usec;
+log_error(timeout: '%s' [PID_FMT], killing, spawn-cmd, 
spawn-pid);
 
-age_usec = now(CLOCK_MONOTONIC) - event-birth_usec;
-if (age_usec = timeout_usec)
-timeout = 1000;
-else {
-if (timeout_warn_usec  0)
-timeout_warn = ((timeout_warn_usec - 
age_usec) / USEC_PER_MSEC) + MSEC_PER_SEC;
+return 1;
+}
 
-timeout = ((timeout_usec - timeout_warn_usec - 
age_usec) / USEC_PER_MSEC) + MSEC_PER_SEC;
-}
-} else {
-timeout = -1;
-}
+static int on_spawn_timeout_warning(sd_event_source *s, uint64_t usec, void 
*userdata) {
+Spawn *spawn = userdata;
 
-fdcount = poll(pfd, 1, timeout_warn);
-if (fdcount  0) {
-if (errno == EINTR)
-continue;
-err = -errno;
-log_error_errno(errno, failed to poll: %m);
-goto out;
-}
-if (fdcount == 0) {
-log_warning(slow: '%s' [PID_FMT], cmd, pid);
+assert(spawn);
 
-fdcount = poll(pfd, 1, timeout);
-if (fdcount  0) {
-if (errno == EINTR)
-continue;
-err = -errno;
-log_error_errno(errno, failed to poll: %m);
-goto out;
-}
-if (fdcount == 0) {
-log_error(timeout: killing '%s' [PID_FMT], 
cmd, pid);
-kill(pid, SIGKILL);
-  

[systemd-devel] [PATCH 1/6] udevd: introduce manager_exit() and manager_reload()

[Tom Gundersen]

The behavior is mostly unchanged, but rather than only ever calling these 
functions at
fixed points in the event loop, they are called directly whenever they are 
invoked.
---
 src/udev/udevd.c | 80 +++-
 1 file changed, 44 insertions(+), 36 deletions(-)

diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index b33a262..91fe3d9 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -690,6 +690,43 @@ static bool is_devpath_busy(Manager *manager, struct event 
*event) {
 return false;
 }
 
+static void manager_exit(Manager *manager) {
+
+assert(manager);
+
+manager-exit = true;
+
+/* close sources of new events and discard buffered events */
+if (manager-fd_ctrl = 0) {
+epoll_ctl(manager-fd_ep, EPOLL_CTL_DEL, manager-fd_ctrl, 
NULL);
+manager-fd_ctrl = safe_close(manager-fd_ctrl);
+}
+
+if (manager-monitor) {
+epoll_ctl(manager-fd_ep, EPOLL_CTL_DEL, manager-fd_uevent, 
NULL);
+manager-monitor = udev_monitor_unref(manager-monitor);
+}
+
+if (manager-fd_inotify = 0) {
+epoll_ctl(manager-fd_ep, EPOLL_CTL_DEL, manager-fd_inotify, 
NULL);
+manager-fd_inotify = safe_close(manager-fd_inotify);
+}
+
+/* discard queued events and kill workers */
+event_queue_cleanup(manager, EVENT_QUEUED);
+manager_kill_workers(manager);
+}
+
+/* reload requested, HUP signal received, rules changed, builtin changed */
+static void manager_reload(Manager *manager) {
+
+assert(manager);
+
+manager_kill_workers(manager);
+manager-rules = udev_rules_unref(manager-rules);
+udev_builtin_exit(manager-udev);
+}
+
 static void event_queue_start(Manager *manager) {
 struct udev_list_node *loop;
 
@@ -846,7 +883,7 @@ static int on_ctrl_msg(sd_event_source *s, int fd, uint32_t 
revents, void *userd
 
 if (udev_ctrl_get_reload(ctrl_msg)  0) {
 log_debug(udevd message (RELOAD) received);
-manager-reload = true;
+manager_reload(manager);
 }
 
 str = udev_ctrl_get_set_env(ctrl_msg);
@@ -885,7 +922,7 @@ static int on_ctrl_msg(sd_event_source *s, int fd, uint32_t 
revents, void *userd
 
 if (udev_ctrl_get_exit(ctrl_msg)  0) {
 log_debug(udevd message (EXIT) received);
-manager-exit = true;
+manager_exit(manager);
 /* keep reference to block the client until we exit
TODO: deal with several blocking exit requests */
 manager-ctrl_conn_blocking = 
udev_ctrl_connection_ref(ctrl_conn);
@@ -1043,7 +1080,7 @@ static int on_sigterm(sd_event_source *s, const struct 
signalfd_siginfo *si, voi
 
 assert(manager);
 
-manager-exit = true;
+manager_exit(manager);
 
 return 1;
 }
@@ -1053,7 +1090,7 @@ static int on_sighup(sd_event_source *s, const struct 
signalfd_siginfo *si, void
 
 assert(manager);
 
-manager-reload = true;
+manager_reload(manager);
 
 return 1;
 }
@@ -1528,26 +1565,6 @@ int main(int argc, char *argv[]) {
 int i;
 
 if (manager-exit) {
-/* close sources of new events and discard buffered 
events */
-if (manager-fd_ctrl = 0) {
-epoll_ctl(manager-fd_ep, EPOLL_CTL_DEL, 
manager-fd_ctrl, NULL);
-manager-fd_ctrl = 
safe_close(manager-fd_ctrl);
-}
-
-if (manager-monitor) {
-epoll_ctl(manager-fd_ep, EPOLL_CTL_DEL, 
manager-fd_uevent, NULL);
-manager-monitor = 
udev_monitor_unref(manager-monitor);
-}
-
-if (manager-fd_inotify = 0) {
-epoll_ctl(manager-fd_ep, EPOLL_CTL_DEL, 
manager-fd_inotify, NULL);
-manager-fd_inotify = 
safe_close(manager-fd_inotify);
-}
-
-/* discard queued events and kill workers */
-event_queue_cleanup(manager, EVENT_QUEUED);
-manager_kill_workers(manager);
-
 /* exit after all has cleaned up */
 if (udev_list_node_is_empty(manager-events)  
hashmap_isempty(manager-workers))
 break;
@@ -1626,22 +1643,13 @@ int main(int argc, char *argv[]) {
 
 /* check for changed config, every 3 seconds at most */
 if ((now(CLOCK_MONOTONIC) - last_usec)  3 * USEC_PER_SEC) {
-if (udev_rules_check_timestamp(manager-rules))
-manager-reload = true;
-if 

[systemd-devel] [PATCH 2/6] udevd: only check for changed config before scheduling new events

[Tom Gundersen]

Also move builtin and rules initialization from main loop to
event_queue_start().

No functional change.
---
 src/udev/udevd.c | 42 +-
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 91fe3d9..e309def 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -83,6 +83,8 @@ typedef struct Manager {
 int fd_worker;
 int worker_watch[2];
 
+usec_t last_usec;
+
 bool stop_exec_queue:1;
 bool reload:1;
 bool exit:1;
@@ -732,6 +734,28 @@ static void event_queue_start(Manager *manager) {
 
 assert(manager);
 
+if (udev_list_node_is_empty(manager-events) ||
+manager-exit || manager-stop_exec_queue)
+return;
+
+/* check for changed config, every 3 seconds at most */
+if (manager-last_usec == 0 ||
+(now(CLOCK_MONOTONIC) - manager-last_usec)  3 * USEC_PER_SEC) {
+if (udev_rules_check_timestamp(manager-rules) ||
+udev_builtin_validate(manager-udev))
+manager_reload(manager);
+
+manager-last_usec = now(CLOCK_MONOTONIC);
+}
+
+udev_builtin_init(manager-udev);
+
+if (!manager-rules) {
+manager-rules = udev_rules_new(manager-udev, 
arg_resolve_names);
+if (!manager-rules)
+return;
+}
+
 udev_list_node_foreach(loop, manager-events) {
 struct event *event = node_to_event(loop);
 
@@ -1557,7 +1581,6 @@ int main(int argc, char *argv[]) {
 sd_notify(1, READY=1);
 
 for (;;) {
-static usec_t last_usec;
 struct epoll_event ev[8];
 int fdcount;
 int timeout;
@@ -1641,15 +1664,6 @@ int main(int argc, char *argv[]) {
 is_ctrl = true;
 }
 
-/* check for changed config, every 3 seconds at most */
-if ((now(CLOCK_MONOTONIC) - last_usec)  3 * USEC_PER_SEC) {
-if (udev_rules_check_timestamp(manager-rules) ||
-udev_builtin_validate(manager-udev))
-manager_reload(manager);
-
-last_usec = now(CLOCK_MONOTONIC);
-}
-
 /* event has finished */
 if (is_worker)
 on_worker(NULL, manager-fd_worker, 0, manager);
@@ -1659,13 +1673,7 @@ int main(int argc, char *argv[]) {
 on_uevent(NULL, manager-fd_uevent, 0, manager);
 
 /* start new events */
-if (!udev_list_node_is_empty(manager-events)  
!manager-exit  !manager-stop_exec_queue) {
-udev_builtin_init(manager-udev);
-if (!manager-rules)
-manager-rules = udev_rules_new(manager-udev, 
arg_resolve_names);
-if (manager-rules)
-event_queue_start(manager);
-}
+event_queue_start(manager);
 
 if (is_signal) {
 struct signalfd_siginfo fdsi;
-- 
2.3.4

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

[systemd-devel] [PATCH 5/6] units: udevd - hook up watchdog support

[Tom Gundersen]

---
 units/systemd-udevd.service.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/units/systemd-udevd.service.in b/units/systemd-udevd.service.in
index 32f04d9..e7216d6 100644
--- a/units/systemd-udevd.service.in
+++ b/units/systemd-udevd.service.in
@@ -23,3 +23,4 @@ RestartSec=0
 ExecStart=@rootlibexecdir@/systemd-udevd
 MountFlags=slave
 KillMode=mixed
+WatchdogSec=1min
-- 
2.3.4

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

[systemd-devel] [PATCH 3/6] udevd: explicitly try to start event queue when it may be possible

[Tom Gundersen]

Rather than trying to schedule new events on every main-loop iteration, do it 
explicitly when
processing an event finishes, a worker is killed, a new uevent is received, or 
the event queue
is explicitly restarted.
---
 src/udev/udevd.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index e309def..c9b0ed5 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -849,6 +849,9 @@ static int on_worker(sd_event_source *s, int fd, uint32_t 
revents, void *userdat
 event_free(worker-event);
 }
 
+/* we have free workers, try to schedule events */
+event_queue_start(manager);
+
 return 1;
 }
 
@@ -865,6 +868,9 @@ static int on_uevent(sd_event_source *s, int fd, uint32_t 
revents, void *userdat
 r = event_queue_insert(manager, dev);
 if (r  0)
 udev_device_unref(dev);
+else
+/* we have fresh events, try to schedule them */
+event_queue_start(manager);
 }
 
 return 1;
@@ -903,6 +909,7 @@ static int on_ctrl_msg(sd_event_source *s, int fd, uint32_t 
revents, void *userd
 if (udev_ctrl_get_start_exec_queue(ctrl_msg)  0) {
 log_debug(udevd message (START_EXEC_QUEUE) received);
 manager-stop_exec_queue = false;
+event_queue_start(manager);
 }
 
 if (udev_ctrl_get_reload(ctrl_msg)  0) {
@@ -1169,6 +1176,9 @@ static int on_sigchld(sd_event_source *s, const struct 
signalfd_siginfo *si, voi
 worker_free(worker);
 }
 
+/* we can start new workers, try to schedule events */
+event_queue_start(manager);
+
 return 1;
 }
 
@@ -1672,9 +1682,6 @@ int main(int argc, char *argv[]) {
 if (is_uevent)
 on_uevent(NULL, manager-fd_uevent, 0, manager);
 
-/* start new events */
-event_queue_start(manager);
-
 if (is_signal) {
 struct signalfd_siginfo fdsi;
 ssize_t size;
-- 
2.3.4

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

[systemd-devel] [PATCH 4/6] udevd: move main-loop to sd-event

[Tom Gundersen]

---
 src/udev/udevd.c | 378 ++-
 1 file changed, 177 insertions(+), 201 deletions(-)

diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index c9b0ed5..8cffd81 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -41,6 +41,8 @@
 #include sys/inotify.h
 
 #include sd-daemon.h
+#include sd-event.h
+#include event-util.h
 #include rtnl-util.h
 #include cgroup-util.h
 #include process-util.h
@@ -62,6 +64,7 @@ static usec_t arg_event_timeout_warn_usec = 180 * 
USEC_PER_SEC / 3;
 
 typedef struct Manager {
 struct udev *udev;
+sd_event *event;
 Hashmap *workers;
 struct udev_list_node events;
 char *cgroup;
@@ -74,15 +77,13 @@ typedef struct Manager {
 struct udev_monitor *monitor;
 struct udev_ctrl *ctrl;
 struct udev_ctrl_connection *ctrl_conn_blocking;
-
-int fd_ep;
-int fd_ctrl;
-int fd_uevent;
-int fd_signal;
 int fd_inotify;
-int fd_worker;
 int worker_watch[2];
 
+sd_event_source *ctrl_event;
+sd_event_source *uevent_event;
+sd_event_source *inotify_event;
+
 usec_t last_usec;
 
 bool stop_exec_queue:1;
@@ -112,8 +113,8 @@ struct event {
 dev_t devnum;
 int ifindex;
 bool is_block;
-usec_t start_usec;
-bool warned;
+sd_event_source *timeout_warning;
+sd_event_source *timeout;
 };
 
 static inline struct event *node_to_event(struct udev_list_node *node) {
@@ -153,6 +154,9 @@ static void event_free(struct event *event) {
 udev_device_unref(event-dev);
 udev_device_unref(event-dev_kernel);
 
+sd_event_source_unref(event-timeout_warning);
+sd_event_source_unref(event-timeout);
+
 if (event-worker)
 event-worker-event = NULL;
 
@@ -254,7 +258,12 @@ static int on_event_timeout_warning(sd_event_source *s, 
uint64_t usec, void *use
 }
 
 static void worker_attach_event(struct worker *worker, struct event *event) {
+sd_event *e;
+uint64_t usec;
+int r;
+
 assert(worker);
+assert(worker-manager);
 assert(event);
 assert(!event-worker);
 assert(!worker-event);
@@ -262,9 +271,19 @@ static void worker_attach_event(struct worker *worker, 
struct event *event) {
 worker-state = WORKER_RUNNING;
 worker-event = event;
 event-state = EVENT_RUNNING;
-event-start_usec = now(CLOCK_MONOTONIC);
-event-warned = false;
 event-worker = worker;
+
+e = worker-manager-event;
+
+r = sd_event_now(e, clock_boottime_or_monotonic(), usec);
+if (r  0)
+return;
+
+(void) sd_event_add_time(e, event-timeout_warning, 
clock_boottime_or_monotonic(),
+ usec + arg_event_timeout_warn_usec, 
USEC_PER_SEC, on_event_timeout_warning, event);
+
+(void) sd_event_add_time(e, event-timeout, 
clock_boottime_or_monotonic(),
+ usec + arg_event_timeout_usec, USEC_PER_SEC, 
on_event_timeout, event);
 }
 
 static void manager_free(Manager *manager) {
@@ -273,7 +292,12 @@ static void manager_free(Manager *manager) {
 
 udev_builtin_exit(manager-udev);
 
+sd_event_source_unref(manager-ctrl_event);
+sd_event_source_unref(manager-uevent_event);
+sd_event_source_unref(manager-inotify_event);
+
 udev_unref(manager-udev);
+sd_event_unref(manager-event);
 manager_workers_free(manager);
 event_queue_cleanup(manager, EVENT_UNDEF);
 
@@ -285,8 +309,6 @@ static void manager_free(Manager *manager) {
 udev_rules_unref(manager-rules);
 free(manager-cgroup);
 
-safe_close(manager-fd_ep);
-safe_close(manager-fd_signal);
 safe_close(manager-fd_inotify);
 safe_close_pair(manager-worker_watch);
 
@@ -336,12 +358,16 @@ static void worker_spawn(Manager *manager, struct event 
*event) {
 manager-monitor = udev_monitor_unref(manager-monitor);
 manager-ctrl_conn_blocking = 
udev_ctrl_connection_unref(manager-ctrl_conn_blocking);
 manager-ctrl = udev_ctrl_unref(manager-ctrl);
-
-manager-fd_ep = safe_close(manager-fd_ep);
-manager-fd_signal = safe_close(manager-fd_signal);
+manager-ctrl_conn_blocking = 
udev_ctrl_connection_unref(manager-ctrl_conn_blocking);
 manager-fd_inotify = safe_close(manager-fd_inotify);
 manager-worker_watch[READ_END] = 
safe_close(manager-worker_watch[READ_END]);
 
+manager-ctrl_event = 
sd_event_source_unref(manager-ctrl_event);
+manager-uevent_event = 
sd_event_source_unref(manager-uevent_event);
+manager-inotify_event = 
sd_event_source_unref(manager-inotify_event);
+
+manager-event = 

Re: [systemd-devel] [PATCH] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning

[Tom Gundersen]

On Sat, May 23, 2015 at 6:04 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
 It was a warning when we still supported kernel  3.4. current
 minimum version is 3.7.

Hm, we don't actually fail out here, but we still try to continue.
Isn't 'warning' more appropriate in that case?

Cheers,
Tom

  src/core/main.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

 diff --git a/src/core/main.c b/src/core/main.c
 index c39815b..3bebc98 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1608,9 +1608,7 @@ int main(int argc, char *argv[]) {
  if (arg_running_as == MANAGER_USER) {
  /* Become reaper of our children */
  if (prctl(PR_SET_CHILD_SUBREAPER, 1)  0) {
 -log_warning_errno(errno, Failed to make us a 
 subreaper: %m);
 -if (errno == EINVAL)
 -log_info(Perhaps the kernel version is too 
 old ( 3.4?));
 +log_error_errno(errno, Failed to make us a 
 subreaper: %m);
  }
  }

 --
 2.4.1

 ___
 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] nspawn: be verbose about interface names

[Tom Gundersen]

On Fri, May 22, 2015 at 4:02 PM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
 Allowed interface name is relatively small. Lets not make
 users go in to the source code to figure out what happened.

 --machine=debian-tree conflicts with
 --machine=debian-tree2

 ex: Failed to add new veth \
  interfaces (host0, vb-debian-tree): File exists
 ---
  src/nspawn/nspawn.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
 index 5009363..646edea 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -2627,7 +2627,7 @@ static int setup_veth(pid_t pid, char 
 iface_name[IFNAMSIZ], int *ifi) {

  r = sd_rtnl_call(rtnl, m, 0, NULL);
  if (r  0)
 -return log_error_errno(r, Failed to add new veth 
 interfaces: %m);
 +return log_error_errno(r, Failed to add new veth interfaces 
 (host0, %s): %m, iface_name);

  i = (int) if_nametoindex(iface_name);
  if (i = 0)
 --
 2.1.4

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


Applied. Thansk!

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

Re: [systemd-devel] [PATCH] Correct path to systemd-fsck in generated systemd-fsck-root.service

[Tom Gundersen]

On Sun, May 24, 2015 at 10:33 PM, Mike Gilbert flop...@gentoo.org wrote:
 ---
  Makefile.am| 1 +
  src/shared/generator.c | 2 +-
  2 files changed, 2 insertions(+), 1 deletion(-)

 diff --git a/Makefile.am b/Makefile.am
 index f84a28d..70d4dc0 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -188,6 +188,7 @@ AM_CPPFLAGS = \
 -DCATALOG_DATABASE=\$(catalogstatedir)/database\ \
 
 -DSYSTEMD_CGROUP_AGENT_PATH=\$(rootlibexecdir)/systemd-cgroups-agent\ \
 -DSYSTEMD_BINARY_PATH=\$(rootlibexecdir)/systemd\ \
 +   -DSYSTEMD_FSCK_PATH=\$(rootlibexecdir)/systemd-fsck\ \
 -DSYSTEMD_SHUTDOWN_BINARY_PATH=\$(rootlibexecdir)/systemd-shutdown\ 
 \
 -DSYSTEMD_SLEEP_BINARY_PATH=\$(rootlibexecdir)/systemd-sleep\ \
 -DSYSTEMCTL_BINARY_PATH=\$(rootbindir)/systemctl\ \
 diff --git a/src/shared/generator.c b/src/shared/generator.c
 index 8128499..807569a 100644
 --- a/src/shared/generator.c
 +++ b/src/shared/generator.c
 @@ -61,7 +61,7 @@ static int write_fsck_sysroot_service(const char *dir, 
 const char *what) {
  [Service]\n
  Type=oneshot\n
  RemainAfterExit=yes\n
 -ExecStart=/usr/lib/systemd/systemd-fsck %2$s\n
 +ExecStart= SYSTEMD_FSCK_PATH  %2$s\n
  TimeoutSec=0\n,
  program_invocation_short_name,
  what,
 --
 2.4.1

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


Applied. Thanks!

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

Re: [systemd-devel] [PATCH] Remove accelerometer helper

[Tom Gundersen]

On Fri, May 22, 2015 at 3:42 PM, Bastien Nocera had...@hadess.net wrote:
 It's moved to the iio-sensor-proxy D-Bus service.

Nice! When was this released? Should we expect all distros to have
picked up this yet?

 ---
  .gitignore |   1 -
  Makefile.am|  15 --
  rules/61-accelerometer.rules   |   3 -
  src/udev/accelerometer/Makefile|   1 -
  src/udev/accelerometer/accelerometer.c | 303 
 -
  5 files changed, 323 deletions(-)
  delete mode 100644 rules/61-accelerometer.rules
  delete mode 12 src/udev/accelerometer/Makefile
  delete mode 100644 src/udev/accelerometer/accelerometer.c

 diff --git a/.gitignore b/.gitignore
 index d2f1a1f..0eaa65f 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -26,7 +26,6 @@
  /GRTAGS
  /GSYMS
  /GTAGS
 -/accelerometer
  /ata_id
  /bootctl
  /build-aux
 diff --git a/Makefile.am b/Makefile.am
 index f84a28d..90a78a9 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4087,21 +4087,6 @@ dist_udevrules_DATA += \
 rules/60-persistent-v4l.rules

  # ---
 ---
 -accelerometer_SOURCES = \
 -   src/udev/accelerometer/accelerometer.c
 -
 -accelerometer_LDADD = \
 -   libudev-internal.la \
 -   libsystemd-internal.la \
 -   libsystemd-shared.la
 -
 -udevlibexec_PROGRAMS += \
 -   accelerometer
 -
 -dist_udevrules_DATA += \
 -   rules/61-accelerometer.rules
 -
 -# ---
 ---
  if ENABLE_GUDEV
  if ENABLE_GTK_DOC
  SUBDIRS += \
 diff --git a/rules/61-accelerometer.rules b/rules/61
 -accelerometer.rules
 deleted file mode 100644
 index a6a2bfd..000
 --- a/rules/61-accelerometer.rules
 +++ /dev/null
 @@ -1,3 +0,0 @@
 -# do not edit this file, it will be overwritten on update
 -
 -SUBSYSTEM==input, ACTION!=remove,
 ENV{ID_INPUT_ACCELEROMETER}==1, IMPORT{program}=accelerometer %p
 diff --git a/src/udev/accelerometer/Makefile
 b/src/udev/accelerometer/Makefile
 deleted file mode 12
 index d0b0e8e..000
 --- a/src/udev/accelerometer/Makefile
 +++ /dev/null
 @@ -1 +0,0 @@
 -../Makefile
 \ No newline at end of file
 diff --git a/src/udev/accelerometer/accelerometer.c
 b/src/udev/accelerometer/accelerometer.c
 deleted file mode 100644
 index 9e2c590..000
 --- a/src/udev/accelerometer/accelerometer.c
 +++ /dev/null
 @@ -1,303 +0,0 @@
 -/*
 - * accelerometer - exports device orientation through property
 - *
 - * When an change event is received on an accelerometer,
 - * open its device node, and from the value, as well as the previous
 - * value of the property, calculate the device's new orientation,
 - * and export it as ID_INPUT_ACCELEROMETER_ORIENTATION.
 - *
 - * Possible values are:
 - * undefined
 - * * normal
 - * * bottom-up
 - * * left-up
 - * * right-up
 - *
 - * The property will be persistent across sessions, and the new
 - * orientations can be deducted from the previous one (it allows
 - * for a threshold for switching between opposite ends of the
 - * orientation).
 - *
 - * Copyright (C) 2011 Red Hat, Inc.
 - * Author:
 - *   Bastien Nocera had...@hadess.net
 - *
 - * orientation_calc() from the sensorfw package
 - * Copyright (C) 2009-2010 Nokia Corporation
 - * Authors:
 - *   Üstün Ergenoglu ext-ustun.ergeno...@nokia.com
 - *   Timo Rongas ext-timo.2.ron...@nokia.com
 - *   Lihan Guo lihan@digia.com
 - *
 - * This program is free software; you can redistribute it and/or
 modify
 - * it under the terms of the GNU General Public License as published
 by
 - * the Free Software Foundation; either version 2 of the License, or
 - * (at your option) any later version.
 - *
 - * This program is distributed in the hope that it will be useful,
 - * but WITHOUT ANY WARRANTY; without even the implied warranty of
 - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 - * GNU General Public License for more details.
 - *
 - * You should have received a copy of the GNU General Public License
 along
 - * with this program; if not, write to the Free Software Foundation,
 Inc.,
 - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 - */
 -
 -#include stdio.h
 -#include string.h
 -#include math.h
 -#include stdlib.h
 -#include getopt.h
 -#include limits.h
 -#include linux/input.h
 -
 -#include libudev.h
 -#include libudev-private.h
 -
 -/* we must use this kernel-compatible implementation */
 -#define BITS_PER_LONG (sizeof(unsigned long) * 8)
 -#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
 -#define OFF(x)  ((x)%BITS_PER_LONG)
 -#define BIT(x)  (1ULOFF(x))
 -#define LONG(x) ((x)/BITS_PER_LONG)
 -#define test_bit(bit, array)((array[LONG(bit)]  OFF(bit))  1)
 -
 -typedef enum {
 -ORIENTATION_UNDEFINED,
 -ORIENTATION_NORMAL,
 -ORIENTATION_BOTTOM_UP,
 -ORIENTATION_LEFT_UP,
 -ORIENTATION_RIGHT_UP
 -} OrientationUp;
 -
 -static const char 

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

[Tom Gundersen]

On Wed, May 20, 2015 at 8:05 PM, Michael Marineau
michael.marin...@coreos.com wrote:
 I haven't retested HEAD yet but up through 219 it would report 'no-carrier
 configuring' which seems bogus since it shouldn't be configuring an
 interface in such a state

no-carrier configuring could easily happen as we would enslave a
device and add routes/addresses even before the device gains a
carrier.

 and there is no .network config to apply to the
 interface either.

Now this is strange. A link should never be in configuring state
unless we actually have a .network file to apply to it.

 We have seen similar looking networkctl output for
 physical interfaces too but since several different states get squashed into
 'configuring' I'm not sure if it is the same situation, it was just easier
 to demo with a .netdev and bridge. Interestingly no other mechanism for
 creating a bridge (ip or brctl) got it into the same state but I'm not sure
 why.

Not sure to be honest, I'll try to keep an eye on this, but as I said
I have not been able to reproduce.

Cheers,

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

Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time

[Tom Gundersen]

On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin alin.ra...@intel.com wrote:
 Hi Lennart,

 Thanks for the answers.

 One more questions. Just a curiosity of mine.

 Currently, a user has to write scripts if he wants to save the run-time 
 configuration in networkd format or to use a configuration management tool 
 like chef for example.
 Even with the latter, the user still needs to write scripts.

 What about saving the run-time configuration in networkd format with 
 networkctl maybe ?
 Something like networkctl save or networkctl save config with extensions 
 to provide per port configuration saving, output directory for saved 
 configuration and so on ... ?

Not entirely sure I understand the question, but this is what I have
in mind: we support three config sources at the moment: stuff in /lib
which is shipped by packages, stuff in /etc that is provided by the
admin and is persistent between reboots and stuff in /run which is
lost on reboot. Our future API should have a switch allowing the
config we apply to either be persistent (written out to /etc) or
ephemeral (written out to /run), so that any config in networkd is
backed by a config file somewhere. Does that make sense? Does it
answer your question, or is there some other type of config you would
like to write out?

Cheers,

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

Re: [systemd-devel] [PATCH] Fixed incorrect type for MTU

[Tom Gundersen]

On Thu, May 21, 2015 at 12:54 PM, dmoneil2 david.m.one...@intel.com wrote:
 The parser uses size_t for MTU however the structure is defined with unsigned 
 int
 as the target type resulting in a value corruption for the next field of the 
 structure.

 dmoneil2 (1):
   Fixed issue with corruption of speed value when setting on x64
 systems.

  src/udev/net/link-config.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks for the patch!  I now pushed a similar fix, please verify that
it works for you.

Cheers,

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

Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd

[Tom Gundersen]

On Wed, May 20, 2015 at 8:24 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey David,

 David Herrmann [2015-05-19 17:06 +0200]:
 We're about to remove gudev from the systemd repository, as it is in
 no way related to the systemd code-base, nor used by the systemd
 project.

 This makes sense indeed. gudev used to be a standalone project before
 it was merged into udev, so the circle is complete now :-)

 For those of us who already packaged gudev from systemd 219, would it
 be possible to bump the current release to 220, so that gudev can be
 packaged without renaming the tarball and doing ugly version numbers?
 Monotonously increasing version numbers and all.. (Yes, there are
 epochs in Debian, and I'm sure RPM has these too, but they might not
 be available everywhere and are generally frowned upon)

While you are at it, why not bump it to 225 or something (just to
guarantee that the last systemd release with gudev has a lower version
number than gudev at that time, so people can switch over whenever
they want without having to worry about going backwards).

Cheers,

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

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

[Tom Gundersen]

On Tue, Apr 21, 2015 at 11:59 PM, Nick Owens misch...@offblast.org wrote:
 hello tom,

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

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

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

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

 nick

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

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

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

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

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

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

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

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

Correct. I mean, waiting for the system coming online like this is
mostly a legacy thing, so we support this in a relatively limited way.
Anything modern better explicitly listen for rtnl events and act
accordingly.

 another instance of this problem is having a bridge like

 [NetDev]
 Name=br0
 Kind=bridge

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

Hm, I'm not able to reproduce this. Can you still reproduce with git
HEAD? If so what are the other config files that are applied, and what
is the output of networkctl whilst wait-online is hanging?

Cheers,

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

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

[Tom Gundersen]

On Tue, May 19, 2015 at 6:57 PM, Jan Engelhardt jeng...@inai.de wrote:

 On Tuesday 2015-05-19 18:38, Tom Gundersen wrote:
  # 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 [...]
  # 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. [...]

 What precisely is the heuristic?[...]

There are two 'types', the ARP hardware identifier (link type as
exposed over rtnl) and the DEVTYPE (as exposed by libudev). The
matching logic only uses DEVTYPE.

 Unlike hwdevtype, arphrd is at least set _all the time_.

True, but not always to something useful (which is why we special case
ARPHRD_ETHER and DEVTYPE==wlan|wwan).

The output of networkctl (and the udev naming to a more limited degree) uses
the ARP hardware identifier and then falls back to DEVTYPE in the case of
ethernet devices to distinguish wlan and wwan interfaces from other kinds of
ethernet interfaces.

In an ideal world, we would only use DEVTYPE and the kernel would
assign this reasonably to all devices. In the meantime we could do
some combination of DEVTYPE and ARPHRD, but the danger here is that we
will lock ourselves into some heuristic and make it impossible to
improve the kernel DEVTYPE's in the future as it would change the
behavior of current setups, which is why I have preferred to not
support any matching when DEVTYPE is not set. I'm very open to change
this if anyone has a convincing scheme in mind though.

 So, perhaps just making networkd support both DevType={match on DEVTYPE 
 string}
 and LinkType={ether,loopback,other ARPHRD_* constants} be the interim solution
 for that.

I'd rather we just decide on some scheme once and for all. Interim
solutions have a way of becoming permanent...

-t
___
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 21, 2015 at 6:26 PM, Lennart Poettering
lenn...@poettering.net wrote:
 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...

There are two 'types', the ARP hardware identifier (link type as
exposed over rtnl) and the DEVTYPE (as exposed by libudev). The
matching logic only uses DEVTYPE. The output of networkctl (and the
udev naming to a more limited degree) uses the ARP hardware identifier
and then falls back to DEVTYPE in the case of ethernet devices to
distinguish wlan and wwan interfaces from other kinds of ethernet
interfaces.

In an ideal world, we would only use DEVTYPE and the kernel would
assign this reasonably to all devices. In the meantime we could do
some combination of DEVTYPE and ARPHRD, but the danger here is that we
will lock ourselves into some heuristic and make it impossible to
improve the kernel DEVTYPE's in the future as it would change the
behavior of current setups, which is why I have preferred to not
support any matching when DEVTYPE is not set. I'm very open to change
this if anyone has a convincing scheme in mind though.

Cheers,

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

Re: [systemd-devel] Setting UseDomains=yes by default DHCP

[Tom Gundersen]

It seems this thread was already resolved, just wanted to add one comment:

On Mon, May 18, 2015 at 2:26 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 So to mount a successful spoof, the attacker needs to
 a) control the dhcp server domain option to return a domain under attacker 
 control

Notice that this is entirely trivial, as the attacker does not need to
control _the_ DHCP server, all they have to do is to provide a
competing DHCP server on the local link and hope they get picked over
the real one.

Cheers,

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

Re: [systemd-devel] How to set primary slave in active-backup mode (bonding)

[Tom Gundersen]

On Thu, Apr 9, 2015 at 4:29 PM, Mikhail Morfikov mmorfi...@gmail.com wrote:
 I usually have two network interfaces on my laptops (one eth and one
 wlan), and when I was using sysvinit I also was configuring the bond
 interface via the /etc/network/interfaces file so the two interfaces
 could work in the active-backup mode. But now, they work in balance-rr
 mode which is set via the .netdev file. The problem with this mode is
 that when you have, let's say wifi 30mbit/s and wired 100mbit/s, you
 can get 60mbit/s max, and that's why I wanted to use the active-backup
 mode which switches from wire to wifi and vice versa depending on
 whether the ethernet cable is plugged in. Generally speaking, I have to
 set some additional parameters so this could work well, and that would
 be:

We don't yet fully support all the bonding options.

 bond-primary eth1

This is not currently supported, I suppose we should add the
possibility of marking a slave as 'primary' to the .network file
(rather than listing the slave in the .netdev file).

 bond-primary-reselect always

This is PrimaryReselectPolicy=always in the .netdev file.

 bond-slaves eth1 wlan0

This is achieved by setting Bond= in the .network files applied to
eth1 and wlan0.

 bond-fail-over-mac none

This is FailOverMACPolicy=none in the .netdev file, which is also the
default, so is redundant.

 I'm not sure if all of them are necessary, and the question is how to
 pass these parameters in systemd? I'm asking because in the
 systemd.netdev manual, in the bond section, these options weren't
 specified.

I hope the above helps, but I suspect you really need the feature to
specify the primary slave for this to work as you intended. Happy to
take a patch!

Cheers,

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

Re: [systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout

[Tom Gundersen]

On Sat, May 2, 2015 at 12:21 PM, Nir Soffer nir...@gmail.com wrote:
 On Tue, Apr 21, 2015 at 12:41 AM, Tom Gundersen t...@jklm.no wrote:
 On Mon, Apr 13, 2015 at 3:04 PM, Nir Soffer nir...@gmail.com wrote:
 On Sat, Apr 11, 2015 at 6:58 PM, David Herrmann dh.herrm...@gmail.com 
 wrote:
 A program running this tool can detect a timeout (expected) or an error
 (unexpected), and can change the program flow based on this result.

 Without this, the only way to detect a timeout is to implement the timeout
 in the program calling udevadm.

 I cannot really see a use-case here. I mean, yeah, the commit-message
 says it warns about timeouts but fails loudly on real errors. But
 again, what's the use-case? Why is a timeout not a real error? Why do
 you need to handle it differently?

 Timeout means that the value I chose may be too small, or the machine
 is overloaded. The administrator may need to configure the system
 differently.

 Other errors are not expected, and typically unexpected errors in an
 underlying tool means getting the developer of the underlying tool
 involved.

 Anyway, if it's only about diagnostics this patch seems fine to me.

 Yes, it is mainly about diagnostics, and making it easier to debug and 
 support.

 Wouldn't a better solution be to improve the udevadm logging? If we
 change the exit codes this is basically ABI. Do we really want to make
 such promises only for diagnostics?

 Improving logging is orthogonal, as it does allow the program to change
 the flow based the exit code.

 Adding a timeout exit code may break code using undocumented behavior,
 since the return code is not documented.

I don't really have a strong argument against this, except that we
should not add ABI without a strong usecase. So you mentioned that
you want this for diagnostics, to which my suggestion was to improve
the logging in udevadm itself. But are there other usecases? What is
the case where the external tool actually needs to change its
behavior?

Cheers,

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

Re: [systemd-devel] systemd-networkd and systemd-nspawn: missing host-side network

[Tom Gundersen]

On Mon, Apr 27, 2015 at 6:50 AM, Kai Krakow hurikha...@gmail.com wrote:
 I've created a container with systemd-nspawn, machinectl enabled it, then
 added machines.target to my default target (systemctl enable
 machines.target) so that containers will be autostarted on boot. That works
 so far.

 But I discovered that systemd-networkd no longer configures my normal
 ethernet device during boot (it's configured as dhcp client). It just
 configures the ve-* device and that's it. After I manually restart networkd,
 all links are configured.

 Steps to reproduce:

 $ cat /etc/systemd/network/80-dhcp.network
 [Match]
 Name=en*
 [Network]
 DHCP=yes
 [DHCP]
 UseDomains=true

 $ cat /etc/systemd/network/90-veth.network
 # This was added because otherwise after reboot, ve- is stuck in
 # mode configuring when looking at networkctl, it changes nothing
 # for the following behaviour, tho...
 [Match]
 Name=ve-*
 [Network]
 DHCP=no

 $ machinectl enable test-machine
 $ systemctl enable machines.target
 $ systemctl reboot
 ...[rebooting]...

 $ networkctl
 IDX LINK TYPE   OPERATIONAL SETUP
   1 lo   loopback   n/a n/a
   2 enp4s0   ether  n/a n/a
   3 sit0 sitn/a n/a
   4 ve-  ether  routableconfigured

 $ ifconfig
 # shows only lo and ve-

Hm? ifconfig does not show enp4s0? How about ip link?

 $ systemctl restart systemd-networkd
 $ networkctl
 IDX LINK TYPE   OPERATIONAL SETUP
   1 lo   loopback   carrier unmanaged
   2 enp4s0   ether  routableconfigured
   3 sit0 sitoff unmanaged
   4 ve-  ether  routableconfigured

Which version did you observe this in? Is this reproducible with
current git HEAD? If so, could you attach $ networkctl status enp4s0
and the output of journalctl -b -u systemd-networkd (preferably after
enabling debug logging in networkd by setting
Environment=SYSTEMD_LOG_LEVEL=debug in the networkd service file).

Cheers,

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

Re: [systemd-devel] networkd failing sporadically failing to bring up network device

[Tom Gundersen]

On Tue, Apr 7, 2015 at 5:46 PM, Richard Maw richard@codethink.co.uk wrote:
 On Sat, Apr 04, 2015 at 12:08:04PM +0100, Sitsofe Wheeler wrote:
 Hi,

 I've noticed that networkd occasionally fails to bring up one of two
 network interfaces on boot (this happens about once every 70 or so
 boots). The machine in question is a VMware ESXi 5.5 guest with two
 VMXNET3 network adaptors. When this issue occurs the message

 rtnl: received address for a nonexistent link (1), ignoring

 is present in the journal.

 Does anyone know if this is a known issue in systemd 216 (I'm using
 Fedora 21)? I've attached a journal log below:

 There's been a few post-217 changes related to parsing messages in rtnl,
 one of which was related to accidentally interpreting change notifications
 as responses under rare circumstances, so there are some known bugs in
 216, but I haven't encountered yours before.

 Re-testing with the latest systemd snapshot would let us know if it's
 one of the bugs fixed post 217.

 If it comes to debugging what netlink is doing, one option is to
 use the nlmon interface, capture it with tcpdump as described in
 http://seclists.org/tcpdump/2014/q4/32 and then use wireshark to parse
 the dump.

Seems I missed parts of this thread (I cannot find the original email
in my archive), so in case I missed something important: could this be
reproduced with current git, or is this seemingly resolved now?

Cheers,

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

Re: [systemd-devel] unaligned write in dhcp_identifier_set_iaid

[Tom Gundersen]

On Tue, Feb 24, 2015 at 7:22 PM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
 there is an unaligned write in dhcp_identifier_set_iaid() and I'm not quite
 sure what the correct fix is:

 int dhcp_identifier_set_iaid(int ifindex, uint8_t *mac, size_t mac_len, 
 uint32_t *_id) {
 [...]
 *_id = (id  0x) ^ (id  32);
 [...]
 }

 And this is called with:
 r = dhcp_identifier_set_iaid(client-index, client-mac_addr, 
 client-mac_addr_len, client-client_id.ns.iaid);

 And iaid is not unaligned because of the packing in struct sd_dhcp_client.
 I'm not sure why '_packed_' is used there. It this just to save some space,
 or is there a reason for this?

Thanks for the report. This seems to have fallen through the cracks.
Should be fixed in git, please verify.

Sorry for the delay.

Cheers,

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

Re: [systemd-devel] systemd-nspawn trouble

[Tom Gundersen]

On Sun, May 17, 2015 at 5:30 PM, Michael Biebl mbi...@gmail.com wrote:
 2015-05-15 22:16 GMT+02:00 Tom Gundersen t...@jklm.no:
 on-demand I agree with Lennart that it makes the most sense to simply
 unconditionally load the modules. If this is undesirable the solution
 should be to teach the kernel to auto-load the modules, not to expect
 the admin to figure out that explicit loading is required, IMHO.

 And now we expect that the admin figures out how to disable loading of
 the iptables module, which isn't anymore obvious.

Out of interest, what is the 'regression' users would experience by
having the iptables module loaded? Or is it just about the principle
of not wanting to load a module unless it is actually used?

 What I was suggesting was, that the iptables modules should only be
 loaded on demand, i.e. when the firewalling functionality is actually
 used.

If so, this should be done by the kernel.

 Lennart did argue, that he didn't want to do that within
 networkd, since he didn't want to grant networkd that capability to
 load modules and therefor to load the module unconditionally in PID 1.
 But moving the modules loading out of networkd doesn't mean, it has to
 be done unconditonally, see how we did it for
 udev/kmod-static-nodes.service

Hm, this is all about letting the kernel do the module loading lazily
on-demand, so I'd be all for that, but then the kernel would need to
learn how to do that for iptables first...

Cheers,

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

Re: [systemd-devel] Will *.network replace resolv.conf? What about Options single-request?

[Tom Gundersen]

On Mon, May 4, 2015 at 2:57 PM, Christian Brunotte c...@lathspell.de wrote:
 systemd.network(5) with Options like DNS= and Domains= looks like
 /etc/resolv.conf will soon be superfluous.

In many setups, yes, but we will not aim at bug-for-bug compatibility
or anything like that. We are open to adding features that make sense
though.

 If that's the plan, I wonder what happens to options single-request
 which I had to use on all IPv6 enabled devices. Is ResolveOptions just
 missing in Systemd or considered so special that will stay in libc's
 resolv.conf?

 (quoting from the man page: By default, glibc performs IPv4 and IPv6
 lookups in parallel since version 2.9. Some appliance DNS servers cannot
 handle queries properly and make the requests time out.)

Hm, this really does not sound like something that should be
configurable. Are you really seeing these bugs in the wild? And if so,
how do other OSs deal with this? I mean, having to add quirks to every
client does not sound very viable... Surely DNS is something that
should 'just work'. I feel like I'm missing some part of the picture
here.

Cheers,

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

Re: [systemd-devel] systemd-nspawn trouble

[Tom Gundersen]

On Wed, Apr 22, 2015 at 2:36 PM, Michael Biebl mbi...@gmail.com wrote:
 2015-04-22 14:26 GMT+02:00 Lennart Poettering lenn...@poettering.net:
 On Wed, 22.04.15 14:22, Michael Biebl (mbi...@gmail.com) wrote:
 2015-04-22 14:14 GMT+02:00 Lennart Poettering lenn...@poettering.net:
  On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote:
  2015-04-22 13:57 GMT+02:00 Lennart Poettering lenn...@poettering.net:
   http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2
 
  Not everyone is using networkd or nspawn though, so loading this
  module for everyone is a bit excessive.
 
  Well, then blacklist the module or don't build it at all.

 That's the wrong way around.

 Nah, I disagree. We do this for a number of modules now. I mean, we

 We currently do this static loading for unix, ipv6 and autofs4.

 load tons of modules automatically, even if you don't use them. For
 example, my laptop always loads the bluetooth modules, even though I
 never used bluetooth.

 Those are all loaded on demand, not statically. I.e. we don't load the
 bluetooth module for each and every user.

We never require the admin to explicitly opt-in to loading any modules
for the functionality we use. For hardware drivers, modules are
unconditionally loaded when the hardware exists, for other modules the
kernel is usually able to load them on demand (filesystems, netdevs,
...). In the cases where the kernel is not able to load modules
on-demand I agree with Lennart that it makes the most sense to simply
unconditionally load the modules. If this is undesirable the solution
should be to teach the kernel to auto-load the modules, not to expect
the admin to figure out that explicit loading is required, IMHO.

Cheers,

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

Re: [systemd-devel] [PATCH v2] networkd: do not change kernel forwarding parameters when IPForwarding is unset

[Tom Gundersen]

On Fri, May 15, 2015 at 10:02 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 15.05.15 12:56, Michael Marineau (michael.marin...@coreos.com) wrote:

 (build time option to ./configure that is)

 I guess I'd be OK with that...

It would be a shame if we started diverging on the defaults I think.
Would be nice if we could come up with some scheme that would work for
everyone. Would an option be to use a script to append
IPForward='kernel' to your network files on upgrades? Pretty dirty,
but I don't know how you usually deal with config changes...

Cheers,

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

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

[Tom Gundersen]

Applied. Thanks!

Tom

On Wed, Apr 22, 2015 at 10:44 AM, Susant Sahani sus...@redhat.com wrote:
 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
 ---
  src/libsystemd/sd-rtnl/rtnl-types.c  |  3 +++
  src/libsystemd/sd-rtnl/rtnl-types.h  |  1 +
  src/network/networkd-netdev-tunnel.c | 43 
 
  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 +
  7 files changed, 53 insertions(+)

 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 7aa9317..aef2ef4 100644
 --- a/src/network/networkd-netdev-tunnel.c
 +++ b/src/network/networkd-netdev-tunnel.c
 @@ -212,6 +212,31 @@ 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)
 +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)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_LOCAL attribute: %m);
 +
 +r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_REMOTE, 
 t-remote.in6);
 +if (r  0)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_REMOTE attribute: %m);
 +
 +return r;
 +}
 +
  static int netdev_ip6tnl_fill_message_create(NetDev *netdev, Link *link, 
 sd_rtnl_message *m) {
  Tunnel *t = IP6TNL(netdev);
  uint8_t proto;
 @@ -287,6 +312,9 @@ static int netdev_tunnel_verify(NetDev *netdev, const 
 char *filename) {
  case NETDEV_KIND_VTI:
  t = VTI(netdev);
  break;
 +case NETDEV_KIND_VTI6:
 +t = VTI6(netdev);
 +break;
  case NETDEV_KIND_IP6TNL:
  t = IP6TNL(netdev);
  break;
 @@ -374,6 +402,12 @@ static void vti_init(NetDev *n) {
  Tunnel *t = VTI(n);

   

Re: [systemd-devel] [PATCH 3/3] networkd: add man for vti6 tunnel

[Tom Gundersen]

Applied. Thanks!

Tom

On Wed, Apr 22, 2015 at 10:44 AM, Susant Sahani sus...@redhat.com wrote:
 ---
  man/systemd.netdev.xml | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
 index f413739..3bfd01b 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

 --
 2.3.5

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

Re: [systemd-devel] [PATCH 1/3] networkd: tunnel improve logging

[Tom Gundersen]

Applied. Thanks!

Tom

On Wed, Apr 22, 2015 at 10:44 AM, Susant Sahani sus...@redhat.com wrote:
 Replaces a lof ot strerror() usage with log_netdev_error_errno()
 ---
  src/network/networkd-netdev-tunnel.c | 240 
 ++-
  1 file changed, 64 insertions(+), 176 deletions(-)

 diff --git a/src/network/networkd-netdev-tunnel.c 
 b/src/network/networkd-netdev-tunnel.c
 index 89ad3ee..7aa9317 100644
 --- a/src/network/networkd-netdev-tunnel.c
 +++ b/src/network/networkd-netdev-tunnel.c
 @@ -54,44 +54,24 @@ static int netdev_ipip_fill_message_create(NetDev 
 *netdev, Link *link, sd_rtnl_m
  assert(t-family == AF_INET);

  r = sd_rtnl_message_append_u32(m, IFLA_IPTUN_LINK, link-ifindex);
 -if (r  0) {
 -log_netdev_error(netdev,
 - Could not append IFLA_IPTUN_LINK 
 attribute: %s,
 - strerror(-r));
 -return r;
 -}
 +if (r  0)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_LINK attribute: %m);

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

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

  r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_TTL, t-ttl);
 -if (r  0) {
 -log_netdev_error(netdev,
 - Could not append IFLA_IPTUN_TTL  
 attribute: %s,
 - strerror(-r));
 -return r;
 -}
 +if (r  0)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_TTL  attribute: %m);

  r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_PMTUDISC, t-pmtudisc);
 -if (r  0) {
 -log_netdev_error(netdev,
 - Could not append IFLA_IPTUN_PMTUDISC 
 attribute: %s,
 - strerror(-r));
 -return r;
 -}
 +if (r  0)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_PMTUDISC attribute: %m);

  return r;
  }
 @@ -107,44 +87,24 @@ static int netdev_sit_fill_message_create(NetDev 
 *netdev, Link *link, sd_rtnl_me
  assert(t-family == AF_INET);

  r = sd_rtnl_message_append_u32(m, IFLA_IPTUN_LINK, link-ifindex);
 -if (r  0) {
 -log_netdev_error(netdev,
 - Could not append IFLA_IPTUN_LINK 
 attribute: %s,
 - strerror(-r));
 -return r;
 -}
 +if (r  0)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_LINK attribute: %m);

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

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

  r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_TTL, t-ttl);
 -if (r  0) {
 -log_netdev_error(netdev,
 - Could not append IFLA_IPTUN_TTL attribute: 
 %s,
 - strerror(-r));
 -return r;
 -}
 +if (r  0)
 +return log_netdev_error_errno(netdev, r, Could not append 
 IFLA_IPTUN_TTL attribute: %m);

  r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_PMTUDISC, t-pmtudisc);
 -if (r  0) {
 -

Re: [systemd-devel] [PATCH] core: fix event source annotations

[Tom Gundersen]

Applied. Thanks!

Tom

On Wed, Apr 29, 2015 at 8:29 PM, Mantas Mikulėnas graw...@gmail.com wrote:
 These looked like a mass-replace gone slightly wrong – two statements
 with no { }'s, and no error checking.
 ---
  src/core/busname.c | 4 +++-
  src/core/manager.c | 5 -
  src/core/socket.c  | 3 ++-
  3 files changed, 9 insertions(+), 3 deletions(-)

 diff --git a/src/core/busname.c b/src/core/busname.c
 index 48cc045..94db122 100644
 --- a/src/core/busname.c
 +++ b/src/core/busname.c
 @@ -291,13 +291,15 @@ static int busname_watch_fd(BusName *n) {
  r = sd_event_source_set_enabled(n-starter_event_source, 
 SD_EVENT_ON);
  else
  r = sd_event_add_io(UNIT(n)-manager-event, 
 n-starter_event_source, n-starter_fd, EPOLLIN, busname_dispatch_io, n);
 -(void) 
 sd_event_source_set_description(n-starter_event_source, busname-starter);
 +
  if (r  0) {
  log_unit_warning_errno(UNIT(n)-id, r, Failed to watch 
 starter fd: %m);
  busname_unwatch_fd(n);
  return r;
  }

 +(void) sd_event_source_set_description(n-starter_event_source, 
 busname-starter);
 +
  return 0;
  }

 diff --git a/src/core/manager.c b/src/core/manager.c
 index 0c94e9e..cf7337e 100644
 --- a/src/core/manager.c
 +++ b/src/core/manager.c
 @@ -90,6 +90,7 @@ static void manager_undo_generators(Manager *m);

  static void manager_watch_jobs_in_progress(Manager *m) {
  usec_t next;
 +int r;

  assert(m);

 @@ -97,12 +98,14 @@ static void manager_watch_jobs_in_progress(Manager *m) {
  return;

  next = now(CLOCK_MONOTONIC) + JOBS_IN_PROGRESS_WAIT_USEC;
 -(void) sd_event_add_time(
 +r = sd_event_add_time(
  m-event,
  m-jobs_in_progress_event_source,
  CLOCK_MONOTONIC,
  next, 0,
  manager_dispatch_jobs_in_progress, m);
 +if (r  0)
 +return;

  (void) 
 sd_event_source_set_description(m-jobs_in_progress_event_source, 
 manager-jobs-in-progress);
  }
 diff --git a/src/core/socket.c b/src/core/socket.c
 index 702742f..67beda4 100644
 --- a/src/core/socket.c
 +++ b/src/core/socket.c
 @@ -1272,11 +1272,12 @@ static int socket_watch_fds(Socket *s) {
  else
  r = sd_event_add_io(UNIT(s)-manager-event, 
 p-event_source, p-fd, EPOLLIN, socket_dispatch_io, p);

 -(void) 
 sd_event_source_set_description(p-event_source, socket-port-io);
  if (r  0) {
  log_unit_warning_errno(UNIT(s)-id, r, Failed to 
 watch listening fds: %m);
  goto fail;
  }
 +
 +(void) sd_event_source_set_description(p-event_source, 
 socket-port-io);
  }

  return 0;
 --
 2.3.7

 ___
 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] udev leaves dangling symlinks

[Tom Gundersen]

Thanks for this, and sorry for the delay! Fix pushed.

Tom

On Thu, Apr 16, 2015 at 9:51 PM, Mantas Mikulėnas graw...@gmail.com wrote:
 So recently I noticed that udev no longer deletes /dev symlinks for removed
 devices, leaving quite a few dangling links over time (and greatly confusing
 udisks as a side effect). This was broken by:

 commit 3c0bab4aaf70b2383aa4cbabf6059c48744e8960
 Author: Tom Gundersen t...@jklm.no
 Date:   Fri Mar 6 18:22:35 2015 +0100

 udevd: event - make db loading lazy in REMOVE event handling

 But udev_node_remove() needs the DB to know about symlinks, so…

 --
 Mantas Mikulėnas graw...@gmail.com

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

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

[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] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs

[Tom Gundersen]

On Wed, Mar 25, 2015 at 9: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.

Sorry for the delay in getting back to you.

I believe this is currently behaving as intended. The intention is
that all devices managed by networkd must be fully configured (not
simply get a carrier), but if there are no devices managed by networkd
then we wait for at least one device to gain carrier (in this case
something else must be bringing the interface up as networkd is up, so
it makes sure that networkd-wait-online does not get in the way of say
NetworkManager).

Does that make sense?

Cheers,

Tom

 ---
  src/network/networkd-wait-online-manager.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/network/networkd-wait-online-manager.c 
 b/src/network/networkd-wait-online-manager.c
 index 1c997a5..1ac162a 100644
 --- a/src/network/networkd-wait-online-manager.c
 +++ b/src/network/networkd-wait-online-manager.c
 @@ -74,13 +74,13 @@ bool manager_all_configured(Manager *m) {
  if (!l-state) {
  log_debug(link %s has not yet been processed by 
 udev,
l-ifname);
 -return false;
 +continue;
  }

  if (streq(l-state, configuring)) {
  log_debug(link %s is being processed by networkd,
l-ifname);
 -return false;
 +continue;
  }

  if (l-operational_state 
 --
 2.0.5

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

Re: [systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout

[Tom Gundersen]

On Mon, Apr 13, 2015 at 3:04 PM, Nir Soffer nir...@gmail.com wrote:
 On Sat, Apr 11, 2015 at 6:58 PM, David Herrmann dh.herrm...@gmail.com wrote:
 A program running this tool can detect a timeout (expected) or an error
 (unexpected), and can change the program flow based on this result.

 Without this, the only way to detect a timeout is to implement the timeout
 in the program calling udevadm.

 I cannot really see a use-case here. I mean, yeah, the commit-message
 says it warns about timeouts but fails loudly on real errors. But
 again, what's the use-case? Why is a timeout not a real error? Why do
 you need to handle it differently?

 Timeout means that the value I chose may be too small, or the machine
 is overloaded. The administrator may need to configure the system
 differently.

 Other errors are not expected, and typically unexpected errors in an
 underlying tool means getting the developer of the underlying tool
 involved.

 Anyway, if it's only about diagnostics this patch seems fine to me.

 Yes, it is mainly about diagnostics, and making it easier to debug and 
 support.

Wouldn't a better solution be to improve the udevadm logging? If we
change the exit codes this is basically ABI. Do we really want to make
such promises only for diagnostics?

Cheers,

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

Re: [systemd-devel] udev interface naming for SR-IOV VFs

[Tom Gundersen]

On Tue, Apr 14, 2015 at 12:11 PM, Ido Barkan ibar...@redhat.com wrote:
 We are implementing support for SR-IOV network cards. Afer the changing of
 the number of VFs on the card and programmatically querying for all links
 (we use libnl for this) we observe that *during the iteration* over the links
 some of them were renamed by udev and still were not. Meanning, some of them
 are called 'ethN' and some are called 'enp2sNf2' (where N is an arbitrary
 number). Also, there are times that not all of the devices are returned from
 libnl.
 After a _while_ everything stabilizes (# of interfaces and names).

 My questions:
 1. Is this what you would expect from udev? Meaning, this is just async 
 behavior?
 2. Is there a way to _know_ programmticaly that everything was probed and 
 renamed?
Not a heuristic?

In short: no. We don't know when the kernel will finish enumerating
all the devices.

What you can know though, is whether a device you receive over netlink
has been fully processed by udev. This is probably what you need,
assuming you always keep listening for new devices in your
daemon/tool.

You can see how we do this in e.g., systemd-networkd where we have
exactly the same situation: our main source of information is rtnl,
but we need to only start using the devices once udev has renamed them
(among other things) so we listen to libudev as well and only start
using a device once both rtnl and libudev has announced it is ready.

HTH,

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

Re: [systemd-devel] [PATCH] networkd vxlan: Add support for enabling UDP checksums

[Tom Gundersen]

Sorry for the delay. Applied. Thanks!

Tom

On Thu, Mar 5, 2015 at 5:32 PM, Susant Sahani sus...@redhat.com wrote:
 Add UDPCheckSum option to enable transmitting UDP checksums when doing
 VXLAN/IPv4. Add UDP6ZeroChecksumRx, and UDP6ZeroChecksumTx
 options to enable sending zero checksums and receiving zero
 checksums in VXLAN/IPv6

 V2: rename Udp to UDP
 ---
  man/systemd.netdev.xml  | 20 +++-
  src/network/networkd-netdev-gperf.gperf |  3 +++
  src/network/networkd-netdev-vxlan.c | 27 +++
  src/network/networkd-netdev-vxlan.h |  3 +++
  4 files changed, 52 insertions(+), 1 deletion(-)

 diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
 index e278aa1..7800dc4 100644
 --- a/man/systemd.netdev.xml
 +++ b/man/systemd.netdev.xml
 @@ -391,7 +391,25 @@
  paraA boolean. When true 
 route short circuit is turned on./para
  /listitem
  /varlistentry
 -/variablelist
 +varlistentry
 +
 termvarnameUDPCheckSum=/varname/term
 +listitem
 +paraA boolean. When true 
 transmitting UDP checksums when doing VXLAN/IPv4 is turned on./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameUDP6ZeroChecksumTx=/varname/term
 +listitem
 + paraA boolean. When true 
 sending zero checksums in VXLAN/IPv6 is turned on./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameUDP6ZeroCheckSumRx=/varname/term
 +listitem
 + paraA boolean. When true 
 receiving zero checksums in VXLAN/IPv6 is turned on./para
 +/listitem
 +/varlistentry
 +  /variablelist
  /refsect1
  refsect1
  title[Tunnel] Section Options/title
 diff --git a/src/network/networkd-netdev-gperf.gperf 
 b/src/network/networkd-netdev-gperf.gperf
 index 963c47c..c06344c 100644
 --- a/src/network/networkd-netdev-gperf.gperf
 +++ b/src/network/networkd-netdev-gperf.gperf
 @@ -47,6 +47,9 @@ VXLAN.ARPProxy,   config_parse_bool,
   0,
  VXLAN.L2MissNotification, config_parse_bool,  0, 
 offsetof(VxLan, l2miss)
  VXLAN.L3MissNotification, config_parse_bool,  0, 
 offsetof(VxLan, l3miss)
  VXLAN.RouteShortCircuit,  config_parse_bool,  0, 
 offsetof(VxLan, route_short_circuit)
 +VXLAN.UDPCheckSum,config_parse_bool,  0, 
 offsetof(VxLan, udpcsum)
 +VXLAN.UDP6ZeroCheckSumRx, config_parse_bool,  0, 
 offsetof(VxLan, udp6zerocsumrx)
 +VXLAN.UDP6ZeroCheckSumTx, config_parse_bool,  0, 
 offsetof(VxLan, udp6zerocsumtx)
  VXLAN.FDBAgeingSec,   config_parse_sec,   0, 
 offsetof(VxLan, fdb_ageing)
  Tun.OneQueue, config_parse_bool,  0, 
 offsetof(TunTap, one_queue)
  Tun.MultiQueue,   config_parse_bool,  0, 
 offsetof(TunTap, multi_queue)
 diff --git a/src/network/networkd-netdev-vxlan.c 
 b/src/network/networkd-netdev-vxlan.c
 index d5128cb..d9b13e3 100644
 --- a/src/network/networkd-netdev-vxlan.c
 +++ b/src/network/networkd-netdev-vxlan.c
 @@ -135,6 +135,30 @@ static int netdev_vxlan_fill_message_create(NetDev 
 *netdev, Link *link, sd_rtnl_
  }
  }

 +r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_CSUM, v-udpcsum);
 +if (r  0) {
 +log_netdev_error(netdev,
 + Could not append IFLA_VXLAN_UDP_CSUM 
 attribute: %s,
 + strerror(-r));
 +return r;
 +}
 +
 +r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_ZERO_CSUM6_TX, 
 v-udp6zerocsumtx);
 +if (r  0) {
 +log_netdev_error(netdev,
 + Could not append 
 IFLA_VXLAN_UDP_ZERO_CSUM6_TX attribute: %s,
 + strerror(-r));
 +return r;
 +}
 +
 +r = sd_rtnl_message_append_u8(m, 

Re: [systemd-devel] [PATCH] networkd: Add support for bond option.

[Tom Gundersen]

Sorry for the delay. Applied. Thanks!

Tom

On Mon, Mar 9, 2015 at 10:58 AM, Susant Sahani sus...@redhat.com wrote:
 This patch adds configurational support for bond option.

 Test conf:

 bond.netdev

 ---
 [NetDev]
 Name=bond1
 Kind=bond

 [Bond]
 ArpAllTargets=all
 PrimaryReselect=better
 ArpIntervalSec=10s
 ArpIpTargets= 192.168.8.102 192.168.8.101 192.168.8.102
 ---

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

 Bonding Mode: load balancing (round-robin)
 MII Status: up
 MII Polling Interval (ms): 0
 Up Delay (ms): 0
 Down Delay (ms): 0
 ARP Polling Interval (ms): 1
 ARP IP target/s (n.n.n.n form): 192.168.8.100, 192.168.8.101, 192.168.8.102
 ---
  man/systemd.netdev.xml  | 167 +
  src/libsystemd/sd-rtnl/rtnl-types.c |  26 ++-
  src/libsystemd/sd-rtnl/rtnl-types.h |  22 +++
  src/network/networkd-netdev-bond.c  | 318 
 +++-
  src/network/networkd-netdev-bond.h  |  85 -
  src/network/networkd-netdev-gperf.gperf |  13 ++
  6 files changed, 627 insertions(+), 4 deletions(-)

 diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
 index ef58887..4230d19 100644
 --- a/man/systemd.netdev.xml
 +++ b/man/systemd.netdev.xml
 @@ -647,7 +647,174 @@
  /listitem
/varlistentry

 +  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
 +
 +  varlistentry
 +termvarnameAdSelect=/varname/term
 +listitem
 +  paraSpecifies the 802.3ad aggregation selection logic to use. 
 Possible values are
 +  literalstable/literal,
 +  literalbandwidth/literal,
 +  literalcount/literal
 +  /para
 +/listitem
 +  /varlistentry
 +
 +  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
 +
 +  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
 +
 +  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
 +
 +  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
 +
 +  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
 +
 +  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 

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Tom Gundersen]

Hi Andy,

On Thu, Apr 16, 2015 at 2:55 AM, Andy Lutomirski l...@amacapital.net wrote:
 Yesterday, I discovered SD_BUS_VTABLE_CAPABILITY.  Are there any
 examples in which it does anything?

Please note that you need to be using kdbus to get any capabilities
transported, so in dbus1 this does nothing (as on dbus1 using
capabilities would be racy). Are you testing this on kdbus?

 If so, I don't suppose any of you
 could give me an example of:

 $ cp `which dbus-send` .
 $ sudo setcap all=eip dbus-send
 $ dbus-send [not sure what goes here]

 that passes an authentication test that would have failed without the setcap?

Note that dbus-send is the old dbus1 command, and will always go via
the bus proxy that connects dbus1 clients to kdbus. As such, it will
only carry the credentials that are available safely on dbus1, and
hence not capabilities. So even if you do use kdbus on your machine,
this example would not work.

To be clear, the reason we do not use the capability logic on dbus1,
but only on kdbus is as follows: On kdbus, the capabilities are
attached to the method call itself, hence we safely know that at the
time the method call was issued by the client side, that client
actually really had those capabilities. On dbus1 however, which uses
AF_UNIX/SOCK_STREAM, this is not possible: we only get the
UID/GID/PID, hence we could only derive the caps from
/proc/$PID/status. But this opens this up for a vulnerability: if a
client quickly issues a method call, and then exec()s a suid binary,
it could happen that the service side would read the capabilities from
that SUID process, and not the original process, and the exploit was
successful. We cannot allow that, hence no capabilities on dbus1,
instead we open up things to a much, much broader uid == 0. kdbus
allows us to be much stricter there, by allowing us to check only one
specific capability.

An equivalent example to the one you gave using native kdbus would be:

$ cp `which busctl` .
$ sudo setcap all=eip busctl
$ ./busctl call org.freedesktop.timedate1 /org/freedesktop/timedate1
org.freedesktop.timedate1 SetTimezone sb Europe/London 0

 In the interest of full disclosure, I'm asking because I think that
 one of two things is true:

 1. The SD_BUS_VTABLE_CAPABILITY code is useless and should therefore be 
 deleted.

This is not the case.

 2. The SD_BUS_VTABLE_CAPABILITY code is exploitably buggy and should
 therefore be deleted.

I have heard this claim from you many times, but so far I haven't been
able to figure out what you have in mind. Could you either give an
example of an exploit or at least the general scheme you have in mind?

Cheers,

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

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Tom Gundersen]

On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski l...@amacapital.net wrote:
 Unshare your user namespace, set things up right, and systemd
 or any other server will see you as having all capabilities.  You've
 fixed that in kdbus, but you haven't (and probably can't!) fix it in
 the legacy code, and that legacy code is still there (!).

The dbus1 code (which I assume you mean when you say legacy code)
does not make use of capabilities, and it should not (see Lennart's
answer for all the details). If anything, this should be an argument
to move to kdbus with native, race-free capability-passing support.

Do I understand correctly, that any concerns you had are about systemd
and its dbus1 compat code (which of course we should take seriously
too), and that you no longer see any security vulnerabilities in the
capability related code of kdbus?

 The ratio of complexity of capability code the kdbus folks have
 already written (hundreds of lines across multiple files) to its
 utility (very near zero AFAICT) is, in my book, not a good sign at
 all.

We have several uses of this, see my mail to Jiri regarding
CAP_SYS_BOOT for instance:
  https://lkml.org/lkml/2015/4/16/219

However, what we are trying to get to the bottom of is if you see any
technical problems with the current kdbus capability handling code. My
understanding is that you don't.

Cheers,

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

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Tom Gundersen]

On Thu, Apr 16, 2015 at 5:57 PM, Andy Lutomirski l...@amacapital.net wrote:
 We have several uses of this, see my mail to Jiri regarding
 CAP_SYS_BOOT for instance:
   https://lkml.org/lkml/2015/4/16/219

 I read that, but I disagree with you.

 CAP_SYS_BOOT is the privilege to directly hard-reboot the system, not
 the privilege to initiate a clean reboot.

My main point that being allowed to do a hard-reboot, but not to do a
clean reboot, makes no sense.

 However, what we are trying to get to the bottom of is if you see any
 technical problems with the current kdbus capability handling code. My
 understanding is that you don't.


 I have a technical problem with it: it's a design that has
 insufficient justification.  It also seems like it will be quite
 limiting in the future, *especially* wrt user namespaces.

What I was really asking was if you see any actual vulnerabilities.
That we have a different technical opinion on the design of this is a
different matter.

 I agree that it's probably not exploitable *if used carefully* in the
 latest kdbus code.

It would be very helpful if you could go into details on why you think
more care is needed here than for other things. Is there anything
non-trivial going on here that I'm missing? The way capabilites are
exposed through kdbus seems perfectly straight-forward to me, so I'm
really trying to get my head around your concerns here.

So, let me ask explicitly again:

* Are there any actual exploitable vulnerabilities you are aware
of in the kdbus kernel code?

* Are there any actual exploitable vulnerabilities on the sd-bus
userspace code you are aware of, regardless if in the kdbus or dbus1
support in it?

If you are, please provide us with good explanations, so that we can
do something about them. We'd love to fix this!

Cheers,

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

Re: [systemd-devel] [systemd-commits] 2 commits - src/libsystemd

[Tom Gundersen]

On Tue, Apr 14, 2015 at 4:21 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Apr 14, 2015 at 07:19:42AM -0700, Tom Gundersen wrote:
  src/libsystemd/sd-device/sd-device.c |9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

 New commits:
 commit 85091685af65831f379580c75b40776c20e245ee
 Author: Tom Gundersen t...@jklm.no
 Date:   Tue Apr 14 16:05:53 2015 +0200

 sd-device: fix reading of subsystem

 diff --git a/src/libsystemd/sd-device/sd-device.c 
 b/src/libsystemd/sd-device/sd-device.c
 index 7d52e3c..d420bd0 100644
 --- a/src/libsystemd/sd-device/sd-device.c
 +++ b/src/libsystemd/sd-device/sd-device.c
 @@ -772,10 +772,10 @@ _public_ int sd_device_get_subsystem(sd_device 
 *device, const char **ret) {
  r = device_set_subsystem(device, drivers);
  else if (path_startswith(device-devpath, /subsystem/) ||
   path_startswith(device-devpath, /class/) ||
 - path_startswith(device-devpath, /buss/))
 + path_startswith(device-devpath, /bus/))
  r = device_set_subsystem(device, subsystem);
  if (r  0)
 -return r;
 +return log_debug_errno(r, sd-devcie: could not set 
 subsystem for %s: %m, device-devpath);
  ^^

 Zbyszek

Thanks! Fixed.

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

Re: [systemd-devel] [RFC 1/6] proxy-discoveryd: Basic core added

[Tom Gundersen]

On Mon, Apr 13, 2015 at 12:05 PM, Tomasz Bursztyka
tomasz.burszt...@linux.intel.com wrote:
 +int manager_new(Manager **ret);
 +Manager *manager_free(Manager *m);
 +
 +DEFINE_TRIVIAL_CLEANUP_FUNC(Manager*, manager_free);
 +#define _cleanup_manager_free_ _cleanup_(manager_freep)

 We generally try to avoid this define in internal code, and just use
 _cleanup_(manager_freep) inline.


 Ok, I followed networkd but indeed other parts don't do that (machined for
 instance).

Do as I say, not as I do :P I didn't get the memo yet when I wrote the
initial networkd parts, I should fix this up to avoid confusion in the
future.

 diff --git a/units/.gitignore b/units/.gitignore
 index ad469c1..63ae1af 100644
 --- a/units/.gitignore
 +++ b/units/.gitignore
 @@ -51,6 +51,7 @@
   /systemd-networkd.service
   /systemd-nspawn@.service
   /systemd-poweroff.service
 +/systemd-proxy-discoveryd.service
   /systemd-quotacheck.service
   /systemd-random-seed.service
   /systemd-reboot.service
 diff --git a/units/systemd-proxy-discoveryd.service.in
 b/units/systemd-proxy-discoveryd.service.in
 new file mode 100644
 index 000..7ac02e0
 --- /dev/null
 +++ b/units/systemd-proxy-discoveryd.service.in
 @@ -0,0 +1,18 @@
 +# This file is part of systemd.
 +#
 +# systemd is free software; you can redistribute it and/or modify it
 +# under the terms of the GNU Lesser General Public License as published
 by
 +# the Free Software Foundation; either version 2.1 of the License, or
 +# (at your option) any later version.
 +
 +[Unit]
 +Description=Proxy service
 +DefaultDependencies=no
 +Requires=dbus.socket
 +After=dbus.socket
 +Before=remote-fs.target
 +
 +[Service]
 +Restart=on-failure
 +ExecStart=@rootlibexecdir@/systemd-proxy-discoveryd
 +StandardOutput=null

 Why this special handling of stdout? Is it the JS engine? Probably
 should have a comment as it is a bit odd.


 I copy-pasted the .service file we had for pacrunner, this needs to be
 tailored for proxy-discoveryd.

 The stdout directing to /dev/null is to avoid the JS engine to print
 anything.
 Though for duktape specifically, we can hook the debug/printing/warning/...
 functions, so we could
 redirect messages to the logs.

That's what I thought. Would be nice to hook this up properly
internally I think. Either to just redirect to /dev/null there, or to
log correctly.

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

Re: [systemd-devel] [systemd-commits] 2 commits - src/libsystemd

[Tom Gundersen]

On Sun, Apr 5, 2015 at 11:50 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 03.04.15 13:23, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:


 -tags = strdupa(value);
 +FOREACH_WORD_SEPARATOR(word, l, value, :, state) {
 +char *tag;

 -while ((next = strchr(tags, ':'))) {
 -next[0] = '\0';
 +tag = strndupa(word, l);


 Repeat after me: I shall not use alloca() within loops. I shall not
 use alloca() within loops. I shall not use alloca() within loops.

 This cannot work.

Fixed. Thanks!

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

Re: [systemd-devel] systemd from git doesn't boot properly in fedora rawhide

[Tom Gundersen]

On Fri, Apr 3, 2015 at 11:14 AM, Jan Synáček jsyna...@redhat.com wrote:
 From the following commit onward, systemd doesn't boot properly in
 Rawhide. Some device units time out and I'm then dropped into an
 emergency shell.

 commit f4ac4d1a82e2c468761fffa23841ad886221
 Author: Tom Gundersen t...@jklm.no
 Date:   Wed Apr 1 13:55:20 2015 +0200

 libudev: device - replace by a thin wrapper around sd-device

 All I can see is that a job is running for some of the device units and
 then it times out. Log from journalctl and one of the failed device
 units can be found at [1] and [2]. Any idea what might be wrong or how
 to debug this any further?

 [1] https://jsynacek.fedorapeople.org/systemd/journalctl.log
 [2] https://jsynacek.fedorapeople.org/systemd/device-unit.log

Thanks for the report. I'll try to reproduce.

Cheers,

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

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Tom Gundersen]

On Fri, Apr 3, 2015 at 4:47 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 02.04.15 13:11, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

 Dear systemd folks,


 some network cards with certain cables and devices take up to five
 seconds so that the link is up [1].

 $ sudo journalctl -u systemd-networkd
 -- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 2015-03-22 
 08:39:39 CET. --
 Mär 20 17:39:31 myhostname systemd-networkd[245]: lo  : 
 gained carrier
 Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0: 
 link configured
 Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0: 
 gained carrier

 This is annoying if the system is up, but you cannot log into a server
 because the NIC is so slow configuring the link.

 The Linux kernel module developers from the e1000-devel mailing list
 suggested the following [2]:

  Both sides either need to be forced or both sides need to be auto-neg.
  Otherwise the auto-negotiation process will usually detect link (the
  physical signal) but fail to find duplex (since one side is not
  talking) and default to the lowest common denominator, e.g. half
  duplex.  So, you could try forcing speed, it may look right on your
  end but if you have no visibility to the other end it could be running
  at half duplex.
 
  You may be able to speed up the auto negotiation process by
  exclusively advertising 1000 Mbps Full Duplex.
 
  # ethtool -s ethX advertise 0x20

 In the IRC channel #syst...@irc.freenode.net somebody told me to look
 into systemd’s network link configuration (`man systemd.link`).

 Reading the manual page, it’s not clear to me, if auto-negotiation is
 going to be disabled, if the following is set.

 BitsPerSecond=1G
 Duplex=Full

 Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
 could I set that up?

 BitsPerSecond= and Duplex= are equivalent to ethtool speed and
 ethtool duplex.

 We currently have no setting in .link files that was equivalent to
 ethtool advertise. Maybe we could add that, Tom?

 Paul, are you sure that this will really cut 5s from the configuration
 time? Did you try this?

No objections from me if it really cuts 5s as described.

Cheers,

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

[systemd-devel] [RFC][PATCH 1/2] libsystemd: add sd-device library

[Tom Gundersen]

This provides equivalent functionality to libudev-device, but in the
systemd style. The public API only caters to creating sd_device objects
from for devices that already exist in /sys, there is no support for
listening for monitoring uevents or creating devices received over
the udev netlink protocol.

The private API contains the necessary functionality to make sd-device
a drop-in replacement for libudev-device, but which we will not export
publicly.
---

Hi guys,

This is another step on the way of ripping out the bits of libudev that will
still be useful once the udev netlink transport has been replaced by kdbus.

Feedback welcome.

Cheers,

Tom

 Makefile.am|9 +-
 src/libsystemd/sd-device/device-internal.h |  125 ++
 src/libsystemd/sd-device/device-private.c  | 1101 +
 src/libsystemd/sd-device/device-private.h  |   63 +
 src/libsystemd/sd-device/device-util.h |   48 +
 src/libsystemd/sd-device/sd-device.c   | 1812 
 src/systemd/sd-device.h|   77 ++
 7 files changed, 3234 insertions(+), 1 deletion(-)
 create mode 100644 src/libsystemd/sd-device/device-internal.h
 create mode 100644 src/libsystemd/sd-device/device-private.c
 create mode 100644 src/libsystemd/sd-device/device-private.h
 create mode 100644 src/libsystemd/sd-device/device-util.h
 create mode 100644 src/libsystemd/sd-device/sd-device.c
 create mode 100644 src/systemd/sd-device.h

diff --git a/Makefile.am b/Makefile.am
index 93fdbc2..9509247 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -231,6 +231,7 @@ AM_CPPFLAGS = \
-I $(top_srcdir)/src/libsystemd/sd-rtnl \
-I $(top_srcdir)/src/libsystemd/sd-network \
-I $(top_srcdir)/src/libsystemd/sd-hwdb \
+   -I $(top_srcdir)/src/libsystemd/sd-device \
-I $(top_srcdir)/src/libsystemd-network \
-I $(top_srcdir)/src/libsystemd-terminal \
$(OUR_CPPFLAGS)
@@ -2918,6 +2919,7 @@ libsystemd_internal_la_SOURCES = \
src/systemd/sd-path.h \
src/systemd/sd-network.h \
src/systemd/sd-hwdb.h \
+   src/systemd/sd-device.h \
src/libsystemd/sd-bus/sd-bus.c \
src/libsystemd/sd-bus/bus-control.c \
src/libsystemd/sd-bus/bus-control.h \
@@ -2981,7 +2983,12 @@ libsystemd_internal_la_SOURCES = \
src/libsystemd/sd-network/network-util.c \
src/libsystemd/sd-hwdb/sd-hwdb.c \
src/libsystemd/sd-hwdb/hwdb-util.h \
-   src/libsystemd/sd-hwdb/hwdb-internal.h
+   src/libsystemd/sd-hwdb/hwdb-intenal.h \
+   src/libsystemd/sd-device/device-internal.h \
+   src/libsystemd/sd-device/device-util.h \
+   src/libsystemd/sd-device/sd-device.c \
+   src/libsystemd/sd-device/device-private.c \
+   src/libsystemd/sd-device/device-private.h
 
 nodist_libsystemd_internal_la_SOURCES = \
src/libsystemd/libsystemd.sym
diff --git a/src/libsystemd/sd-device/device-internal.h 
b/src/libsystemd/sd-device/device-internal.h
new file mode 100644
index 000..59ec1a6
--- /dev/null
+++ b/src/libsystemd/sd-device/device-internal.h
@@ -0,0 +1,125 @@
+/***
+  This file is part of systemd.
+
+  Copyright 2008-2012 Kay Sievers k...@vrfy.org
+  Copyright 2014 Tom Gundersen t...@jklm.no
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#pragma once
+
+#include hashmap.h
+#include set.h
+
+struct sd_device {
+uint64_t n_ref;
+
+sd_device *parent;
+bool parent_set; /* no need to try to reload parent */
+
+OrderedHashmap *properties;
+Iterator properties_iterator;
+uint64_t properties_generation; /* changes whenever the properties are 
changed */
+uint64_t properties_iterator_generation; /* generation when iteration 
was started */
+
+/* the subset of the properties that should be written to the db*/
+OrderedHashmap *properties_db;
+
+Hashmap *sysattr_values; /* cached sysattr values */
+
+Set *sysattrs; /* names of sysattrs */
+Iterator sysattrs_iterator;
+bool sysattrs_read; /* don't try to re-read sysattrs once read */
+
+Set *tags;
+Iterator tags_iterator;
+uint64_t tags_generation; /* changes whenever the tags are changed */
+uint64_t tags_iterator_generation; /* generation when iteration was 
started */
+bool property_tags_outdated; /* need to update

[systemd-devel] [RFC][PATCH 2/2] libudev: device - replace by a thin wrapper around sd-device

[Tom Gundersen]

 = \
src/network/networkctl.c
 
 networkctl_LDADD = \
-   libsystemd-internal.la \
libudev-internal.la \
+   libsystemd-internal.la \
libsystemd-shared.la \
libsystemd-network.la
 
@@ -5905,8 +5918,8 @@ libsystemd_logind_core_la_SOURCES = \
 
 libsystemd_logind_core_la_LIBADD = \
libsystemd-label.la \
-   libsystemd-internal.la \
libudev-internal.la \
+   libsystemd-internal.la \
libsystemd-shared.la
 
 if HAVE_ACL
@@ -5929,10 +5942,10 @@ loginctl_SOURCES = \
src/login/sysfs-show.c
 
 loginctl_LDADD = \
+   libudev-internal.la \
libsystemd-internal.la \
libsystemd-logs.la \
libsystemd-journal-internal.la \
-   libudev-internal.la \
libsystemd-shared.la
 
 rootbin_PROGRAMS += \
diff --git a/src/libudev/libudev-device-internal.h 
b/src/libudev/libudev-device-internal.h
new file mode 100644
index 000..18ae7a9
--- /dev/null
+++ b/src/libudev/libudev-device-internal.h
@@ -0,0 +1,62 @@
+/***
+  This file is part of systemd.
+
+  Copyright 2008-2012 Kay Sievers k...@vrfy.org
+  Copyright 2015 Tom Gundersen t...@jklm.no
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#pragma once
+
+#include libudev.h
+#include sd-device.h
+
+/**
+ * udev_device:
+ *
+ * Opaque object representing one kernel sys device.
+ */
+struct udev_device {
+struct udev *udev;
+
+/* real device object */
+sd_device *device;
+
+/* legacy */
+int refcount;
+
+struct udev_device *parent;
+bool parent_set;
+
+struct udev_list properties;
+uint64_t properties_generation;
+struct udev_list tags;
+uint64_t tags_generation;
+struct udev_list devlinks;
+uint64_t devlinks_generation;
+struct udev_list sysattrs;
+bool sysattrs_read;
+};
+
+struct udev_device *udev_device_new(struct udev *udev);
+
+#define assert_return_errno(expr, r, err)   \
+do {\
+if (_unlikely_(!(expr))) {  \
+log_assert_failed_return(#expr, __FILE__, __LINE__, 
__PRETTY_FUNCTION__); \
+errno = err;\
+return (r); \
+}   \
+} while (false)
diff --git a/src/libudev/libudev-device-private.c 
b/src/libudev/libudev-device-private.c
index e590288..bb4d7e6 100644
--- a/src/libudev/libudev-device-private.c
+++ b/src/libudev/libudev-device-private.c
@@ -2,6 +2,7 @@
   This file is part of systemd.
 
   Copyright 2008-2012 Kay Sievers k...@vrfy.org
+  Copyright 2015 Tom Gundersen t...@jklm.no
 
   systemd is free software; you can redistribute it and/or modify it
   under the terms of the GNU Lesser General Public License as published by
@@ -17,172 +18,392 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
-#include stdio.h
-#include string.h
-#include stddef.h
-#include stdbool.h
-#include unistd.h
-#include fcntl.h
-#include sys/stat.h
-
 #include libudev.h
 #include libudev-private.h
+#include libudev-device-internal.h
+
+#include device-private.h
+
+int udev_device_tag_index(struct udev_device *udev_device, struct udev_device 
*udev_device_old, bool add) {
+sd_device *device_old = NULL;
+int r;
+
+assert(udev_device);
+
+if (udev_device_old)
+device_old = udev_device_old-device;
+
+r = device_tag_index(udev_device-device, device_old, add);
+if (r  0)
+return r;
+
+return 0;
+}
+
+int udev_device_update_db(struct udev_device *udev_device) {
+int r;
+
+assert(udev_device);
+
+r = device_update_db(udev_device-device);
+if (r  0)
+return r;
+
+return 0;
+}
+
+int udev_device_delete_db(struct udev_device *udev_device) {
+int r;
+
+assert(udev_device);
+
+r = device_delete_db(udev_device-device);
+if (r  0)
+return r;
+
+return 0;
+}
+
+int udev_device_get_ifindex(struct udev_device *udev_device) {
+int r, ifindex;
+
+assert(udev_device);
+
+r = sd_device_get_ifindex

[systemd-devel] [RFC][PATCH] udev: net_id - support multi-function, multi-port enpo* device names

[Tom Gundersen]

I'd argue that having firmware labels for such devices makes no sense, but they 
exist, so make sure
we handle them as best as we can.
---
 src/udev/udev-builtin-net_id.c | 64 --
 1 file changed, 43 insertions(+), 21 deletions(-)

diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index 71f3a59..1a72190 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -35,7 +35,7 @@
  * Type of names:
  *   bnumber -- BCMA bus core number
  *   ccwname -- CCW bus group name
- *   oindex  -- on-board device index number
+ *   oindex[ffunction][ddev_port]-- on-board device index number
  *   sslot[ffunction][ddev_port] -- hotplug slot index number
  *   xMAC-- MAC address
  *   [Pdomain]pbussslot[ffunction][ddev_port]
@@ -126,11 +126,38 @@ struct netnames {
 char ccw_group[IFNAMSIZ];
 };
 
+/* read the 256 bytes PCI configuration space to check the multi-function bit 
*/
+static bool is_pci_multifunction(struct udev_device *dev) {
+_cleanup_fclose_ FILE *f = NULL;
+const char *filename;
+uint8_t config[64];
+
+filename = strjoina(udev_device_get_syspath(dev), /config);
+f = fopen(filename, re);
+if (!f)
+return false;
+if (fread(config, sizeof(config), 1, f) != 1)
+return false;
+
+/* bit 0-6 header type, bit 7 multi/single function device */
+if ((config[PCI_HEADER_TYPE]  0x80) != 0)
+return true;
+
+return false;
+}
+
 /* retrieve on-board index number and label from firmware */
 static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
+unsigned func, dev_port = 0;
+size_t l;
+char *s;
+const char *attr;
 const char *index;
 int idx;
 
+if (sscanf(udev_device_get_sysname(names-pcidev), %*x:%*x:%*x.%u, 
func) != 1)
+return -ENOENT;
+
 /* ACPI _DSM  -- device specific method for naming a PCI or PCI 
Express device */
 index = udev_device_get_sysattr_value(names-pcidev, acpi_index);
 /* SMBIOS type 41 -- Onboard Devices Extended Information */
@@ -141,30 +168,25 @@ static int dev_pci_onboard(struct udev_device *dev, 
struct netnames *names) {
 idx = strtoul(index, NULL, 0);
 if (idx = 0)
 return -EINVAL;
-snprintf(names-pci_onboard, sizeof(names-pci_onboard), o%d, idx);
 
-names-pci_onboard_label = 
udev_device_get_sysattr_value(names-pcidev, label);
-return 0;
-}
-
-/* read the 256 bytes PCI configuration space to check the multi-function bit 
*/
-static bool is_pci_multifunction(struct udev_device *dev) {
-_cleanup_fclose_ FILE *f = NULL;
-const char *filename;
-uint8_t config[64];
+/* kernel provided multi-device index */
+attr = udev_device_get_sysattr_value(dev, dev_port);
+if (attr)
+dev_port = strtol(attr, NULL, 10);
 
-filename = strjoina(udev_device_get_syspath(dev), /config);
-f = fopen(filename, re);
-if (!f)
-return false;
-if (fread(config, sizeof(config), 1, f) != 1)
-return false;
+s = names-pci_onboard;
+l = sizeof(names-pci_onboard);
+l = strpcpyf(s, l, o%d, idx);
+if (func  0 || is_pci_multifunction(names-pcidev))
+l = strpcpyf(s, l, f%d, func);
+if (dev_port  0)
+l = strpcpyf(s, l, d%d, dev_port);
+if (l == 0)
+names-pci_onboard[0] = '\0';
 
-/* bit 0-6 header type, bit 7 multi/single function device */
-if ((config[PCI_HEADER_TYPE]  0x80) != 0)
-return true;
+names-pci_onboard_label = 
udev_device_get_sysattr_value(names-pcidev, label);
 
-return false;
+return 0;
 }
 
 static int dev_pci_slot(struct udev_device *dev, struct netnames *names) {
-- 
2.3.4

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

Re: [systemd-devel] [RFC][PATCH 1/2] libsystemd: add sd-device library

[Tom Gundersen]

After discussing this with Kay, I went ahead and pushed this. Feedback
still welcome of course.

Cheers,

Tom

On Wed, Apr 1, 2015 at 3:00 PM, Tom Gundersen t...@jklm.no wrote:
 This provides equivalent functionality to libudev-device, but in the
 systemd style. The public API only caters to creating sd_device objects
 from for devices that already exist in /sys, there is no support for
 listening for monitoring uevents or creating devices received over
 the udev netlink protocol.

 The private API contains the necessary functionality to make sd-device
 a drop-in replacement for libudev-device, but which we will not export
 publicly.
 ---

 Hi guys,

 This is another step on the way of ripping out the bits of libudev that will
 still be useful once the udev netlink transport has been replaced by kdbus.

 Feedback welcome.

 Cheers,

 Tom

  Makefile.am|9 +-
  src/libsystemd/sd-device/device-internal.h |  125 ++
  src/libsystemd/sd-device/device-private.c  | 1101 +
  src/libsystemd/sd-device/device-private.h  |   63 +
  src/libsystemd/sd-device/device-util.h |   48 +
  src/libsystemd/sd-device/sd-device.c   | 1812 
 
  src/systemd/sd-device.h|   77 ++
  7 files changed, 3234 insertions(+), 1 deletion(-)
  create mode 100644 src/libsystemd/sd-device/device-internal.h
  create mode 100644 src/libsystemd/sd-device/device-private.c
  create mode 100644 src/libsystemd/sd-device/device-private.h
  create mode 100644 src/libsystemd/sd-device/device-util.h
  create mode 100644 src/libsystemd/sd-device/sd-device.c
  create mode 100644 src/systemd/sd-device.h

 diff --git a/Makefile.am b/Makefile.am
 index 93fdbc2..9509247 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -231,6 +231,7 @@ AM_CPPFLAGS = \
 -I $(top_srcdir)/src/libsystemd/sd-rtnl \
 -I $(top_srcdir)/src/libsystemd/sd-network \
 -I $(top_srcdir)/src/libsystemd/sd-hwdb \
 +   -I $(top_srcdir)/src/libsystemd/sd-device \
 -I $(top_srcdir)/src/libsystemd-network \
 -I $(top_srcdir)/src/libsystemd-terminal \
 $(OUR_CPPFLAGS)
 @@ -2918,6 +2919,7 @@ libsystemd_internal_la_SOURCES = \
 src/systemd/sd-path.h \
 src/systemd/sd-network.h \
 src/systemd/sd-hwdb.h \
 +   src/systemd/sd-device.h \
 src/libsystemd/sd-bus/sd-bus.c \
 src/libsystemd/sd-bus/bus-control.c \
 src/libsystemd/sd-bus/bus-control.h \
 @@ -2981,7 +2983,12 @@ libsystemd_internal_la_SOURCES = \
 src/libsystemd/sd-network/network-util.c \
 src/libsystemd/sd-hwdb/sd-hwdb.c \
 src/libsystemd/sd-hwdb/hwdb-util.h \
 -   src/libsystemd/sd-hwdb/hwdb-internal.h
 +   src/libsystemd/sd-hwdb/hwdb-intenal.h \
 +   src/libsystemd/sd-device/device-internal.h \
 +   src/libsystemd/sd-device/device-util.h \
 +   src/libsystemd/sd-device/sd-device.c \
 +   src/libsystemd/sd-device/device-private.c \
 +   src/libsystemd/sd-device/device-private.h

  nodist_libsystemd_internal_la_SOURCES = \
 src/libsystemd/libsystemd.sym
 diff --git a/src/libsystemd/sd-device/device-internal.h 
 b/src/libsystemd/sd-device/device-internal.h
 new file mode 100644
 index 000..59ec1a6
 --- /dev/null
 +++ b/src/libsystemd/sd-device/device-internal.h
 @@ -0,0 +1,125 @@
 +/***
 +  This file is part of systemd.
 +
 +  Copyright 2008-2012 Kay Sievers k...@vrfy.org
 +  Copyright 2014 Tom Gundersen t...@jklm.no
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as published by
 +  the Free Software Foundation; either version 2.1 of the License, or
 +  (at your option) any later version.
 +
 +  systemd is distributed in the hope that it will be useful, but
 +  WITHOUT ANY WARRANTY; without even the implied warranty of
 +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public License
 +  along with systemd; If not, see http://www.gnu.org/licenses/.
 +***/
 +
 +#pragma once
 +
 +#include hashmap.h
 +#include set.h
 +
 +struct sd_device {
 +uint64_t n_ref;
 +
 +sd_device *parent;
 +bool parent_set; /* no need to try to reload parent */
 +
 +OrderedHashmap *properties;
 +Iterator properties_iterator;
 +uint64_t properties_generation; /* changes whenever the properties 
 are changed */
 +uint64_t properties_iterator_generation; /* generation when 
 iteration was started */
 +
 +/* the subset of the properties that should be written to the db*/
 +OrderedHashmap *properties_db;
 +
 +Hashmap *sysattr_values; /* cached sysattr values */
 +
 +Set *sysattrs; /* names of sysattrs */
 +Iterator sysattrs_iterator;
 +bool sysattrs_read; /* don't try to re-read sysattrs

Re: [systemd-devel] [RFC][PATCH] udev: net_id - support multi-function, multi-port enpo* device names

[Tom Gundersen]

I pushed a version of this only handling the multi-port devices. We
can deal with multi-function if and when they appear in the wild.

-t

On Wed, Apr 1, 2015 at 4:52 PM, Tom Gundersen t...@jklm.no wrote:
 I'd argue that having firmware labels for such devices makes no sense, but 
 they exist, so make sure
 we handle them as best as we can.
 ---
  src/udev/udev-builtin-net_id.c | 64 
 --
  1 file changed, 43 insertions(+), 21 deletions(-)

 diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
 index 71f3a59..1a72190 100644
 --- a/src/udev/udev-builtin-net_id.c
 +++ b/src/udev/udev-builtin-net_id.c
 @@ -35,7 +35,7 @@
   * Type of names:
   *   bnumber -- BCMA bus core number
   *   ccwname -- CCW bus group name
 - *   oindex  -- on-board device index number
 + *   oindex[ffunction][ddev_port]-- on-board device index number
   *   sslot[ffunction][ddev_port] -- hotplug slot index number
   *   xMAC-- MAC address
   *   [Pdomain]pbussslot[ffunction][ddev_port]
 @@ -126,11 +126,38 @@ struct netnames {
  char ccw_group[IFNAMSIZ];
  };

 +/* read the 256 bytes PCI configuration space to check the multi-function 
 bit */
 +static bool is_pci_multifunction(struct udev_device *dev) {
 +_cleanup_fclose_ FILE *f = NULL;
 +const char *filename;
 +uint8_t config[64];
 +
 +filename = strjoina(udev_device_get_syspath(dev), /config);
 +f = fopen(filename, re);
 +if (!f)
 +return false;
 +if (fread(config, sizeof(config), 1, f) != 1)
 +return false;
 +
 +/* bit 0-6 header type, bit 7 multi/single function device */
 +if ((config[PCI_HEADER_TYPE]  0x80) != 0)
 +return true;
 +
 +return false;
 +}
 +
  /* retrieve on-board index number and label from firmware */
  static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
 +unsigned func, dev_port = 0;
 +size_t l;
 +char *s;
 +const char *attr;
  const char *index;
  int idx;

 +if (sscanf(udev_device_get_sysname(names-pcidev), %*x:%*x:%*x.%u, 
 func) != 1)
 +return -ENOENT;
 +
  /* ACPI _DSM  -- device specific method for naming a PCI or PCI 
 Express device */
  index = udev_device_get_sysattr_value(names-pcidev, acpi_index);
  /* SMBIOS type 41 -- Onboard Devices Extended Information */
 @@ -141,30 +168,25 @@ static int dev_pci_onboard(struct udev_device *dev, 
 struct netnames *names) {
  idx = strtoul(index, NULL, 0);
  if (idx = 0)
  return -EINVAL;
 -snprintf(names-pci_onboard, sizeof(names-pci_onboard), o%d, idx);

 -names-pci_onboard_label = 
 udev_device_get_sysattr_value(names-pcidev, label);
 -return 0;
 -}
 -
 -/* read the 256 bytes PCI configuration space to check the multi-function 
 bit */
 -static bool is_pci_multifunction(struct udev_device *dev) {
 -_cleanup_fclose_ FILE *f = NULL;
 -const char *filename;
 -uint8_t config[64];
 +/* kernel provided multi-device index */
 +attr = udev_device_get_sysattr_value(dev, dev_port);
 +if (attr)
 +dev_port = strtol(attr, NULL, 10);

 -filename = strjoina(udev_device_get_syspath(dev), /config);
 -f = fopen(filename, re);
 -if (!f)
 -return false;
 -if (fread(config, sizeof(config), 1, f) != 1)
 -return false;
 +s = names-pci_onboard;
 +l = sizeof(names-pci_onboard);
 +l = strpcpyf(s, l, o%d, idx);
 +if (func  0 || is_pci_multifunction(names-pcidev))
 +l = strpcpyf(s, l, f%d, func);
 +if (dev_port  0)
 +l = strpcpyf(s, l, d%d, dev_port);
 +if (l == 0)
 +names-pci_onboard[0] = '\0';

 -/* bit 0-6 header type, bit 7 multi/single function device */
 -if ((config[PCI_HEADER_TYPE]  0x80) != 0)
 -return true;
 +names-pci_onboard_label = 
 udev_device_get_sysattr_value(names-pcidev, label);

 -return false;
 +return 0;
  }

  static int dev_pci_slot(struct udev_device *dev, struct netnames *names) {
 --
 2.3.4

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

Re: [systemd-devel] [PATCH] nspawn: fallback on bind mount when mknod fails

[Tom Gundersen]

On Mar 29, 2015 5:18 PM, Alban Crequy alban.cre...@gmail.com wrote:

 From: Alban Crequy al...@endocode.com

 Some systems abusively restrict mknod, even when the device node already
 exists in /dev. This is unfortunate because it prevents systemd-nspawn
 from creating the basic devices in /dev in the container.

 This patch implements a workaround: when mknod fails, fallback on bind
 mounts.

Could we just always use bind mounts and avoid the two code paths?

Tom

 Additionally, /dev/console was created with a mknod with the same
 major/minor as /dev/null before bind mounting a pts on it. This patch
 removes the mknod and creates an empty regular file instead.

 In order to test this patch, I used the following configuration, which I
 think should replicate the system with the abusive restriction on mknod:

   # grep devices /proc/self/cgroup
   4:devices:/user.slice/restrict
   # cat /sys/fs/cgroup/devices/user.slice/restrict/devices.list
   c 1:9 r
   c 5:2 rw
   c 136:* rw
   # systemd-nspawn --register=false -D .
 ---
  src/nspawn/nspawn.c | 27 ++-
  1 file changed, 14 insertions(+), 13 deletions(-)

 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
 index 300b6df..09fff38 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -1449,8 +1449,17 @@ static int copy_devnodes(const char *dest) {
  return -r;
  }

 -if (mknod(to, st.st_mode, st.st_rdev)  0)
 -return log_error_errno(errno, mknod(%s)
failed: %m, to);
 +if (mknod(to, st.st_mode, st.st_rdev)  0) {
 +if (errno != EPERM)
 +return log_error_errno(errno,
mknod(%s) failed: %m, to);
 +
 +/* Some systems abusively restrict mknod
but
 + * allow bind mounts. */
 +if (touch(to)  0)
 +return log_error_errno(errno,
touch (%s) failed: %m, to);
 +if (mount(from, to, bind, MS_BIND,
NULL)  0)
 +return log_error_errno(errno,
both mknod and bind mount (%s) failed: %m, to);
 +}

  if (arg_userns  arg_uid_shift != UID_INVALID)
  if (lchown(to, arg_uid_shift,
arg_uid_shift)  0)
 @@ -1481,7 +1490,6 @@ static int setup_ptmx(const char *dest) {
  static int setup_dev_console(const char *dest, const char *console) {
  _cleanup_umask_ mode_t u;
  const char *to;
 -struct stat st;
  int r;

  assert(dest);
 @@ -1489,24 +1497,17 @@ static int setup_dev_console(const char *dest,
const char *console) {

  u = umask();

 -if (stat(/dev/null, st)  0)
 -return log_error_errno(errno, Failed to stat /dev/null:
%m);
 -
  r = chmod_and_chown(console, 0600, 0, 0);
  if (r  0)
  return log_error_errno(r, Failed to correct access mode
for TTY: %m);

  /* We need to bind mount the right tty to /dev/console since
   * ptys can only exist on pts file systems. To have something
 - * to bind mount things on we create a device node first, and
 - * use /dev/null for that since we the cgroups device policy
 - * allows us to create that freely, while we cannot create
 - * /dev/console. (Note that the major minor doesn't actually
 - * matter here, since we mount it over anyway). */
 + * to bind mount things on we create a empty regular file. */

  to = strjoina(dest, /dev/console);
 -if (mknod(to, (st.st_mode  ~0) | 0600, st.st_rdev)  0)
 -return log_error_errno(errno, mknod() for /dev/console
failed: %m);
 +if (touch(to)  0)
 +return log_error_errno(errno, touch() for /dev/console
failed: %m);

  if (mount(console, to, bind, MS_BIND, NULL)  0)
  return log_error_errno(errno, Bind mount for
/dev/console failed: %m);
 --
 2.1.4

 ___
 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] automount: add expire support

[Tom Gundersen]

Looks nice. Minor nitpicks below.

On Sun, Mar 22, 2015 at 1:36 PM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
 ---
  man/systemd.automount.xml |   8 ++
  man/systemd.mount.xml |   9 ++
  src/core/automount.c  | 209 
 --
  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 |  27 +
  8 files changed, 253 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 cec90cbb319d..d2c148943e0f 100644
 --- a/src/core/automount.c
 +++ b/src/core/automount.c
 @@ -40,6 +40,7 @@
  #include dbus-automount.h
  #include bus-util.h
  #include bus-error.h
 +#include async.h

  static const UnitActiveState state_translation_table[_AUTOMOUNT_STATE_MAX] = 
 {
  [AUTOMOUNT_DEAD] = UNIT_INACTIVE,
 @@ -79,13 +80,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);
 @@ -110,6 +114,8 @@ static void automount_done(Unit *u) {

  set_free(a-tokens);
  a-tokens = NULL;
 +set_free(a-expire_tokens);
 +a-expire_tokens = NULL;
  }

  static int automount_add_mount_links(Automount *a) {
 @@ -263,6 +269,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);
 @@ -271,11 +278,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, automount_result_to_string(a-result),
  prefix, a-where,
 -prefix, a-directory_mode);
 +prefix, a-directory_mode,
 +prefix, format_timespan(time_string, FORMAT_TIMESPAN_MAX, 
 a-timeout_idle_usec, USEC_PER_SEC));
  }

  static void automount_enter_dead(Automount *a, AutomountResult f) {
 @@ -365,7 +374,7 @@ static int autofs_protocol(int dev_autofs_fd, int 
 ioctl_fd) {
  return 0;
  }

 -static int autofs_set_timeout(int dev_autofs_fd, int ioctl_fd, time_t sec) {
 +static int autofs_set_timeout(int dev_autofs_fd, int ioctl_fd, usec_t usec) {
  struct autofs_dev_ioctl param;

  assert(dev_autofs_fd = 0);
 @@ -373,7 +382,9 @@ static int autofs_set_timeout(int dev_autofs_fd, int 
 ioctl_fd, time_t sec) {

  init_autofs_dev_ioctl(param);
  param.ioctlfd = ioctl_fd;
 -param.timeout.timeout = sec;
 +
 +/* Convert to seconds, 

Re: [systemd-devel] [PATCH 3/3] networkd-dhcp6: Do not handle prefix expiry

[Tom Gundersen]

On Wed, Mar 25, 2015 at 2:37 PM, Patrik Flykt
patrik.fl...@linux.intel.com wrote:
 Expiring prefixes need not be handled anymore as the kernel has been
 instructed not to create routes for DHCPv6 assigned addresses via the
 IFA_F_NOPREFIXROUTE flag.

Great stuff. Please push all three!

-t

 ---
  src/network/networkd-dhcp6.c | 42 +-
  1 file changed, 1 insertion(+), 41 deletions(-)

 diff --git a/src/network/networkd-dhcp6.c b/src/network/networkd-dhcp6.c
 index 283a7d6..e863f4b 100644
 --- a/src/network/networkd-dhcp6.c
 +++ b/src/network/networkd-dhcp6.c
 @@ -86,42 +86,6 @@ static int dhcp6_address_update(Link *link, struct 
 in6_addr *ip6_addr,
  return r;
  }

 -static int dhcp6_prefix_expired(Link *link) {
 -int r;
 -sd_dhcp6_lease *lease;
 -struct in6_addr *expired_prefix, ip6_addr;
 -uint8_t expired_prefixlen;
 -uint32_t lifetime_preferred, lifetime_valid;
 -
 -r = sd_icmp6_ra_get_expired_prefix(link-icmp6_router_discovery,
 -expired_prefix, expired_prefixlen);
 -if (r  0)
 -return r;
 -
 -r = sd_dhcp6_client_get_lease(link-dhcp6_client, lease);
 -if (r  0)
 -return r;
 -
 -sd_dhcp6_lease_reset_address_iter(lease);
 -
 -while (sd_dhcp6_lease_get_address(lease, ip6_addr,
 -lifetime_preferred,
 -lifetime_valid) = 0) {
 -
 -r = sd_icmp6_prefix_match(expired_prefix, expired_prefixlen,
 -ip6_addr);
 -if (r = 0) {
 -r = dhcp6_address_update(link, ip6_addr, 128,
 -lifetime_preferred,
 -lifetime_valid);
 -
 -return r;
 -}
 -}
 -
 -return 0;
 -}
 -
  static int dhcp6_lease_address_acquired(sd_dhcp6_client *client, Link *link) 
 {
  int r;
  sd_dhcp6_lease *lease;
 @@ -310,6 +274,7 @@ static void icmp6_router_handler(sd_icmp6_nd *nd, int 
 event, void *userdata) {

  switch(event) {
  case ICMP6_EVENT_ROUTER_ADVERTISMENT_NONE:
 +case ICMP6_EVENT_ROUTER_ADVERTISMENT_PREFIX_EXPIRED:
  return;

  case ICMP6_EVENT_ROUTER_ADVERTISMENT_TIMEOUT:
 @@ -319,11 +284,6 @@ static void icmp6_router_handler(sd_icmp6_nd *nd, int 
 event, void *userdata) {

  break;

 -case ICMP6_EVENT_ROUTER_ADVERTISMENT_PREFIX_EXPIRED:
 -dhcp6_prefix_expired(link);
 -
 -break;
 -
  default:
  if (event  0)
  log_link_warning(link, ICMPv6 error: %s,
 --
 2.1.4

 ___
 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] Providing DNS for DHCPServer configuration

[Tom Gundersen]

Hi Ash,

We do want some functionality like this. However, I don't think we
should simply default to assuming the DHCP server is also a DNS
server. The way it should work is to pass to the client all the (non
restricted, i.e., where Domains= is not set, or includes the wildcard)
DNS servers configured for the host.

That has the restriction that any DNS server you want to pass on to
the client must also be a valid DNS server on the server. Which I
think is fine.

Makes sense?

Cheers,

Tom

On Wed, Mar 25, 2015 at 1:44 AM, Ash Charles ashchar...@gmail.com wrote:
 Hi,

 I'm using the DHCPServer option within systemd-networkd along with
 hostapd to provide a basic wireless access point on an embedded
 system.  When my client systems connect, they make a DHCP request that
 includes a parameter request for a Domain Name Server (option
 6)---standard fare I think.  The DHCPAck/DHCPOffer from
 systemd-network doesn't provide a response to this part of the request
 so the client needs to manually configure a DNS server.  I created a
 rudimentary patch (attached) that uses the access point IP as the DNS
 server---seems to work okay for my particular use case though I
 recognize this is *far* from generic.

 Is there 1. a different/better way of doing this and, 2. if not, is
 such a feature desirable for systemd-networkd/what might a good
 implementation look like?

 Thanks for any inights!
 --Ash

 ___
 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] timedatectl: check for getenv(TZDIR)

[Tom Gundersen]

Hi Shawn,

Could you redo the commit message to explain what's going on here?
I.e., what ends up being 'wrong' when we ignore TZDIR? Maybe also make
this clearer in the warning.

-t

On Tue, Mar 24, 2015 at 8:02 PM, Shawn Landden sh...@churchofgit.com wrote:
 I liked having the DST information. It is a pity glibc doesn't export
 this information.

 v3
 ---
  src/timedate/timedatectl.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
 index ab5c8a1..d529a0a 100644
 --- a/src/timedate/timedatectl.c
 +++ b/src/timedate/timedatectl.c
 @@ -88,6 +88,11 @@ static void print_status_info(const StatusInfo *i) {
  unsetenv(TZ);
  }

 +if (getenv(TZDIR)) {
 +fprintf(stderr, Warning: Ignoring the TZDIR variable.\n\n);
 +unsetenv(TZDIR);
 +}
 +
  r = setenv(TZ, i-timezone, false);
  if (r  0) {
  log_error_errno(errno, Failed to set TZ environment 
 variable: %m);
 --
 2.2.1.209.g41e5f3a

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

Re: [systemd-devel] [PATCH 2/2] macro: allow assert_se() assertions to also be optimized out when NDEBUG is set

[Tom Gundersen]

On Fri, Mar 27, 2015 at 2:04 PM, Djalal Harouni tix...@opendz.org wrote:
 Hi Shawn,

 On Thu, Mar 26, 2015 at 11:21:54PM -0700, Shawn Landden wrote:
 On Thu, Mar 26, 2015 at 5:47 PM, Djalal Harouni tix...@opendz.org wrote:
  On Fri, Mar 27, 2015 at 12:30:53AM +0100, Tom Gundersen wrote:
  On Thu, Mar 26, 2015 at 9:19 AM, Lennart Poettering
  lenn...@poettering.net wrote:
   On Tue, 24.03.15 11:11, Shawn Landden (sh...@churchofgit.com) wrote:
  
   Will result in slightly smaller binaries, and cuts out the branch, 
   even if
   the expression is still executed.
  
   I am sorry, but the whole point of assert_se() is that it has side
   effects. That's why it is called that way (the se suffix stands for
   side effects), and is different from assert(). You are supposed to
   use it whenever the code enclosed in it shall not be suppressed if
   NDEBUG is defined. This patch of yours breaks that whole logic!
 
  Hm, am I reading the patch wrong? It looks good to me. It is simply
  dropping the branching and logging in the NDEBUG case, but the
  expression itself is still evaluated.
  Yep but it seems that abort() will never be called,
  log_assert_failed() = abort()
 
  And the logging mechanism is also one of those side effects. IMO unless
  there are real valid reasons for any change to these macors... changing
  anything here will just bring more bugs that we may never notice.
 
 Those are the side effects of assert(), the side effects of the
 expression are still evaluated.
 Yes but there are also the following points:
 * assert() is simple, assert_se() is more complex and it may modify other
 global sate. I don't think that we can break down side effects of
 assert_se() into:
  1) side effects of assert()
  2) side effects of other expressions.

 And then remove that part 1)


 So given the fact that asser_se() do not depend on NDEBUG, did you
 consider the following:

 * You don't have control over what the expression do, it may just call
   abort() or exit() in case of fatal errors, so even if you remove the
   explicit abort() call, expressions may just call it.

If expr() aborts or exits, then it really does not matter whether we
abort() explicitly or not, so I don't see what this has to do with
this patch. Sure, even with NDEBUG the program may abort if that is
called explicitly...

 * Some expressions were perhaps depending on the logging mechanism which
   is part of the side effect. Callers to assert_se() are perhaps using
   it for a reason, are you sure that you are not introducing a
   regression here ?! it will be difficult to debug the error if we don't
   have logs.

As far as I can tell all the relevant logging functions are pure. They
should not interact with global state, but maybe I'm missing
something?

 * Current expression may modify/interact with a global state which may
   cause a fatal error, and if the caller wants to know if that failed,
   then abort(), your patch just introduced a regression, without the
   explicit abort(), all callers now have to call abort().

Yeah, this is the point I think. I still think the patch makes sense
though, it really don't see why there should be a distinction between
assert_se() and assert() when it comes to logging and aborting.

If assert_se() fails it indicates we may have messed up the global
state, and if assert() fails it indicates that the global state may be
messed up (by someone else). Either way the global state is
potentially messed up and not logging/aborting seems as (un)safe in
both situations.

Another way of seeing it, intuitively I don't see why we should
distinguish between

assert_se(foo() = 0);

and

r = foo();
assert(r = 0);

 * Did you grep for assert_se() uses in the source ?

 I really do not think this is an improvement, we can't predict the
 semantics of expression here, perhaps we can with simple assert() but
 not with assert_se().

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

Re: [systemd-devel] [PATCH 2/2] macro: allow assert_se() assertions to also be optimized out when NDEBUG is set

[Tom Gundersen]

On Thu, Mar 26, 2015 at 9:19 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 24.03.15 11:11, Shawn Landden (sh...@churchofgit.com) wrote:

 Will result in slightly smaller binaries, and cuts out the branch, even if
 the expression is still executed.

 I am sorry, but the whole point of assert_se() is that it has side
 effects. That's why it is called that way (the se suffix stands for
 side effects), and is different from assert(). You are supposed to
 use it whenever the code enclosed in it shall not be suppressed if
 NDEBUG is defined. This patch of yours breaks that whole logic!

Hm, am I reading the patch wrong? It looks good to me. It is simply
dropping the branching and logging in the NDEBUG case, but the
expression itself is still evaluated.

So in the NDEBUG case assert_se(foo()) becomes equivalent to
foo(), which I guess makes sense (though I doubt it makes much of a
difference).

-t

 ---
  src/shared/macro.h | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/src/shared/macro.h b/src/shared/macro.h
 index 7f89951..02219ea 100644
 --- a/src/shared/macro.h
 +++ b/src/shared/macro.h
 @@ -212,17 +212,17 @@ static inline unsigned long ALIGN_POWER2(unsigned long 
 u) {
  (__x / __y + !!(__x % __y));\
  })

 -#define assert_se(expr) \
 -do {\
 -if (_unlikely_(!(expr)))\
 -log_assert_failed(#expr, __FILE__, __LINE__, 
 __PRETTY_FUNCTION__); \
 -} while (false) \
 -
  /* We override the glibc assert() here. */
  #undef assert
  #ifdef NDEBUG
 +#define assert_se(expr) do {expr} while(false)
  #define assert(expr) do {} while(false)
  #else
 +#define assert_se(expr) \
 +do {\
 +if (_unlikely_(!(expr)))\
 +log_assert_failed(#expr, __FILE__, __LINE__, 
 __PRETTY_FUNCTION__); \
 +} while (false)
  #define assert(expr) assert_se(expr)
  #endif

 --
 2.2.1.209.g41e5f3a

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


 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] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Tom Gundersen]

On Tue, Mar 24, 2015 at 3:17 PM, Stef Walter st...@redhat.com wrote:
 On 24.03.2015 15:11, Kay Sievers wrote:
 On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 Exactly because they do not require being upgraded in lock-step, doing
 conversion to the local time locally is racy. Assuming we have up-to-date
 timezone database locally, with the patch that was merged today we can
 answer the question what the local time should be remotely, but not
 necessarily what the local time is remotely.

 If we go to the trouble of displaying the remote local time, imho we
 should do it as the remote does.

 No, we should care about the *state* of the system, and that is its
 time value and its configured location on earth.

 Then stop displaying incorrect presentation data in timedatectl.

I don't see how this is incorrect now. See below.

 Systemd has no business in fixing the *presentation* logic of these
 values. It is not an API for the timezone database. These tools
 already exist.

 Please stop trying to add insufficient and half-thought-through APIs
 to cover problems which just do not exist in reality or do not need to
 be worked-around by systemd.

 This gives us what we need:

 $ date '+%s:%:z'

 So we'll use that instead of timedated. I'll update the wiki page for
 the timedated DBus interface to note parts of it are just not remotable.

For the record, I think it IS remoteable now with the recent change.
It all comes down to what you intend the fields to mean. Now we mean
the field to mean the real localtime of the server (as seen from the
client), whereas you want it to mean the localtime the server thinks
it has. If these two notions don't coincide, something is obviously
fucked, but I don't think it is correct to say that the current way of
handling it mean the API is not remotable.

Cheers,

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