[tor-relays] numtcpsock prevents relay from working properly.
Hi, I am experiencing trouble with a new VPS relay. https://atlas.torproject.org/#details/41F07731207742860D43AC426FBAE2F3947BD1CA It spontaneously acquired an advertised bandwidth of 2.67MB/s but then started to sputter. Failing because we have 1314 connections already ... Specifically, looking at /proc/user_beancounters numtcpsock is the culprit, which is limited to 1360 (some other processes are using the remaining sockets). This artificial limit causes new connections to fail even though send/receive buffers or CPU usage are well below critical. The value can't be changed from inside the OpenVZ container. That's a pity because traffic appears to be unmetered and a lot of potential is wasted this way. I understand that there is currently no way to limit this inside the Tor process because every relay needs to be ready to connect to every other relay at any time. So I tried to get its consensus weight down. Gradually lowering the MaxAdvertisedBandwidth to 300k caused it to briefly acquire the "Stable" flag and run into trouble again. That's no better than a home connection. Worse, in fact, because the problem persists. I'm curious, is this a common experience? Asking customer service would mean explicitly drawing attention to the fact that I'm trying to use the cheap plan to run Tor nodes. That's completely against my instincts. On the other hand they *did* offer a free-form box in the registration form. Has anyone tried and if so, to any avail? Is there a workaround I'm missing? iptables can be configured freely, but I don't see how that would help. At this point I'll probably call it a day, try elsewhere and set this one up as a bridge instead. Frankly I was a bit surprised that technical snags like this aren't generally mentioned in relay setup guides or FAQs. For all I know, it may be common knowledge among expert sysadmins that OpenVZ should be shunned or whatever, but to someone with little prior experience as a user of commercial hosting, some of these limitations come as a surprise. In a bout of post factum searching, I only found this discussion https://serverfault.com/questions/698845/debian-limit-number-of-tcp-sockets-for-a-process-especially-tor-on-openvz IMHO this kind of knowledge should be spread more "pro-actively", which is why I'm posting this on a public list. Peace, Erik ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] numtcpsock prevents relay from working properly.
Hi Nils, Yes, this is a known problem. It has been discussed a number of times before on this list, but it never made it into any FAQ. On 10/07/2016 11:38 AM, Nils Erik Flick wrote: > Asking customer service would mean explicitly drawing attention to the > fact that I'm trying to use the cheap plan to run Tor nodes. That's > completely against my instincts. On the other hand they *did* offer a > free-form box in the registration form. > > Has anyone tried and if so, to any avail? It is not unusual for ISPs to set a very conservative default, and then raise it when the customer asks. You don't necessarily have to mention Tor in your request. > IMHO this kind of knowledge should be spread more "pro-actively", which > is why I'm posting this on a public list. Always a good idea to remind people. Maybe this encourages someone to submit a patch for the website? -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] numtcpsock prevents relay from working properly.
Hi Moritz, thanks for your reply. This is very helpful. I think I will raise the issue with my provider and see how it goes. Best, Erik Moritz Bartl: > Hi Nils, > > Yes, this is a known problem. It has been discussed a number of times > before on this list, but it never made it into any FAQ. > > On 10/07/2016 11:38 AM, Nils Erik Flick wrote: >> Asking customer service would mean explicitly drawing attention to the >> fact that I'm trying to use the cheap plan to run Tor nodes. That's >> completely against my instincts. On the other hand they *did* offer a >> free-form box in the registration form. >> >> Has anyone tried and if so, to any avail? > > It is not unusual for ISPs to set a very conservative default, and then > raise it when the customer asks. You don't necessarily have to mention > Tor in your request. > >> IMHO this kind of knowledge should be spread more "pro-actively", which >> is why I'm posting this on a public list. > > Always a good idea to remind people. Maybe this encourages someone to > submit a patch for the website? > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] numtcpsock prevents relay from working properly.
Thanks again Moritz, great advice. I got a very nice reply from customer support almost instantly, the limit was increased and it's been working all right for a week. Nils Erik Flick: > Hi Moritz, > > thanks for your reply. This is very helpful. I think I will raise the > issue with my provider and see how it goes. > > Best, > Erik > > Moritz Bartl: >> Hi Nils, >> >> Yes, this is a known problem. It has been discussed a number of times >> before on this list, but it never made it into any FAQ. >> >> On 10/07/2016 11:38 AM, Nils Erik Flick wrote: >>> Asking customer service would mean explicitly drawing attention to the >>> fact that I'm trying to use the cheap plan to run Tor nodes. That's >>> completely against my instincts. On the other hand they *did* offer a >>> free-form box in the registration form. >>> >>> Has anyone tried and if so, to any avail? >> >> It is not unusual for ISPs to set a very conservative default, and then >> raise it when the customer asks. You don't necessarily have to mention >> Tor in your request. >> >>> IMHO this kind of knowledge should be spread more "pro-actively", which >>> is why I'm posting this on a public list. >> >> Always a good idea to remind people. Maybe this encourages someone to >> submit a patch for the website? >> > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays