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

Bug #690433 reported by Simon Déziel on 2010-12-15
This bug affects 5 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)

Bug Description

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 :

/etc/sysctl.d/60-nf-conntrack.conf :

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 :

start on virtual-filesystems

    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
  Installed: 1:3.2.8-1ubuntu4
  Candidate: 1:3.2.8-1ubuntu4
  Version table:
 *** 1:3.2.8-1ubuntu4 0
        500 lucid/main Packages
        100 /var/lib/dpkg/status

David Gibson (dwg) wrote :

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.

affects: procps (Ubuntu) → upstart (Ubuntu)
Simon Déziel (sdeziel) wrote :


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) wrote :

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) wrote :

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) wrote :


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

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

Arkadiy Kulev (eth-ethaniel) wrote :

I confirm, I have the same problem and the following setting is not applied:

Simon Déziel (sdeziel) wrote :


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

Changed in upstart (Ubuntu):
status: New → Confirmed
James Hunt (jamesodhunt) wrote :

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

affects: upstart (Ubuntu) → procps (Ubuntu)
James Hunt (jamesodhunt) wrote :

This issue is related to bug 771372.

Simon Déziel (sdeziel) wrote :

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

Changed in procps (Ubuntu):
status: Confirmed → Fix Committed
Simon Déziel (sdeziel) wrote :

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

Changed in procps (Ubuntu):
status: Fix Committed → Fix Released
burdandrei (burdandrei) wrote :

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

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

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 :)

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

Other bug subscribers