No dice, this solution did not solve the problem for me either. My VPS holds up well to a maximum traffic of this magnitude and the hardware resources are not used more than 50% but nevertheless it keeps shutting down and restarting the tor service up to a maximum Uptime of 3 hours (but often restarts earlier). I want to specify that it does not restart the VPS but only the tor service. I also do not detect any files in the path "/var/log/tor". I would not know what else to check. --- 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) mercoledì 27 marzo 2024 14:55, Alessandro Greco via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> ha scritto: > 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 tor-relays@xxxxxxxxxxxxxxxxxxxx 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] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D87C1222177BB099E55AE > > [2] https://community.torproject.org/relay/relays-requirements/ > > -------- Original Message -------- > > On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays@xxxxxxxxxxxxxxxxxxxx wrote: > > > > Dear Tor-Relays Mailing List Members, > > > > I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. > > > > Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. > > > > This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. > > > > As such, I'd like to pose some questions to the community to gather feedback and assess best practices: > > > > 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? > > > 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? > > > 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? > > > > Thank you in advance for your time and cooperation. > > > > Best regards, > > > Aleff. > > > > [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E3BE81E63056B > > > [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ > > > > --- > > > > 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)_______________________________________________ > > > tor-relays mailing list > > > tor-relays@xxxxxxxxxxxxxxxxxxxx > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > _______________________________________________ > > tor-relays mailing list > > tor-relays@xxxxxxxxxxxxxxxxxxxx > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays_______________________________________________ > > tor-relays mailing list > tor-relays@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Attachment:
publickey - alessandro.greco.1@protonmail.com - 0x1D14CC10.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays