Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management

2024-04-15 Thread Frank Lý via tor-relays 
Hello Aleff,

It should be okay as-is, but I would temporarily upgrade the hardware to 
determine if it is the root cause.

Frank

Apr 2, 2024, 10:34 AM by tor-relays@lists.torproject.org:

> My computer has:
> - 1 vCore CPU
> - 1 GB RAM
> - Maximum bandwidth: 1 GB/s
>
> So if I understand correctly, the problem should not be at the hardware 
> level, right?
>
>
> Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays <> 
> tor-relays@lists.torproject.org  Lý via tor-relays <> > ha scritto:
>
>> Hello Aleff,
>>
>> That is up to you. I strongly suspect that the hardware is the bottleneck, 
>> but detailed specifications are required in order to determine a conclusion. 
>> Tor is currently bounded by single-thread CPU performance, with a minimum 
>> recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If 
>> your hardware does not meet these RAM requirements, upgrade it, then adjust 
>> the relay bandwidth rate limit as necessary.
>>
>> Frank
>>
>> Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org:
>>
>> > I want to thank you for all the support replies you sent in response to my 
>> > previous communication. I have carefully read through all your insights 
>> > and appreciate your efforts in trying to find a solution to the issue.
>> >
>> > After thorough consideration of the matter, I have concluded that the 
>> > problem may not be due to configuration errors in the automatic updates, 
>> > as initially speculated. Rather, it seems that the issue could be 
>> > hardware-related, with my VPS computer potentially unable to handle a 
>> > certain amount of traffic.
>> >
>> > It's worth noting that there are no bandwidth issues, and the connection 
>> > speed is high. However, I have set a RelayBandwidthRate limit of 250 
>> > Mbits. Interestingly, despite this configuration, the Tor Metrics site 
>> > detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 
>> > Mbits. This led me to speculate that the machine might experience an 
>> > overload of operations or connections, causing it to crash temporarily. As 
>> > a result, at the time of restart, Tor Statistics records the maximum speed 
>> > reached up to that point (without ever reaching the set limit). 
>> > Subsequently, following this theory, the Tor service restarts 
>> > automatically without causing any anomalies in the service.
>> >
>> > To address this situation, I have decided to reduce the RelayBandwidthRate 
>> > limit from 250 Mbits to 100 Mbits, which falls within the minimum limits 
>> > proposed by torproject. If this is the case, however, it is also true that 
>> > it would be best to impose an upper limit of 80% when considering the 
>> > bandwidth magnitude involving the crash event as the maximum point. I 
>> > honestly don't know how I would be able to verify this and acquire this 
>> > kind of data, probably doing trial and error is the way. Perhaps the ideal 
>> > would be to lower the maximum bandwidth further to verify for sure that 
>> > this is what it is?
>> >
>> > Currently, I am closely monitoring the situation to assess whether this 
>> > modification has a positive impact on the issue.
>> >
>> > I will keep you updated on any progress, and I thank you once again for 
>> > your support and understanding.
>> >
>> > Best regards,
>> >
>> > Aleff.
>> >
>> > ---
>> >
>> > Browse my WebSite: aleff-gitlab.gitlab.io
>> > Use my PGP Public Key: 
>> > pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85
>> > Join to support:
>> > - Free Software Foundation! (my.fsf.org/join?referrer=6202114)
>> > - Electronic Frontier Foundation! (eff.org)
>> > - Tor-Project (torproject.org)
>> > - Signal (signal.org)
>> >
>> > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays 
>> >  ha scritto:
>> >
>> >> Hi Alessandro,
>> >>
>> >> It's good to hear from you. I have a relay in a somewhat similar 
>> >> situation[1], although I've only just clocked it. If you're using Debian 
>> >> or one of its derivatives, then you can configure the unattended-upgrades 
>> >> package to perform a restart at a specific time if required. This means 
>> >> that your relay won't restart every time an upgrade is required, but will 
>> >> keep itself up to date. I think configuring a time for a daily restart 
>> >> (if upgrade required) would be a fairly good balance between stability 
>> >> and reliability.
>> >>
>> >> See what other people say or from your own experience, as Tor circuits 
>> >> are generally quite resilient and as long as you aren't a guard node I 
>> >> believe connections won't die because your relay is restarting.
>> >>
>> >> I would also note that Tor recommends [2] an uptime or 24/7 is nice, but 
>> >> not required and that restarts to the daemon or node are fine. Because of 
>> >> this, it might not be worth worrying too much about this issue.
>> >>
>> >> I hope you find some of this useful,
>> >> Seth
>> >>
>> >>
>> >>
>> >> [1] 
>> >> ht

Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management

2024-04-04 Thread Alessandro Greco via tor-relays 
I made the changes you recommended and also added/edited these parameters in 
the torrc configuration file:
- RunAsDaemon 1
- RelayBandwidthRate 10 MB
- RelayBandwidthBurst 20 MB

But in spite of that I did not solve the problem.

I monitored via nyx what was happening on service reboot and noticed that it 
detects the tor control port closed. Regarding this setting in the torrc file I 
wrote.

- ControlPort 9051
- CookieAuthentication 1

And trying to run nmap to see if port 9051 is open it shows me open in 
LISTENING mode.

To make what I tried to report in this email clearer I have uploaded a 
15-second video[1] that captures the exact moment when the shutdown occurs 
where you can see that at first port 9051 is working properly while at some 
point it seems to shut down automatically.


It's possible that the Tor service never ceases to function, but for some 
strange reason, the port 9051 stops functioning, preventing the control of Tor 
itself. As a result, it may appear that Tor has restarted, when in fact the 
uptime simply resets because the port 9051 is unreachable for a certain period 
of time.



[1] https://vimeo.com/930658793



martedì 2 aprile 2024 23:24, denny.obre...@a-n-o-n-y-m-e.net 
 ha scritto:

> You should tweak your web server as presented in this section:
> 

> 

> 

> https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-preparing-your-system-for-high-number-of-connections
> 

> 

> 

> This would most likely solve Out-Of-Memory problems I suspect you are 
> experiencing.
> 

> 

> 

> Denny
> 

> 

> On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote ..
> 

> > My computer has:
> > - 1 vCore CPU
> > - 1 GB RAM
> > - Maximum bandwidth: 1 GB/s
> > 

> > So if I understand correctly, the problem should not be at the hardware 
> > level, right?
> > 

> > 

> > Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays 
> >  ha scritto:
> > 

> > > Hello Aleff,
> > > 

> > > That is up to you. I strongly suspect that the hardware is the 
> > > bottleneck, but detailed specifications are required in order to 
> > > determine a conclusion. Tor is currently bounded by single-thread CPU 
> > > performance, with a minimum recommendation of 1 GB of RAM for non-exit 
> > > relays faster than 40 Mbit/s. If your hardware does not meet these RAM 
> > > requirements, upgrade it, then adjust the relay bandwidth rate limit as 
> > > necessary.
> > > 

> > > Frank
> > > 

> > > Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org:
> > > 

> > > > I want to thank you for all the support replies you sent in response to 
> > > > my previous communication. I have carefully read through all your 
> > > > insights and appreciate your efforts in trying to find a solution to 
> > > > the issue.
> > > >
> > > > After thorough consideration of the matter, I have concluded that the 
> > > > problem may not be due to configuration errors in the automatic 
> > > > updates, as initially speculated. Rather, it seems that the issue could 
> > > > be hardware-related, with my VPS computer potentially unable to handle 
> > > > a certain amount of traffic.
> > > >
> > > > It's worth noting that there are no bandwidth issues, and the 
> > > > connection speed is high. However, I have set a RelayBandwidthRate 
> > > > limit of 250 Mbits. Interestingly, despite this configuration, the Tor 
> > > > Metrics site detects a spee d of approximately 10/13 MBytes, equivalent 
> > > > to about 90/110 Mbits. This led me to speculate that the machine might 
> > > > experience an overload of operations or connections, causing it to 
> > > > crash temporarily. As a result, at the time of restart, Tor Statistics 
> > > > records the maximum speed reached up to that point (without ever 
> > > > reaching the set limit). Subsequently, following this theory, the Tor 
> > > > service restarts automatically without causing any anomalies in the 
> > > > service.
> > > >
> > > > To address this situation, I have decided to reduce the 
> > > > RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls 
> > > > within the minimum limits proposed by torproject. If this is the case, 
> > > > however, it is also true that it would be best to impose an upper limit 
> > > > of 80% when considering the bandwidth magnitude involving the crash 
> > > > event as the maximum point. I honestly don't know how I would be able 
> > > > to verify this and acquire this kind of data, probably doing trial and 
> > > > error is the way. Perhaps the ideal would be to lower the maximum 
> > > > bandwidth further to verify for sure that this is what it is?
> > > >
> > > > Currently, I am closely monitoring the situation to assess whether this 
> > > > modification has a positive impact on the issue.
> > > >
> > > > I will keep you updated on any progress, and I thank you once again for 
> > > > your support and understanding.
> > > >
> > > > Best regards,
> > > >
> > > > Aleff.
> > > >
> > > > ---
> > > >
> > > > Browse my WebSite:

Re: [tor-relays] R: Re: Request for Feedback on Relay Node Update Management

2024-04-04 Thread John Crow via tor-relays 
Hello, My computer has:- 1 vCore CPU- 1 GB RAM- Maximum bandwidth: 1 GB/sSo if 
I understand correctly, the problem should not be at the hardware level, 
right?For running a relay, I definitely recommend you upgrade to at least 2gb 
of Ram per vCore or 2GB per 1 Tor instance. On my fleet of relays the minimum 
spec I use is 2vCores and 4GB ram.
John - prsv admin


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] R: Re: Request for Feedback on Relay Node Update Management

2024-04-02 Thread denny . obreham 
   You should tweak your web server as presented in this section:

   https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-prep
   aring-your-system-for-high-number-of-connections

   This would most likely solve Out-Of-Memory problems I suspect you are
   experiencing.

   Denny
   On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote ..

   My computer has:

   - 1 vCore CPU

   - 1 GB RAM

   - Maximum bandwidth: 1 GB/s

   So if I understand correctly, the problem should not be at the hardware
   level, right?

 Il mar, apr 2, 2024 alle 12:14, Frank Lý via tor-relays
 <[1]tor-relays@lists.torproject.org> ha scritto:

 Hello Aleff,
 That is up to you. I strongly suspect that the hardware is the
 bottleneck, but detailed specifications are required in order to
 determine a conclusion. Tor is currently bounded by single-thread
 CPU performance, with a minimum recommendation of 1 GB of RAM for
 non-exit relays faster than 40 Mbit/s. If your hardware does not
 meet these RAM requirements, upgrade it, then adjust the relay
 bandwidth rate limit as necessary.
 Frank
 Mar 27, 2024, 7:00 AM by tor-relays@lists.torproject.org:
 > I want to thank you for all the support replies you sent in
 response to my previous communication. I have carefully read through
 all your insights and appreciate your efforts in trying to find a
 solution to the issue.
 >
 > After thorough consideration of the matter, I have concluded that
 the problem may not be due to configuration errors in the automatic
 updates, as initially speculated. Rather, it seems that the issue
 could be hardware-related, with my VPS computer potentially unable
 to handle a certain amount of traffic.
 >
 > It's worth noting that there are no bandwidth issues, and the
 connection speed is high. However, I have set a RelayBandwidthRate
 limit of 250 Mbits. Interestingly, despite this configuration, the
 Tor Metrics site detects a speed of approximately 10/13 MBytes,
 equivalent to about 90/110 Mbits. This led me to speculate that the
 machine might experience an overload of operations or connections,
 causing it to crash temporarily. As a result, at the time of
 restart, Tor Statistics records the maximum speed reached up to that
 point (without ever reaching the set limit). Subsequently, following
 this theory, the Tor service restarts automatically without causing
 any anomalies in the service.
 >
 > To address this situation, I have decided to reduce the
 RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls
 within the minimum limits proposed by torproject. If this is the
 case, however, it is also true that it would be best to impose an
 upper limit of 80% when considering the bandwidth magnitude
 involving the crash event as the maximum point. I honestly don't
 know how I would be able to verify this and acquire this kind of
 data, probably doing trial and error is the way. Perhaps the ideal
 would be to lower the maximum bandwidth further to verify for sure
 that this is what it is?
 >
 > Currently, I am closely monitoring the situation to assess whether
 this modification has a positive impact on the issue.
 >
 > I will keep you updated on any progress, and I thank you once
 again for your support and understanding.
 >
 > Best regards,
 >
 > Aleff.
 >
 > ---
 >
 > Browse my WebSite: aleff-gitlab.gitlab.io
 > Use my PGP Public Key:
 pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85
 > Join to support:
 > - Free Software Foundation! (my.fsf.org/join?referrer=6202114)
 > - Electronic Frontier Foundation! (eff.org)
 > - Tor-Project (torproject.org)
 > - Signal (signal.org)
 >
 > martedì 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays ha
 scritto:
 >
 >> Hi Alessandro,
 >>
 >> It's good to hear from you. I have a relay in a somewhat similar
 situation[1], although I've only just clocked it. If you're using
 Debian or one of its derivatives, then you can configure the
 unattended-upgrades package to perform a restart at a specific time
 if required. This means that your relay won't restart every time an
 upgrade is required, but will keep itself up to date. I think
 configuring a time for a daily restart (if upgrade required) would
 be a fairly good balance between stability and reliability.
 >>
 >> See what other people say or from your own experience, as Tor
 circuits are generally quite resilient and as long as you aren't a
 guard node I believe connections won't die because your relay is
 restarting.
 >>
 >> I would also note that Tor recommends [2] an uptime or 24/7 is
 nice, but not required and that restarts to the daemon or node are
 fine. Because o