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

Tom Gundersen teg at jklm.no
Mon Jan 12 15:38:26 PST 2015

On Mon, Jan 12, 2015 at 11:46 PM, Jan Engelhardt <jengelh at 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
> 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.

So the ordering is correct, but not its semantics. Later in the same
manpage it is explained: "The first (in lexical order) of the link
files that matches a given device is applied." In other words, since
'99-' is ordered before '99a' only '99-' is applied and '99a' is

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

Ah, link files are applied by udev (and udev only). They are meant as
a way to set sane network-agnostic values when the device first
appears. If you think some of the documentation is unclear on this
point, please let me know.

Some of the .link settings may make sense to tweak also per-network,
in which case we support changing them in .network files. This does
not apply to interface names though, as changing that at run-time
tends to cause lots of problems. We therefore make sure that the
interface name is only ever changed by udev, and only before the
presence of the device is announced via libudev to the rest of



More information about the systemd-devel mailing list