procps runs before network is properly initialized
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
procps (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Disabling rp_filter on an interface that is subject to eth renaming during boot will end up disabling rp_filter on the wrong interface.
On my specific system, I want to turn off rp_filter on eth2:
root@fw2:~# cat /etc/sysctl.
net.ipv4.
net.ipv4.
but on reboot I get this:
root@fw2:~# sysctl net.ipv4.conf| grep -F .rp_filter
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
net.ipv4.
This seems to be caused by eth renaming that happens after procps ran:
root@fw2:~# dmesg | grep rename
[ 5.697133] udevd[492]: renamed network interface eth5 to rename7
[ 5.720664] udevd[490]: renamed network interface eth2 to rename4
[ 5.752559] udevd[494]: renamed network interface eth3 to eth2
[ 5.792480] udevd[491]: renamed network interface eth4 to rename6
[ 5.820484] udevd[462]: renamed network interface eth0 to eth4
[ 5.864355] udevd[463]: renamed network interface eth1 to eth5
[ 5.940202] udevd[492]: renamed network interface rename7 to eth3
[ 5.960133] udevd[490]: renamed network interface rename4 to eth0
[ 5.984130] udevd[491]: renamed network interface rename6 to eth1
During the boot up, "eth2" has the rp_filter disabled as expected but it is later renamed to "rename4" then "eth0". The disabled rp_filter ends up on "eth0" which is obviously not what was expected.
This is not the first time procps.conf interacts badly with network initialization (LP: #690433, LP: #771372).
I think that splitting procps.conf in two jobs would solve this once for good. The idea would be to have something like https:/ /launchpadlibra rian.net/ 63746118/ procps. conf and https:/ /launchpadlibra rian.net/ 63746194/ procps- net.conf