I'm using (multiple instanced due to multiple watch directories of) transmission-daemon 2.42 on a PPC/OS X 10.5 machine. My machine has several (dynamic) network interfaces, so I bind the daemon instanced to a certain IP using the settins.json file, reloading it (with a modified IP) when the IP on the interface changes by sending a SIGHUP. Anyway, I noticed that after a couple of days usage (usually 4 to 5 days) the bittorrent traffic crawls to a halt and newly added torrents don't pick up any peers. Now my incoming port is still open and the log shows the daemon receiving peers from the tracker, and I can still access the daemon process using transmission-remote, transmission-remote-cli.py and "Transmission Remote GUI". When I checked the files opened by the daemon process (using lsof), I noticed that there were a lot of entries like this:
transmiss 67995 bill 105u IPv4 0x2e58e64 0t0 TCP *:* (CLOSED)
One daemon process has a peer-limit-global of 50, and all 50 connection slots where taken up by said "closed" connections, another daemon process has a peer-limit-global of 100 and all of them were taken up by said "closed" connections as well. So I guess for some reason the daemon doesn't purge that closed connections, slowly decreasing the number of slots available for peer connections. I didn't open a ticket on the bug tracker yet, as the information gathered so for might be not sufficient. Any advice?
No, this behavior is IMHO due to the changing of the "bind-address-ipv4" in the settings.json file and SIGHUP. I only see an increase in the number of "(CLOSED)" connections during the small time when the interface changed the assigned IP adress and the daemon is still bound to the old IP adress (approx. 60 seconds) or shortly thereafter. Then the number stays the same for the next 24 hours (or until the network interface gets a new IP adress, and a rebinding of the daemon to a new IP occurs). I was thinking that the daemon tries to connect to peers. During the negotiation the interface changes. Somehow these "connections" don't timeout properly and don't get removed.
More info: I'm running three daemon instances on distinct ports (the ones with more loaded torrents show a stepper increase in "(CLOSED)" connections after the "rebinding" then the ones with less loaded torrents), OSX supposedly has still plenty of PCBs to use. These are values with average network usage:
> sysctl -a | grep pcb
net.inet.tcp.pcbcount: 194
net.inet.udp.pcbcount: 41
There are enough mbufs as well:
netstat -m
6220/7569 mbufs in use:
4228 mbufs allocated to data
4 mbufs allocated to packet headers
1987 mbufs allocated to socket names and addresses
1 mbufs allocated to Appletalk data blocks
1349 mbufs allocated to caches
1247/2554 mbuf 2KB clusters in use
68/232 mbuf 4KB clusters in use
6036 KB allocated to network (35.8% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to drain routines