[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-relays] Re: Shutting down my ~40 guards
I did some digging with ai. Chatgpt wrote this raport. It happened midnight Finland time last night. I had no problem pushing over 2tb per day before with this small relay. I hope this helps:
Tor relay Atomirotta — circuit creation overload, memory exhaustion and OOM termination (25–26 October 2026)
Hello,
I operate a non-exit Tor relay named Atomirotta, running on a FreeBSD VPS. I would like to report a severe circuit creation overload event on 25–26 October 2026, which resulted in repeated circuit cleanup attempts and ultimately the FreeBSD kernel terminating the Tor process due to memory exhaustion.
Given the ongoing discussion about BEGIN_DIR flooding and resource exhaustion affecting Tor relays, I believe this incident may be relevant. I cannot currently confirm that BEGIN_DIR requests were responsible, as I do not have request-level metrics or debug logs.
Relay environment
Relay nickname: Atomirotta
Operating system: FreeBSD
Physical RAM: 1,033,318,400 bytes (approximately 985 MiB)
Swap: 1 GiB
ORPort: 9001
ExitRelay: 0
RelayBandwidthRate: 30 MBytes
RelayBandwidthBurst: 30 MBytes
MaxMemInQueues: 256 MB
Tor version during the incident: 0.4.9.13
Tor upgraded to 0.4.9.14 on 26 October at 06:20
The relay has previously sustained substantial throughput, including approximately 2.18 TiB of combined inbound and outbound traffic on 22 October, without a corresponding OOM termination recorded that day.
Incident timeline
All timestamps below are from the local system logs; the timezone has not yet been verified against UTC.
25 October, 23:17:46
The first visible warning appeared:
Your computer is too slow to handle this many circuit creation requests!
Please consider using the MaxAdvertisedBandwidth config option
or choosing a more restricted exit policy.
This warning subsequently repeated at a very high rate.
Examples of suppressed warning counts:
23:24:22 4,981 similar messages suppressed
23:27:36 8,577 similar messages suppressed
23:41:51 13,159 similar messages suppressed
23:43:05 7,388 similar messages suppressed
23:44:52 12,264 similar messages suppressed
23:49:40 5,690 similar messages suppressed
23:50:40 4,701 similar messages suppressed
Across the available incident log entries, the suppressed counts total more than 75,000 occurrences of this warning. These counts should not be interpreted as a direct measurement of distinct circuit creation requests.
25 October, 23:43:56
Tor reported memory pressure:
We're low on memory
(cell queues total alloc: 32548032
buffer total alloc: 588982272
tor compress total alloc: 0
rendezvous cache total alloc: 154830731).
Killing circuits with over-long queues.
Immediately afterward:
Removed 80491504 bytes by killing 414 circuits;
35590 circuits remain alive.
25 October, 23:44:57
The relay also reported HSDir cache pressure:
HSDir cache exceeded limit
(155001524 > 154997760 bytes).
Pruned 50015586 bytes during an HS descriptor upload.
25 October, 23:51:21–23:58:05
Repeated memory-pressure events continued:
23:51:23 Killed 446 circuits; 44085 remain
23:54:40 Killed 457 circuits; 48939 remain
23:58:05 Killed 535 circuits; 47809 remain
The number of remaining circuits increased substantially despite repeated cleanup.
26 October, 00:02–00:07
Further memory cleanup attempts:
00:02:48 Killed 469 circuits; 44703 remain
00:04:01 Killed 460 circuits; 44109 remain
00:06:04 Killed 482 circuits; 39943 remain
At 00:07:28, Tor again reported low memory.
Four seconds later, the FreeBSD kernel logged:
Oct 26 00:07:28 kernel: swap_pager: out of swap space
Oct 26 00:07:32 kernel: pid 61621 (tor), jid 0,
uid 256, was killed: failed to reclaim memory
Oct 26 00:07:33 kernel: pid 95576 (sshd-auth), jid 0,
uid 22, was killed: failed to reclaim memory
The system therefore experienced global memory exhaustion, not merely an application-level warning.
Previous OOM incidents
The FreeBSD kernel logs also show Tor being terminated due to memory exhaustion on:
27 September 2026, 19:56
13 October 2026, 05:27
18 October 2026, 01:57
26 October 2026, 00:07
A circuit creation overload warning is also present on 18 October at 01:25.
Current status
Following the upgrade to Tor 0.4.9.14, the relay was running with:
Tor RSS: 666232 KiB (~651 MiB)
Tor VSZ: 1336088 KiB
Swap used: 37 MiB
At the time of inspection, the process had been running for approximately 11 hours.
No additional circuit creation overload warnings were found in the available log after 26 October at 00:04:18. This does not establish whether the workload ended, changed, or was affected by the process restart or software upgrade.
Observations and questions
The incident appears to have involved an unusually high rate of circuit creation activity, a large number of concurrent circuits, repeated memory-pressure mitigation, and eventual kernel-level OOM termination.
This is consistent with a circuit-building resource-exhaustion scenario, but I cannot establish malicious intent or attribute the incident specifically to BEGIN_DIR flooding using the available notice-level logs.
In particular, I would appreciate guidance on:
Whether this failure pattern resembles the ongoing BEGIN_DIR or circuit-building DoS activity observed elsewhere in the Tor network.
Which metrics or logging facilities would best distinguish excessive circuit creation from BEGIN_DIR stream flooding, without imposing excessive overhead on a small relay.
Whether Tor 0.4.9.14 includes relevant mitigations for this specific workload, or whether additional fixes are expected.
Whether there are recommended resource-protection settings for low-memory, non-exit relays that preserve useful bandwidth capacity.
I can provide additional notice-level logs, system information and bandwidth statistics if useful.
Thank you for your work on Tor and for investigating the ongoing relay resource-exhaustion issues.
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx