Pewarta Proxy

📋 Server Request & Proxy Logs

Loading active proxy settings...
Developed by Khairul Adha (adhexa.id)
Mengambil log server...

⚙️ Pengaturan Proxy Target

Skip to content

OrbStack crashes when internet connection drops briefly #2322

Closed

Description

@panoptican

Describe the bug

Not sure what the bug is exactly, but here is my pure speculation.

  • It seems like OrbStack crashes when internet connection drops briefly with gluetun VPN container running
  • "tooManyInterfaces" error appears in logs might be an alternate explanation, but there are only 14 interface

In any case, this is what specifically has been happening, whatever the cause:

  • OrbStack completely crashes
  • All containers stop
  • "failed to add network" error=tooManyInterfaces appears in logs
  • Requires manual OrbStack restart to recover

To Reproduce

No response

Expected behavior

No response

Diagnostic report (REQUIRED)

OrbStack info:
Version: 2.0.5
Commit: cfe47627f138ffd822c958553b0a93eaf2692c71 (v2.0.5)

System info:
macOS: 15.5 (24F74)
CPU: arm64, 10 cores
CPU model: Apple M4
Model: Mac16,10
Memory: 16 GiB

Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-01-30T19-21-20.051980Z.zip

Screenshots and additional context (optional)

No response

Activity

  1. paunadeu commented on Mar 18, 2026

    @paunadeu

    Happening here too.
    Disconnected mount popup is also appeaing

  2. ericmeadows commented on Mar 31, 2026

    @ericmeadows

    Same!

  3. added this to the v2.1.4 milestone on May 23, 2026
  4. kdrag0n commented on May 23, 2026

    @kdrag0n
    Member

    Fixed for the next version.

  5. kdrag0n commented on Jun 4, 2026

    @kdrag0n
    Member

    Released in v2.2.0.

  6. kaloona commented on Aug 30, 2026

    @kaloona

    I hit this on OrbStack v2.2.3 (Docker 29.4.0), so whatever landed for the v2.2.0 milestone doesn't fully fix it.

    Sequence from ~/.orbstack/log/vmgr.log last night:

    🌸 agent:docker | time="08-29 22:52:49" level=error msg="failed to add network" error="too many interfaces" network=watchtower_default
    ...
    🌸 agent:docker | time="08-30 02:33:51" level=error msg="failed to add network" error="too many interfaces" network=bridge
    🌸 agent:docker | time="08-30 02:33:51" level=error msg="failed to add network" error="too many interfaces" network=mcp-camoufox_mcp-camoufox-net
    🌸 agent:docker | time="08-30 02:33:51" level=error msg="failed to add network" error="too many interfaces" network=searxng_searxng_internal
    🌸 agent:docker | time="08-30 02:33:51" level=error msg="failed to add network" error="too many interfaces" network=sitepins_sitepins-net
    🌸 agent:docker | time="08-30 02:33:51" level=error msg="failed to add network" error="too many interfaces" network=watchtower_default
    

    (repeats identically every few seconds for ~30 min, across every network on the host, not just one)

    It escalated into a full VM crash:

    🌲 vmgr | time="08-30 03:06:31" level=info msg="stop requested" reason=9
    🌲 vmgr | time="08-30 03:06:31" level=error msg="VM force stop failed" error="force stop already requested"
    2026-08-30 03:06:33.499 OrbStack[96835:...] Daemon exited: I/O error
    

    After that the VM stayed in Stopped state until I manually ran orb start — several hours of downtime for every container on the host.

    A few things that might help narrow it down:

    • At the time this started, the host had ~70 network interfaces total (46 veth, 13 br-*) — nowhere near any real kernel limit, consistent with the other report here of it happening at just 14 interfaces. So tooManyInterfaces looks like a bug in the agent's own interface accounting, not an actual resource exhaustion.
    • I checked macOS's configd logs (via log show) around both error timestamps and found no interface/connectivity state change — no Wi-Fi drop, no DHCP renewal, nothing. So at least in this case it doesn't look like it needs an actual "internet connection drop" to trigger; it may be firing on its own periodic reconciliation.
    • No crash-looping containers, no VPN/gluetun container running here, restart counts were all 0 except one unrelated container with 1 restart — so it's not caused by container churn on my end either.

    Happy to share the full vmgr.log if useful.

  7. JackCA commented on Sep 11, 2026

    @JackCA

    Happening here as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    t/bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions