Help

Re: Block run stopped identifying that port 9000 is busy

1519 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Ronen_Babayoff
7 - App Architect
7 - App Architect

Hey,

The cli used to be able to detect that ports are busy and have block run listen on 9002, 9004 etc, so I could run multiple blocks in parallel in my dev env. It stopped doing that. Right now it just prints that it listens on 9000 again, even though first block run listens on it.

I don’t know if it’s a cli version thing or an OS thing (I recently upgraded to WSL 2).

My current env:

WSL 2
Ubuntu 18.04
blocks-cli - 0.0.52

Thanks,
Ronen

6 Replies 6
Ronen_Babayoff
7 - App Architect
7 - App Architect

Hey @Kasra, it still happens in latest version of blocks-cli - 0.0.54.

Thanks for reporting this, we’ll investigate. I haven’t heard of other reports so far, so I suspect it’s something to do with WSL 2.

Additional info - turns out that even though I upgraded windows to latest version with wsl 2 support, my ubuntu 18.04 distro was still using wsl 1. Once I upgraded it to wsl 2 following the instructions here and here, block run didn’t work due too an EMFILE: too many open files error.

I’m going to increase open file descriptor limits on my distro to see if it fixes it, but didn’t have time to deal with it due to hackathon submissions, so I downgraded back to wsl 1. Once I try to increase limits on wsl 2, will let you know if it works and also fixed the port issue.

I haven’t been able to reproduce this behavior. From Powershell in the host:

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Running         2

And from within the VM:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04 LTS
Release:        20.04
Codename:       focal

$ node --version
v12.18.2

$ block --version
0.0.54

I bound an HTTP server to port 9000:

$ python3 -m http.server 9000
Serving HTTP on 0.0.0.0 port 9000 (http://0.0.0.0:9000/) ...

After executing block run, the CLI correctly reported that the default port was unavailable. It also rejected my attempt to insist on port 9000:

$ block run
? Port 9000 is taken, please provide an alternative port to run on: 9000
? Port 9000 is taken, please provide an alternative port to run on: 9001
Updating bundle...
Bundle updated

✅ Your block is running locally at https://localhost:9001
https://localhost:9001 has been copied to your clipboard

@Kasra_Kyanzadeh Does Airtable support WSL version 1? Should I attempt to reproduce the bug in that environment?

I’ve also tried reproducing this by using two parallel executions of block run (instead of python3 and block run), but everything seems to be working in that case, as well.

Ronen_Babayoff
7 - App Architect
7 - App Architect

Hey @Mike_Pennisi, thanks for trying to help.

@Kasra_Kyanzadeh, solved it by (documenting it here for others who run into the same problem):

  1. Upgrading to wsl 2

The EMFILE: too many open files could not be solved by increasing open file limits, because increasing open file limits on wsl 2 for a regular user using ulimit -n NEW_LIMIT doesn’t work. See reported bugs here and here.

  1. Due to that, I switched to developing with the root user (yes, bad idea, hopefully things will be solved by wsl team). To make root user default for wsl, I ran in a power shell:

ubuntu1804.exe config --default-user root

  1. Couldn’t install blocks-cli globally as root (similar error to the cli error recently reported in v0.0.53 I think), so I installed it using --save-dev and I’m running it using npx block run

After all of that, block run identifies busy ports… :grinning_face_with_sweat:

Cheers,
Ronen Babayoff
Superblocks.at