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@lists.torproject.org> 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@lists.torproject.org 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@lists.torproject.org 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@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_______________________________________________ > > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
publickey - alessandro.greco.1@protonmail.com - 0x1D14CC10.asc
Description: application/pgp-keys
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
