You are not logged in.
Whenever my torrent connections are loaded up fairly high (100 - 200), and I git clone, its connection is refused, unable to connect to a socket.
My networking foo is rather weak, and I am less looking for an answer to this problem and more for a clue as to how I might go about diagnosing it more precisely.
Offline
I'm guessing maybe you're running out of File Descriptors... Since you don't want an answer, just a direction, I'll stop there
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
I'm guessing maybe you're running out of File Descriptors... Since you don't want an answer, just a direction, I'll stop there
This is just the kind of tip I was looking for. This is what I've found out:
Using transmission (my preferred torrent client) to the capacity at which git connections fail,
lsof | wc -l
yields a count of 17128,
lsof -p 6382 | wc -l
where 6382 is transmission PID, yields a count of 224, which is just about the number of connections I allow transmission to make (250).
I read, however, that
cat /proc/sys/fs/file-max
which gives me 290131, is the max number of file descriptors available. But I suspect this is system wide across all shells and children because it does not square with
ulimit -aH
Which shows the max to be 1024.
Further still, the output of
lsof | wc -l
is greater than the shell limit (1024) .
So... although I seem to know more about file descriptors, not yet enough to square these different results or to establish that indeed I am running out of them.
As of 15 minutes ago a didn't know the first thing about any of this, so it occurs to me I still might be harboring a misunderstanding of the problem.
Any further advice?
Last edited by ryanklee (2011-06-21 02:02:24)
Offline
This is just the kind of tip I was looking for
...
Any further advice?
Perhaps...
sysctl net.ipv4.netfilter.ip_conntrack_max
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
ryanklee wrote:This is just the kind of tip I was looking for
...
Any further advice?Perhaps...
sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max exists neither as setting in /etc/sysctl.conf nor as or in a file in /proc/sys/net/ipv4/.
I grep'd through /var/log/messages which turned up nothing related to packets, iptables or conntrack. A dead end?
(Thank you for your help thus far.)
Next step?
Offline
(Thank you for your help thus far.)
NP, it's fun
Always happy to help someone who is willing to help themself too
Next step?
I'm out of ideas
I'll check back in if I think of anything...
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Some routers don't like too many connections.
Offline
Some routers don't like too many connections.
Aware of this, but I am getting acceptable behavior when using the same router with the same number of established connections on a different OS.
Offline
Does e.g. web browsing work properly when git doesn't?
Offline
Web browsing seems to work correctly, but in the case of a general delays in connecting to this site or another while torrenting, I haven't established one way or the other if it's my provider, reduced bandwidth, or related to whatever is causing the git connections to fail. My provider (comcast, if you are familiar) is somewhat flaky to begin with and so I usual default to attributing sluggish web activity to them.
Offline
You could perhaps prefix strace to git- maybe you'd get more info as to why connections fail.
Offline