If anyone else comes across this, this seemed to help: iptables -t raw -A PREROUTING -i lo -j NOTRACK iptables -t raw -A OUTPUT -o lo -j NOTRACK
On top of already having a rule for "-A INPUT -i lo -j ACCEPT" and "-A OUTPUT -j ACCEPT". This way ip_conntrack isn't involved when making connections to couchdb on the loopback connection. I was making many rapid connections and quickly using up all the space in the hash tables for ip_conntrack. -Tim On Mon, Sep 10, 2012 at 3:20 PM, Tim Tisdall <[email protected]> wrote: > No. It's a cron script that I've been using for a while now. PHP is > reporting that fclose() is properly closing the connections, but the > fact that /proc/sys/net/ipv4/netfilter/ip_conntrack_count seems to > grow rapidly when the script is running seems to indicate otherwise. > > I recently did an update on PHP and so I suspect this is some bug that > got introduced by that update. Anyone else using PHP with couchdb and > notice similar problems after upgrading to PHP 5.3.16? > > -Tim > > On Mon, Sep 10, 2012 at 2:02 PM, Keith Gable <[email protected]> > wrote: >> Is there a similar increase in HTTP requests? It sounds to me that your web >> server is executing your PHP script, which is making requests into CouchDB. >> So an increase in requests would result in an increase of CouchDB requests. >> >> --- >> Keith Gable >> A+ Certified Professional >> Network+ Certified Professional >> Storage+ Certified Professional >> Mobile Application Developer / Web Developer >> >> >> >> On Sun, Sep 9, 2012 at 9:14 PM, Tim Tisdall <[email protected]> wrote: >> >>> I'm using iptables on my system to block external access to everything >>> except for explicit ports (http, https, ssh, etc). I'm not sure how, >>> but I'm getting “nf_conntrack: table full, dropping packet.” and “TCP: >>> time wait bucket table overflow” because the number of connections is >>> past the maximum trackable. By listing the connections in >>> /proc/net/ip_conntrack I can see a wack of entries that look like the >>> following: >>> >>> tcp 6 54 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=56039 >>> dport=5984 packets=7 bytes=429 src=127.0.0.1 dst=127.0.0.1 sport=5984 >>> dport=56039 packets=7 bytes=19476 [ASSURED] mark=0 secmark=0 use=2 >>> >>> I see that it's using port 5984 which is what couchdb is on, but I'm >>> not sure why this is occurring. I'm using PHP with the fsockopen() >>> method described in the wiki and I do have a script running that's >>> making updates to the db. However, PHP isn't multi-threaded and I'm >>> making calls through the fsockopen and then closing the connection >>> immediately afterwards. Does anyone know what's causing this to >>> occur? Or maybe where to look further to figure this out? >>> >>> -Tim >>>
