procps starts too early to correctly set net.netfilter.nf_conntrack_acct

[Simon Déziel]

Binary package hint: procps

I followed the documentation in /etc/sysctl.d/README that tells to put custom sysctl settings in /etc/sysctl.d/60-*.conf.

/etc/sysctl.d/60-bridge-firewalling.conf :
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-arptables=0

/etc/sysctl.d/60-nf-conntrack.conf :
net.netfilter.nf_conntrack_acct=0

but those setting are not applied on reboot. They are correctly applied when running this though :

sudo service procps start

I think that this is because the procps Upstart script starts too soon in the boot process :

/etc/init/procps.conf:
...
start on virtual-filesystems

task
script
    cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -p -
end script

I don't know Upstart enough to change the "start on" line to have my settings correctly applied. Any help is greatly appreciated.

simon@xeon:~$ lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04

simon@xeon:~$ apt-cache policy procps
procps:
  Installed: 1:3.2.8-1ubuntu4
  Candidate: 1:3.2.8-1ubuntu4
  Version table:
 *** 1:3.2.8-1ubuntu4 0
        500 http://ca.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

[David Gibson (dwg)]

I've hit a similar problem, though it's net.bridge.bridge-nf-call-iptables that I care about.

It's not because it's running too early though, it's not running at all. I confirmed this by adding some echos to a log file to the script in /etc/init/procps.conf. It appears to be broken in both karmic and maverick. I think this must be an upstart or mountall bug.

[Simon Déziel (sdeziel)]

@David,

I just found a workaround for the net.bridge.bridge-nf-call-*tables values. You need to add the bridge module to /etc/modules and run update-initramfs :

echo "bridge" >> /etc/modules
update-initramfs -k all -u

This works because the bridge module is responsible to create the sysctl keys once loaded. Having the module included in the initrd makes sure the keys will exist when procps upstart job is run.

I haven't test for the net.netfilter.nf_conntrack_acct key but I think that including the nf_conntrack module to /etc/modules would fix this too.

[Simon Déziel (sdeziel)]

Instead of using the previous workaround I modified /etc/init/procps.conf and added /etc/init/procps-net.conf. With the modified and the new files everything is working (including net.netfilter.nf_conntrack_acct) without needing to add modules to the initrd.

[David Gibson (dwg)]

Ok, looks like we're hitting different bugs. For me, on karmic at least the procps.conf script is not being run *at all*.

[Simon Déziel (sdeziel)]

@David,

Maybe adding a "post-up" command to your bridge configuration in /etc/network/interfaces would help. Here is an example :

# The primary network interface
auto br0
iface br0 inet static
    address 172.16.20.1
    netmask 255.255.255.0
    gateway 172.16.20.2

    # Workaround for upstart problem
    post-up /sbin/sysctl -p /etc/sysctl.d/60-bridge-firewalling.conf

[Arkadiy Kulev (eth-ethaniel)]

I confirm, I have the same problem and the following setting is not applied:
net.ipv4.netfilter.ip_conntrack_max=1548576

[Simon Déziel (sdeziel)]

@Arkadiy

As a workaround you you install the /etc/init/procps.conf and /etc/init/procps-net.conf from comments #3 and #4.

[James Hunt (jamesodhunt)]

This is an issue with the procps package, not Upstart.

[James Hunt (jamesodhunt)]

This issue is related to bug 771372.

[Simon Déziel (sdeziel)]

@James, since the latest packages uploaded to lucid-proposed for bug 771372, the problem is fixed. Many thanks.

[Simon Déziel (sdeziel)]

Marking as "fix released" as the -updates package fixes the issue on Lucid.

[burdandrei (burdandrei)]

i still have a problem that net.ipv4.netfilter.ip_conntrack_max are not applying

[Jeroen Vijfhuizen (jeroenvijfhuizen)]

I'd like to second that, still having this on Ubuntu server 12.04 LTS.

[Jeroen Vijfhuizen (jeroenvijfhuizen)]

Could not find a way to edit comments but I'd like to retract comment #14. In my case it was first touching any iptables related stuff in rc.local which seems to be executed later then procps. I am now force loading the related module 'nf_conntrack_ipv4' in /etc/modules which makes the sysctl.d settings being properly applied on next boot.

This was one of the most confusing system configuration related bugs I have ever had to chase. Hopefully there is some way (I know this is not easy) to make this whole process better in the future :)