bugzilla-daemon@netfilter.org
2004-Jan-07 04:07 UTC
[Bug 91] conntrack unload loops forever (reproducible)
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91 mschwendt@users.sf.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From mschwendt@users.sf.net 2004-01-07 05:07 ------- I still see this with kernel 2.4.24. 100% reproducible for me. lsmod shows "ip_conntrack (deleted)" as the only netfilter module left with "modprobe -r ip_conntrack_ftp" taking 99% CPU time. Since the patch for this has never made it into the kernel for Red Hat Linux 7.3 and 8.0 (it's not in 9 either yet), I've looked into adding it. But neither the "Fix unhelp" attachment works nor the one which is attached to the corresponding bug report at Red Hat's bugzilla. Hence I went to try 2.4.24, and it hangs, too. The only work-around for me is still to either not remove netfilter modules or remove them in a different order than Red Hat's iptables script would do. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@netfilter.org
2004-Jan-12 08:22 UTC
[Bug 91] conntrack unload loops forever (reproducible)
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From mschwendt@users.sf.net 2004-01-12 09:22 ------- Some more info after enabling a bit of debug info: * ip_conntrack_cleanup() loops forever back to the i_see_dead_people label * atomic_read(&ip_conntrack_count) is stuck at 1 * ip_ct_selective_cleanup(..) doesn't do anything because get_next_corpse(..) doesn't find anything other than NULL * cat /proc/net/ip_conntrack is empty Patches/ideas welcome! ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@netfilter.org
2004-Jan-12 19:34 UTC
[Bug 91] conntrack unload loops forever (reproducible)
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From kaber@trash.net 2004-01-12 20:34 ------- Please share some more details: - Is it a RH 2.4.24 or vanilla kernel you're talking about ? - What is the order the RH scripts remove them and in what order does it work ? - Do you have sessions that are tracked by a helper when trying to remove the modules (ftp,irc,...) ? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@netfilter.org
2004-Jan-12 21:59 UTC
[Bug 91] conntrack unload loops forever (reproducible)
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From mschwendt@users.sf.net 2004-01-12 22:59 ------- * It's vanilla 2.4.24 from kernel.org. * RH kernels are identified with an additional version/build number.> What is the order the RH scripts remove them and in what order does it work ?There is nothing like a well-defined order of removal which works for everyone. Trial and error or removing netfilter modules manually, can be tiresome. The corresponding bug report is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103177 The iptables userspace packages from RH, which trigger this bug, do a recursive "modprobe -r" removal of what is found in output of "lsmod". The first iptables package update of that kind which removed netfilter modules was this: ftp://ftp.tu-chemnitz.de/pub/linux/redhat-updates/7.3/en/os/i386/iptables-1.2.8-8.72.3.i386.rpm> Do you have sessions that are tracked by a helper when trying to > remove the modules (ftp,irc,...) ?Helper modules are loaded, but no actual conntrack traffic because this is right after reboot and a client machine with a server rule-set. In addition to what modules are loaded automatically, these are loaded explicitly: IPTABLES_MODULES="ip_conntrack_ftp ip_nat_ftp ip_conntrack_irc ip_nat_irc" As mentioned before, prior to unloading the modules ("service iptables stop" with Red Hat Linux), "cat /proc/net/ip_conntrack" is empty. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@netfilter.org
2004-Jan-12 22:24 UTC
[Bug 91] conntrack unload loops forever (reproducible)
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From kaber@trash.net 2004-01-12 23:24 ------- Could you try the extra/conntrack* patches (you need to apply submitted and pending first) ? Joszef believes they will solve all refcounting problems. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@netfilter.org
2004-Jan-13 00:22 UTC
[Bug 91] conntrack unload loops forever (reproducible)
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From mschwendt@users.sf.net 2004-01-13 01:22 ------- That gives me ip_conntrack 2.2 (in particular due to extra patches conntrack_arefcount and conntrack_locking), but locks up in exactly the same way as described in my first comment here. I assume that when I would insert debug output, it would be caught in the same loop as before. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Seemingly Similar Threads
- [Bug 91] conntrack unload loops forever (reproducible)
- [Bug 91] New: conntrack unload loops forever (reproducible)
- [Bug 91] conntrack unload loops forever (reproducible)
- Should R Packages Unload Dynamic Libraries When They Unload?
- Flash keeping forever when using ActiveRecordStore