Share more insights on the type of HSDir flood requests with Tor 0.4.9.14 using custom metrics proposed in https://gitlab.torproject.org/tpo/core/tor/-/work_items/41460 Optimistic 0.4.9.15 will rate limit some of these. Will find out soon! Over a 48 hour period, across ~300 relays, tracked 30 different flood windows averaging around 2.5 hours. 1. Descriptor fetching dominates. Relay O (chart 1) recorded 14,526,740 fetches—99.8% of its counted streams. Uploads accounted for 26,651 requests (0.18%). Ten other relays also had fetch-majority periods. 2. HTTP-wait closures dominate. Relay T (chart 2) recorded 57,501,531 such closures—98.2% of its streams. Tor was still waiting for an HTTP request, with an empty input buffer and no earlier request classification. Parsing failures are counted separately. Thirteen other relays also had HTTP-wait-majority periods. 3. The majority type can change. Relay J (chart 3) recorded 99.8% fetches (27,345,592 requests) in the earlier period. In the later period, 72.0% were HTTP-wait closures (22,764,459 streams). One other relay, N, also changed majority category. https://1aeo.com/blog/repeat-descriptor-fetches-tor-floods.html Attached summary and detailed charts. On Monday, October 26th, 2026 at 8:59 AM, kullikovana via tor-relays <tor-relays@lists.torproject.org> wrote:
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@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
