Relays do restart for different reasons. For example, two of my relays (the upgrade process is automated on both) were restarted on March 23rd, practically at the same time.
Different OS versions on different machines from different ISP for both relays.
One was restarted because some libraries needed to be upgraded on the system:
```
The following packages will be upgraded:
libbsd0 libc-bin libc6 libxslt1.1 locales
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[...]
Restarting services...
[...] tor@default.service [...]
```
The server even needed to be rebooted afterward.
The other one had a very different reason, as you can see from the syslog:
```
Mar 23 03:07:43 leslie kernel: [849147.801728] Out of memory: Killed process 930 (tor) tot al-vm:850180kB, anon-rss:620800kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:1652kB oom_score_adj:0
Mar 23 03:07:43 leslie systemd[1]: tor@Leslie.service: A process of this unit has been killed by the OOM killer.
Mar 23 03:07:44 leslie systemd[1]: tor@Leslie.service: Main process exited, code=killed, status=9/KILL
Mar 23 03:07:44 leslie systemd[1]: tor@Leslie.service: Failed with result 'oom-kill'.
Mar 23 03:07:44 leslie systemd[1]: tor@Leslie.service: Consumed 2d 5h 54min 39.122s CPU time.
Mar 23 03:07:44 leslie systemd[1]: tor@Leslie.service: Scheduled restart job, restart counter is at 1.
Mar 23 03:07:44 leslie systemd[1]: Stopped Anonymizi ng overlay network for TCP (instance Leslie).
Mar 23 03:07:44 leslie systemd[1]: tor@Leslie.service: Consumed 2d 5h 54min 39.122s CPU time.
Mar 23 03:07:44 leslie systemd[1]: Starting Anonymizing overlay network for TCP (instance Leslie)...
```
That was the last time both relays were restarted (~ 3 days ago)
Denny
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)