Re: [tor-relays] Memory Problems with tor releay - restart tor automatically after failure
Hi Nusenu and Roman, thanks for you recommendations. I already implemented as small ~ 10 lines script which does it job and logs what's going on. Mit Mai 24 21:45:01 CEST 2017 Process tor2 is not running -> starting Don Mai 25 08:50:02 CEST 2017 Process tor2 is not running -> starting Don Mai 25 10:10:22 CEST 2017 Process tor1 is not running -> starting Don Mai 25 11:25:02 CEST 2017 Process tor2 is not running -> starting Don Mai 25 15:40:02 CEST 2017 Process tor2 is not running -> starting As you can see we had this OOM on one server yesterday 4 times. On the other everything went fine. Upgrading 16.04 is on the roadmap - but we agreed in the team it would be a last resort. We want to have equal configuration on all nodes (and other servers we operate). Since we hopefully soon may have an additional provider we would start with the new machine for the clean setup on the chosen OS and then would follow with the existing ones. Long text short. If it helps with the cause of the current problem I would start changing OS today. If not we try to get a common platform for all our tor and other servers. Even the scripts works and now the exits return to their throughput it feels like a dirty solution to do this auto restart. best regards Dirk p.s. Nusenu - it seem onionoo responds better now - was there a solution to the problem On 25.05.2017 10:54, nusenu wrote: > Hi Dirk, > > I noticed your comment [1] about your plans to write a script that > restarts tor should it get killed. > > I just wanted to let you know that if you have plans to upgrade to > Ubuntu 16.04 you will get this out of the box due to systemd Restart= > [2] service configuration. > > [1] https://trac.torproject.org/projects/tor/ticket/22255#comment:23 > [2] > https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@.service#n20 > https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart= > > > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit relay consensus weight
On Thu, May 25, 2017 at 08:20:16PM -0700, Arisbe wrote: > I just made an interesting observation that I thought I would share. > Yesterday I started a VPS exit relay at a well known hosting company > in Moldova [0]. Within 24 hours I saw the consensus weight exceed > 1. The relay is bandwidth limited to 10 MiB/s. Not that I'm > complaining! Thanks for running an exit relay! (Using data files from https://collector.torproject.org/recent/relay-descriptors/consensuses/) $ grep -A4 "^r TorExitMoldova" 2017-05*|grep "w " 2017-05-24-20-00-00-consensus-w Bandwidth=0 Unmeasured=1 2017-05-24-21-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-24-22-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-24-23-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-00-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-01-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-02-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-03-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-04-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-05-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-06-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-07-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-08-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-09-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-10-00-00-consensus-w Bandwidth=8460 2017-05-25-11-00-00-consensus-w Bandwidth=8460 2017-05-25-12-00-00-consensus-w Bandwidth=8180 2017-05-25-13-00-00-consensus-w Bandwidth=8180 2017-05-25-14-00-00-consensus-w Bandwidth=8180 2017-05-25-15-00-00-consensus-w Bandwidth=8180 2017-05-25-16-00-00-consensus-w Bandwidth=8180 2017-05-25-17-00-00-consensus-w Bandwidth=8180 2017-05-25-18-00-00-consensus-w Bandwidth=8180 2017-05-25-19-00-00-consensus-w Bandwidth=9670 2017-05-25-20-00-00-consensus-w Bandwidth=9670 2017-05-25-21-00-00-consensus-w Bandwidth=9670 2017-05-25-22-00-00-consensus-w Bandwidth=9670 2017-05-25-23-00-00-consensus-w Bandwidth=9670 2017-05-26-00-00-00-consensus-w Bandwidth=9670 2017-05-26-01-00-00-consensus-w Bandwidth=9670 2017-05-26-02-00-00-consensus-w Bandwidth=9670 2017-05-26-03-00-00-consensus-w Bandwidth=9670 Here's what I think happened: A) You started up your exit relay the evening of May 24 UTC, and it published a descriptor with a tiny amount of bandwidth in it (from self-testing). B) Somehow, it attracted a traffic flow that was very high volume. Its consensus weight was tiny, but there are millions of Tor clients, so maybe one of them chose it anyway. Or maybe the bandwidth authorities themselves added this load. I'm not sure how step 'B' happened, but however it did, your relay handled a lot of traffic, so it learned that it *could* handle a lot of traffic, so it published new relay descriptors saying that it's quite fast. It has published three descriptors so far. The third number on the bandwidth line is its self-reported capacity: published 2017-05-24 19:50:38 bandwidth 10485760 12582912 145408 published 2017-05-24 23:34:24 bandwidth 10485760 12582912 6487186 published 2017-05-25 15:39:43 bandwidth 10485760 12582912 11526593 C) By the time the bandwidth authorities got around to measuring it, it was already proudly self-reporting a big capacity. The way the bandwidth authorities work is that they decide a modification to the self-reported number, depending on how you perform compared to your peers who self-report a similar number. You perform about average compared to your peers, so they gave you a consensus weight that is around the number you were self-reporting. > So it begs the question: Is there not enough exit relays on the Tor > network? Well, exit relays attract traffic in a very different pattern than guard relays. The blog post that we always point people to: https://blog.torproject.org/blog/lifecycle-of-a-new-relay has to do with how a fast non-exit relay will grow over time. So it is much more normal for your consensus weight to grow quickly for an exit relay. (Well, expected. It's hard to say what is normal with the weird broken design that is the bandwidth authority subsystem these days. :) As for whether there are not enough exit relays... always! :) We actually have about a third of the capacity of the network in Exits right now, so from a load balancing perspective, it's not a disaster, since clients avoid using the exit relays for any other positions in their circuits, and it works out ok. But from the perspective of resistance against correlation attacks, which is largely a function of diversity of entry points and exit points, then having only 1/3 of the network as a possible exit point means things aren't as good as they could be. Hope that helps, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] exit relay consensus weight
Hello relay ops, I just made an interesting observation that I thought I would share. Yesterday I started a VPS exit relay at a well known hosting company in Moldova [0]. Within 24 hours I saw the consensus weight exceed 1. The relay is bandwidth limited to 10 MiB/s. Not that I'm complaining! So it begs the question: Is there not enough exit relays on the Tor network? Arisbe [0] B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Legal Status of Relays Worldwide [was: kittens seized]
On 21/05/2017 21:47, grarpamp wrote: >> On 21/05/2017 14:14, Nagaev Boris wrote: >> Can they force an operator to decrypt, if he lives in other country >> which is non-US and non-EU (e.g. Russia or China)? Does it make sense >> to run nodes in countries you don't live in or visit? > > If poor odds or afraid of such things, the farther distant > and / or opposite legally, politically, logically and physically > the better. This is sound advice, at the same time I though that I did not like the prospect of being subjected to a contract with a foreign company when running a relay, i.e. being subjected to the law of another country. Of course this depends on which country you live in. C signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Memory Problems with tor releay
On Wed, May 24, 2017 at 07:51:50PM -0400, Roger Dingledine wrote: > Well, you are a winner, in that you found a new Tor bug (in > 0.3.1.1-alpha): > https://bugs.torproject.org/22368 > > Once we resolve that one, I'll ask for another valgrind run. :) Ok, we merged the fix for bug 22368. If anybody wants to resume running valgrind on git master to hunt for memory issues, we're eagerly awaiting more reports. :) --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Memory Problems with tor releay - restart tor automatically after failure
On Thu, 25 May 2017 08:54:00 + nusenu wrote: > I noticed your comment [1] about your plans to write a script that > restarts tor should it get killed. > > I just wanted to let you know that if you have plans to upgrade to > Ubuntu 16.04 you will get this out of the box due to systemd Restart= > [2] service configuration. > > [1] https://trac.torproject.org/projects/tor/ticket/22255#comment:23 > [2] > https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@.service#n20 > https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart= Or you can just put /etc/init.d/tor start | grep -v "already running" into your crontab at every 5 minutes or similar. If Tor is already running, this will not do anything, i.e. won't launch a duplicate or anything of that sort. And in case it crashed, you will get an E-Mail automatically (assuming you set up your crontab MAILTO= and system's MTA properly) telling you that it has been started (again), letting you to keep assessing frequency of the issue. -- With respect, Roman ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Memory Problems with tor releay - restart tor automatically after failure
Hi Dirk, I noticed your comment [1] about your plans to write a script that restarts tor should it get killed. I just wanted to let you know that if you have plans to upgrade to Ubuntu 16.04 you will get this out of the box due to systemd Restart= [2] service configuration. [1] https://trac.torproject.org/projects/tor/ticket/22255#comment:23 [2] https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@.service#n20 https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart= -- https://mastodon.social/@nusenu https://twitter.com/nusenu_ signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
