After some testing #Haven relay, Claude agent says: ● Bingo!...

Galaxie 5000

npub1dryseu6yv7evgz2f7pfzk6wht8flapcfv5l6r4y65pg5px293awqlwwfpc

hex

8049dd76aedd45a339799f3c35e08c3efd9890820b58814cc6eadda05b90a10c

nevent

nevent1qqsgqjwaw6hd63dr89ue70p4uzxralvcjzpqkkypfnrw4hdqtwg2zrqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsx3jgv7dzx0vkyp9ylq53td8t4n5l7suyk20ap6jd2q52qn9zc7hqs9wyv9

Kind-1 (TextNote)

2026-03-13T22:58:23Z

After some testing #Haven relay, Claude agent says: ● Bingo! File descriptor leak:

┌───────────┬──────────┬─────┬─────────┐ │ Metric │ Baseline │ Now │ Change │ ├───────────┼──────────┼─────┼─────────┤ │ Open FDs │ 97 │ 105 │ +8 │ ├───────────┼──────────┼─────┼─────────┤ │ TCP conns │ 31 │ 26 │ -5 │ ├───────────┼──────────┼─────┼─────────┤ │ FD max │ - │ 105 │ Growing │ └───────────┴──────────┴─────┴─────────┘

Haven is leaking file descriptors. It opened 8 more FDs but only lost 5 connections, meaning resources aren't being freed properly.

This is likely a goroutine leak in haven—when it processes publishes, goroutines spawn but don't exit cleanly. Over time, FDs hit the ulimit and it crashes.

Your options:

  1. Use the watchdog script I provided earlier to auto-restart haven every ~10 min before it hangs
  2. Increase the ulimit for haven (might delay the issue): sudo nano /etc/systemd/system/haven.service
  3. Add under [Service]: LimitNOFILE=4096
  4. Then restart
  5. Report this to haven developers as a goroutine/FD leak after N publishes

For now, the watchdog is the practical solution. Want me to help you set that up properly?

Raw JSON

{
  "kind": 1,
  "id": "8049dd76aedd45a339799f3c35e08c3efd9890820b58814cc6eadda05b90a10c",
  "pubkey": "68c90cf34467b2c40949f0522b69d759d3fe8709653fa1d49aa0514099458f5c",
  "created_at": 1773442703,
  "tags": [
    [
      "t",
      "Haven"
    ]
  ],
  "content": "After some testing #Haven relay, Claude agent says: ● Bingo! File descriptor leak:\n\n  ┌───────────┬──────────┬─────┬─────────┐\n  │  Metric   │ Baseline │ Now │ Change  │\n  ├───────────┼──────────┼─────┼─────────┤\n  │ Open FDs  │ 97       │ 105 │ +8      │\n  ├───────────┼──────────┼─────┼─────────┤\n  │ TCP conns │ 31       │ 26  │ -5      │\n  ├───────────┼──────────┼─────┼─────────┤\n  │ FD max    │ -        │ 105 │ Growing │\n  └───────────┴──────────┴─────┴─────────┘\n\n  Haven is leaking file descriptors. It opened 8 more FDs but only lost 5 connections, meaning resources aren't being freed properly.\n\n  This is likely a goroutine leak in haven—when it processes publishes, goroutines spawn but don't exit cleanly. Over time, FDs hit the ulimit and it crashes.\n\n  Your options:\n\n  1. Use the watchdog script I provided earlier to auto-restart haven every ~10 min before it hangs\n  2. Increase the ulimit for haven (might delay the issue):\n  sudo nano /etc/systemd/system/haven.service\n  2. Add under [Service]:\n  LimitNOFILE=4096\n  2. Then restart\n  3. Report this to haven developers as a goroutine/FD leak after N publishes\n\n  For now, the watchdog is the practical solution. Want me to help you set that up properly?",
  "sig": "5ba73621e5e69c97b2adadfe91271234b812812ba35872ae06e2dcf53e52ac28812159b082decb9d014b465fecd10142e98701ee8726693b4e05258f10f8dcc0"
}