procps runs before network is properly initialized

Bug #1073658 reported by Simon Déziel on 2012-10-31
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
procps (Ubuntu)
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.d/60-partly-disable-rp-filter.conf
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.eth2.rp_filter=0

but on reboot I get this:

root@fw2:~# sysctl net.ipv4.conf| grep -F .rp_filter
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.eth2.rp_filter = 1
net.ipv4.conf.eth4.rp_filter = 1
net.ipv4.conf.eth5.rp_filter = 1
net.ipv4.conf.eth3.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.eth1/29.rp_filter = 1
net.ipv4.conf.eth1/23.rp_filter = 1
net.ipv4.conf.eth1/30.rp_filter = 1

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.

Simon Déziel (sdeziel) wrote :

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://launchpadlibrarian.net/63746118/procps.conf and https://launchpadlibrarian.net/63746194/procps-net.conf

Simon Déziel (sdeziel) wrote :

Unfortunately even the above proposition doesn't work. Using "post-up" in /etc/network/interfaces does not work properly either.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers