Given lack of errors after interface rename, settings were most probably
applied correctly.
No. According to the log, the lack of errors after the rename result
simlpy in there are no more settings left that could be applied. Because
they all have been tried before. And failed. sysctl.conf is most likely
only read once during boot. And in this case that happens before the
rename.
tw:~ # systemctl stop NetworkManager.service
tw:~ # ip l set dev enp0s5 down
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
1
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
1
tw:~ # echo 3 > /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
tw:~ # echo 2 > /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
3
tw:~ # ip l set dev enp0s5 name ififif
tw:~ # ip l set dev ififif up
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/addr_gen_mode
3
Thanks for taking the time to demonstrate this. But it does not comapre,
as you do not remane the interface. It is alway enp0s5, and therefore
the kernel is keeping the /proc/sys/net/ipv6/conf/enp0s5/ settings.
You you would need to apply the sysctl to enp0s5, then rename it to
lan01, then the /proc/sys/net/ipv6/conf/enp0s5/... hierachy would be
gone and instead you would have a
/proc/sys/net/ipv6/conf/lan01/ hierachie, that would NOT inherit the
settings you've applied to enp0s5.
From a kernel perspective point of view these two are not related at
all, they are independent interfaces, that just appear and go. At least,
that's what it seems like.
And that is what is happening here on boot.
systemd-sysctl applies the eth0 setting from sysctl.conf to the
interface. It failes to to do the same for ens3, as this interface does
not exist yet. As it is still named eth0
Then systemd renames eth0 to ens3. The eth0 settings are gone, the ones
for ens3 are not applied any more, as systemd-sysctl has already
processed sysctl.conf. Therefore the default values are used.
As written in a follow up, the ordering seems to be different on deepin
linux using systemd 241 instead of arch and systemd 245.
However, even with deepin, if you rename an interface with an udev rule
or .link file, you run into the same problems again. Just, that there
are now three renames and sysctl is read after the second, but before
the third rename. Same result however.
What likely happens in your case is something else changes settings
after they had been applied by udev. Notice I had to stop NetworkManager
to avoid interfering as soon as link comes up.
I do not use any other network manager but systemd-networkd. In fact, I
do not even have any installed. netctl, the default of arch, has been
removed straight after install.
And, in addition, journal is pretty clear about systemd-networkd doing
the name change:
Mai 23 10:41:27 systemd-networkd[464]: ens3: Interface name change
detected, ens3 has been renamed to eth0.
Mai 23 10:41:27 systemd-networkd[464]: eth0: Interface name change
detected, eth0 has been renamed to ens3.
But, in case this is still true, what would be the best way to figure out?
How can we hunt down this issue?
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
