[Errno 10048] error while attempting to bind on address ('::1', 8081, 0, 0): only one usage of each socket address (protocol/network address/port) is normally permitted

I am working on a Windows 10 Laptop (by DELL). Prodigy and jupyterlab extension are successfully installed. This can be understood by the following:



Now, when I run prodigy in jupyterlab, the following error pops up:

Now, I tried finding out the processes that run on port 8081, and resource monitor gives the following before running this cell:

and after the error pops up:

Even when I tried changing the port of running to some other port which is not used by any other processes in the system, the same error pops up with the new port.
Please help me out

Thanks for the detailed report – this is strange, I haven't seen this issue before :thinking: 8081 is the port you're using for Prodigy, right? It seems like it tries to start the server a second time. Does it work without the extensions and/or if yourun Prodigy from the terminal?

Yes, the port 8081is used by prodigy only.
This error has been appearing from the first time the server started, the exact same error, That too for all changes of ports in app.py .
So, I tried doing the same with anaconda terminal , it worked perfectly.
But only after installing 'murmurhash', in that too the same error came in the beginning. Port 8081 on localhost ran Prodigy well.


The processes that run during this are the same as the one when I run from JupyterLab.

After insalling the module, in jupyterlab the command runs properly, yet giving the error, but still running.

Ah, that's interesting – maybe JupyterLab is somehow swallowing the error here and this was the actual problem. Prodigy failed because your environment was missing a dependency, but you only saw the port error (which is weird and something we need to investigate, but doesn't actually make a difference).

Anyway, glad it's working now! I think the underlying problem we should look into here is how to make sure that errors that occur while serving Prodigy are raised correctly. It's possible that the new async app has an impact here and causes this, but I'm not 100% sure.

Yes, that was the actual issue. It would be great if the murmurhash package came with the installation of Prodigy package, it didn't come for me.
The extension jupyterlab-prodigy needs to be improved too.
Thanks for your time and support. :grin:

I faced the error that is very similar to yours (ERROR: [Errno 10048] error while attempting to bind on address ('127.0.0.1', 8080): only one usage of each socket address (protocol/network address/port) is normally permitted). I tried all the methods offered by google but failed. So, how do you solve this error? Can you please say it in detail? Thank you!

1 Like

@hujukee Are you able to run Prodigy from a terminal? Maybe you're facing a similar problem and there's an underlying error that's the real problem and that doesn't get shown in Jupyter.

Also, did you try setting a different "port" in your prodigy.json?

Ah, I now get it!!! Setting a different "port" in my prodigy.json is really makes sense. Thank you very much, Ines. :blush:

1 Like

I actually did try changing the port in prodigy.json.
It didn't work. I would suggest you to try doing that. And if that doesn't work, you can try installing the murmurhash package through the terminal in the respective working environment.

i got the same error as above (also working under windows 10 in jupyterlab).
Installing murmurhash does not show any effect.
I also changed the port for the prodigy localhost to e.g. 8081.

The Main Problem is that once a prodigy session is started i dont seem to be able to terminate it anymore.
So it isnt possible to start another prodigy process with e.g. a different dataset unless i terminate the sessions kernel of the jupyterlab session.

Starting and Terminating Sessions from the console works fine however.

I think this comes down to how Jupyter / JupyterLab handles a server that's started in a cell and how it lets you terminate it. This thread has some approaches that might be more convenient than restarting the whole kernel:

Thank you. That solved it. :slight_smile: