Re: [tor-relays] Relays not in cached consensus

> On 5 Feb 2018, at 10:37, Tyler Durden wrote: > > Hi > > Just ~3 weeks before the 34C3, two of our newer Exits were thrown out of > the consensus weight and since than never came back in. > I'm talking about: > geri (geri.enn.lu) 93FAB6F91C2EF33D0ACEEF7448177FCA2CEB99A0 > freki

[tor-relays] Relays not in cached consensus

Hi Just ~3 weeks before the 34C3, two of our newer Exits were thrown out of the consensus weight and since than never came back in. I'm talking about: geri (geri.enn.lu) 93FAB6F91C2EF33D0ACEEF7448177FCA2CEB99A0 freki (freki.enn.lu) C8AB1B2AF0CBAAE3611A814B4C7D38DCE0CBFEB4 We tried to purge the

[tor-relays] Disable CellStatistics to reduce RAM usage

Hi, If your relay is using too much RAM, please disable CellStatistics. (It's not on by default.) For more details, please see: https://trac.torproject.org/projects/tor/ticket/25141 https://trac.torproject.org/projects/tor/ticket/24806#comment:13 T

Re: [tor-relays] chutney debugging: (Sandbox) Caught a bad syscall attempt (syscall kill)

Hi Nick, > On 5 Feb 2018, at 00:36, tor7 wrote: > > (Sandbox) Caught a bad syscall attempt (syscall kill) > tor(+0x1853fa)[0x6141342b23fa] > /lib64/libc.so.6(kill+0x7)[0x75008527ace7] > /lib64/libc.so.6(kill+0x7)[0x75008527ace7] > tor(+0x1c3bab)[0x6141342f0bab] >

Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.

> So it seems to be something python2/python3 related. I'm not sure why I used > python3 to be honest. Interesting. Can't say there's anything that comes straight to mind that would cause that. I'd expect python2 and python3 to behave the same on this front. > P.S. If you want the logs, do you

[tor-relays] Disable CellStatistics !!!

After many crashes and much pain, I determined that having CellStatistics enabled causes a busy relay to consume at least two or three _gigabytes_ of additional memory. Relay operators with less than 16GB per instance are advised to disable it. By default CellStatistics is disabled unless

Re: [tor-relays] atlas.torproject.org: missing updated information for relays

it is back now. -- https://mastodon.social/@nusenu twitter: @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

Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.

Hi Stain, On 4 Feb 2018, at 14:56, Stian Fauskanger wrote: Hi Stijn, So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version specific, as I recently

Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.

Hi Damian, On Sat, Feb 3, 2018 at 2:10 PM, Stijn Jonker wrote: Hi All, So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version

Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.

Hi Stijn, So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version specific, as I recently upgraded the tor software on the nodes regularly. So on

[tor-relays] chutney debugging: (Sandbox) Caught a bad syscall attempt (syscall kill)

I'm trying chutney to measure my CPU, but it does not appear to work: chutney/tools/test-network.sh --flavour basic-min --data-bytes 104857600 test-network.sh: using CHUTNEY_DNS_CONF '/dev/null' test-network.sh: no $TOR_DIR, chutney will use $PATH for tor binaries test-network.sh: $CHUTNEY_PATH

Re: [tor-relays] tor cpu / MBit/s benchmarks

You asked: Is this the expected output? > On 4 Feb 2018, at 22:59, tor7 wrote: > > test000a is running with PID 963 > test001a is running with PID 966 > test002a is running with PID 969 > test003ba is running with PID 972 > test004r is running with PID 975 > test005r is

Re: [tor-relays] tor cpu / MBit/s benchmarks

> You can test how much Tor traffic your machine can handle with chutney: I'm asking to find out which CPU to buy (I don't have the hardware yet to test and would like to find out before buying), that is why I was asking others for their eperience. > git clone

Re: [tor-relays] atlas.torproject.org: missing updated information for relays

> searching for relays by fingerprint I always get the same information: > >Information for relays was published: 2018-02-02 19:00:00 UTC this is a known outage: https://lists.torproject.org/pipermail/tor-dev/2018-February/012881.html https://twitter.com/nusenu_/status/959764027072278529: >

Re: [tor-relays] issue with setting up a private bridge

On Sun, 4 Feb 2018 09:56:18 +0330 Hamid Safe wrote: > Hello tor-relays team, > > > > I am facing issue trying to set up a private obfs4proxy+tor relay > > bridge(centos 7 server) on a vps outside Iran and using the same > > methodology obfs4+tor client (Arch linux) inside