stable-diffusion-webui
stable-diffusion-webui copied to clipboard
AUTOMATIC1111
[Bug]: OSError: Port 7860 is in use. If a gradio.Blocks is running on the port, you can close() it or gradio.close_all().
Is there an existing issue for this?
- [X] I have searched the existing issues and checked the recent builds/commits
What happened?
When you reset the UI (apply changes, etc...) it causes this error in Linux (being far more secure than WIndows)
Steps to reproduce the problem
.
What should have happened?
It should just work as in Windows by applying what it said that I posted in the title.
Commit where the problem happens
3fe9e9e54dcfc41d7c5ee6976f83b0de29fd3dda
What platforms do you use to access UI ?
Windows, Linux
What browsers do you use to access the UI ?
Google Chrome, Microsoft Edge
Command Line Arguments
No response
Additional information, context and logs
No response
An alternative can be
gradio_blocks = gr.Blocks(port=8000)
you're specifying the gradio app to ran on port 8000
Another option is to use the following command
def my_function(x):
return x + 1
gr.Interface(fn=my_function, inputs="text", outputs="text", port=8888).launch()
What the code does it increments the port number by .So the first port number when running the app will be 7861. I hope this helps Good luck
I'm having the same issue, I'm using the --api --port {number} argument to change the port and this was no problem but now it is causing an issue and is claiming my port is in use when it most definitely isn't in use. This is on windows 10
Another option is to kill the PID using the following command
lsof -i :7868
Then using the folliwing to kill the PID
sudo <PID USER>
@TWIISTED-STUDIOS Kindly terminating the PID by killing the PID as explained earlier then let me know how it goes I would be more than glad to help
@TWIISTED-STUDIOS Kindly terminating the PID by killing the PID as explained earlier then let me know how it goes I would be more than glad to help
sorry only just seen this i feel that restarting the computer fixed the issue however its back again and im not sure what keeps causing it
@TWIISTED-STUDIOS Did you kill the PID If you didn't kill the PID try following the recommendation I gave you earlier in the comment section above
@TWIISTED-STUDIOS Did you kill the PID If you didn't kill the PID try following the recommendation I gave you earlier in the comment section above
Interestingly enough, I had a look through a list of all the processes and their respective ports that were in use to then be prepared to kill the PID of the process but to my surprise not a single process was using the listed port. So that was confusing. - you can rectify it by shutting down and rebooting, it's just an inconvenience.
I also have the same error, modify the port also did not help, I once had the same problem, reboot to solve, but this reboot also did not work.
Traceback (most recent call last): File "D:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\networking.py", line 121, in start_server s.bind((LOCALHOST_NAME, server_port)) PermissionError: [WinError 10013] Made an attempt to access the socket in a way that access rights are not allowed.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "D:\AI\stable-diffusion-webui\launch.py", line 38, in
I found this problem with：OSError: All ports from 7860 to 7959 are in use. Please close a port Same
Changing the port to a non - 7860 to 7959 port will fix it
Still facing this issue when using port 9900, and lsof -i:9900 shows nothing.
I know this is a old issue, but it seems no one has found a solution yet. I have found a solution that good work for me, so I want to share it here:
Firstly, this is not a webui or gradio issue, it's a Windows issue.
If you check the NAT tcp port exclusion range using netsh interface ipv4 show excludedportrange protocol=tcp, you will find 7860 falls within some range...
(I guess some cracking software takes advantage of Windows' port permission restrictions to achieve cracking, but fails to properly clean up the port permissions after finishing, leading to this issue).
So naturally, it's simple to just remove these restrictions, like this:
net stop winnat
netsh interface ipv4 show excludedportrange protocol=tcp
net start winnat
netsh interface ipv4 show excludedportrange protocol=tcp
Now the port should be free to use again.
UPDATE: one line to do it
net stop winnat && net start winnat
