Trying to run bun with --inspect crashes with Failed to start server.

[thomasdarimont]

What version of Bun is running?

1.0.2+37edd5a6e389265738e89265bcbdf2999cb81a49

What platform is your computer?

Linux 6.4.15-100.fc37.x86_64 x86_64 x86_64

What steps can reproduce the bug?

index.ts:

const server = Bun.serve({
    port: 3000,
    fetch(req) {
      return new Response("Bun!");
    },
  });
  
  console.log(`Listening on http://localhost:${server.port} ...`);

Then run:

bun run --inspect index.ts

What is the expected behavior?

I'd expect no crash and an URL for the web debugger debug.bun.sh being printed to the console.

What do you see instead?

$ bun run --inspect index.ts  
Failed to start inspector:
 127 |   }
128 |   get url() {
129 |     return this.#url;
130 |   }
131 | 
132 |   #listen() {
                     ^
error: Failed to start server. Is port 6499 in use?
      at #listen (internal:debugger:132:18)
      at new Debugger (internal:debugger:118:26)
      at internal:debugger:94:24

Additional information

No response

[Electroid]

If Bun fails to open the inspector on 6499, it should probably just use 0 for the next attempt.

[thomasdarimont]

Even if I specify a custom port via --inspect=42424 it still fails with a message similar to the one above (with the new port number).

[etorhub]

I am having the same issue, but only when using bun inside a docker container, even though I expose that particular port.

[JStaWZL]

I had the same error with the debugger. I wondered because the port mentioned in the error message is not in use on my system. So I traced the system calls of bun --inspect index.ts using strace and found out that the debugger tries to bind its port to an IPv6 address ('::1') instead of an IPv4 address and this apparently is why it failed for me. Further up in the trace I figured out that bun looks up my /etc/hosts file and seems to get the idea of using the IPv6 address for binding the debugger to a network interface from that. My /etc/hosts file had for 'localhost' an IPv4 address entry and the IPv6 entry which bun attempted to use for its debugger. Removing 'localhost' from the IPv6 entry imediately made it possible to start bun with the debugger and the debugger was accessable via my browser. I currently don't know enough though to tell which system is actually at fault here or what the proper fix would be.

[lg]

same as @JStaWZL. removing ::1 localhost,... from the /etc/hosts file from my VSCode Dev Container fixed it. i dont have ipv6 in this dev container at all, so that's perhaps the issue.

[mohas]

I have the same issue suddenly! one thing that bugs me is that bun spawns the inspector when I use bun run event without --inspect option! it starts it using a port and throws EADDRINUSE error on that same port! I'm using bun 1.1.34 on windows 10 machine

[Komodood]

The same problem, today, for some reason, bun decided to run inspector on my machine, although the --inspect flag is not used. I didn't do any updates, bun -v: 1.1.34

Important

updating to the latest version resolves the issue with the inspect flag

$ bunx --bun vite --port 9001 --host
Failed to start inspector:
 44 |       };
45 |     }, this.#listen();
46 |   }
47 |   get url() {
48 |     return this.#url;
49 |   #listen() {
              ^
EADDRINUSE: Failed to start server. Is port 52479 in use?
 syscall: "listen"

      at #listen (internal:debugger:49:10)
      at new Debugger (internal:debugger:35:14)
      at internal:debugger:3:13

error: script "dev" exited with code 1

p.s. after restarting the system, the port became available, but the second project on bun does not turn on due to the same error, although the inspect flag is set to a different port:

$ bun tsc && bun --inspect=4000 --watch run src/index.ts
Failed to start inspector:
 44 |       };
45 |     }, this.#listen();
46 |   }
47 |   get url() {
48 |     return this.#url;
49 |   #listen() {
              ^
EADDRINUSE: Failed to start server. Is port 52479 in use?
 syscall: "listen"

      at #listen (internal:debugger:49:10)
      at new Debugger (internal:debugger:35:14)
      at internal:debugger:3:13

error: script "dev" exited with code 1

[RiskyMH]

@Komodood I believe your issue is #15425 and it was due to a bug in vscode extension (which the fix should release soon). The erroring of connection should also be fixed in canary (and release soon too): bun upgrade --canary

[Komodood]

@Komodood I believe your issue is #15425 and it was due to a bug in vscode extension (which the fix should release soon). The erroring of connection should also be fixed in canary (and release soon too): bun upgrade --canary

thanks for answering, extension now is disabled, but maybe i am not restarted vscode. After reopen project, all work well