JVM_Bind 端口 8080 已在使用中 -- 但该端口上没有进程
[英]JVM_Bind port 8080 already in use -- but there are no processes on that port
问题描述
When attempting to do a mvn grails:run-app on my project, I get the JVM_Bind error that 8080 is already in use.
尝试在我的项目上执行 mvn grails:run-app 时，我收到 JVM_Bind 错误，即 8080 已在使用中。 I've been running this project with no problems up until an Eclipse crash in the middle of running it.我一直在运行这个项目，直到 Eclipse 在运行过程中崩溃为止。 I've rebooted my machine twice and it doesn't clear this up.我已经重新启动了我的机器两次，但它没有解决这个问题。 Netstat (netstat -ano) shows nothing on 8080. My tomcat is on 8088, and if I reconfigure it to run on 8080, it works fine, so that port is not in use. netstat (netstat -ano) 在 8080 上什么也没显示。我的 tomcat 在 8088 上，如果我重新配置它在 8080 上运行，它工作正常，因此该端口未使用。 It is only maven and/or grails that has this error.只有 maven 和/或 grails 有这个错误。 Any ideas how I can clear this up?有什么想法可以解决这个问题吗？
$ netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 752
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:623 0.0.0.0:0 LISTENING 7056
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 832
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING 960
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING 904
TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING 1128
TCP 0.0.0.0:1033 0.0.0.0:0 LISTENING 888
TCP 0.0.0.0:1034 0.0.0.0:0 LISTENING 5548
TCP 0.0.0.0:2701 0.0.0.0:0 LISTENING 4788
TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING 1688
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1452
TCP 0.0.0.0:4369 0.0.0.0:0 LISTENING 3644
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:5432 0.0.0.0:0 LISTENING 3604
TCP 0.0.0.0:5672 0.0.0.0:0 LISTENING 3544
TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING 2928
TCP 0.0.0.0:15672 0.0.0.0:0 LISTENING 3544
TCP 0.0.0.0:16992 0.0.0.0:0 LISTENING 7056
TCP 0.0.0.0:25672 0.0.0.0:0 LISTENING 3544
TCP 10.0.0.252:139 0.0.0.0:0 LISTENING 4
TCP 10.0.0.252:1060 74.125.22.188:5228 ESTABLISHED 7144
TCP 10.0.0.252:1062 168.159.224.143:443 ESTABLISHED 6316
TCP 10.0.0.252:55861 208.43.253.206:443 ESTABLISHED 7136
TCP 10.0.0.252:57299 141.101.112.192:443 CLOSE_WAIT 8160
TCP 10.0.0.252:57300 141.101.112.192:443 CLOSE_WAIT 8160
TCP 10.0.0.252:57301 141.101.112.192:443 CLOSE_WAIT 8160
TCP 10.0.0.252:57385 23.196.34.134:443 ESTABLISHED 7144
TCP 10.0.0.252:57430 208.43.253.206:443 CLOSE_WAIT 7136
TCP 10.0.0.252:57435 173.194.121.0:80 ESTABLISHED 7144
TCP 10.0.0.252:57442 173.194.121.14:443 ESTABLISHED 7144
TCP 10.0.0.252:57447 64.86.202.11:80 ESTABLISHED 7144
TCP 10.0.0.252:57456 168.159.218.174:443 ESTABLISHED 6316
TCP 10.0.0.252:57462 190.93.244.58:80 ESTABLISHED 7144
TCP 10.0.0.252:57463 74.125.228.217:80 TIME_WAIT 0
TCP 10.0.0.252:57470 23.196.2.197:80 ESTABLISHED 7144
TCP 127.0.0.1:1029 0.0.0.0:0 LISTENING 2028
TCP 127.0.0.1:1030 127.0.0.1:4369 ESTABLISHED 3544
TCP 127.0.0.1:1035 127.0.0.1:62522 ESTABLISHED 7416
TCP 127.0.0.1:1036 0.0.0.0:0 LISTENING 7136
TCP 127.0.0.1:1164 0.0.0.0:0 LISTENING 996
TCP 127.0.0.1:1165 0.0.0.0:0 LISTENING 7056
TCP 127.0.0.1:2559 0.0.0.0:0 LISTENING 7060
TCP 127.0.0.1:4369 127.0.0.1:1030 ESTABLISHED 3644
TCP 127.0.0.1:55018 0.0.0.0:0 LISTENING 3112
TCP 127.0.0.1:62522 0.0.0.0:0 LISTENING 1348
TCP 127.0.0.1:62522 127.0.0.1:1035 ESTABLISHED 1348
TCP [::]:80 [::]:0 LISTENING 4
TCP [::]:135 [::]:0 LISTENING 752
TCP [::]:445 [::]:0 LISTENING 4
TCP [::]:623 [::]:0 LISTENING 7056
TCP [::]:1025 [::]:0 LISTENING 832
TCP [::]:1026 [::]:0 LISTENING 960
TCP [::]:1027 [::]:0 LISTENING 904
TCP [::]:1028 [::]:0 LISTENING 1128
TCP [::]:1033 [::]:0 LISTENING 888
TCP [::]:1034 [::]:0 LISTENING 5548
TCP [::]:2701 [::]:0 LISTENING 4788
TCP [::]:3306 [::]:0 LISTENING 1688
TCP [::]:3389 [::]:0 LISTENING 1452
TCP [::]:5357 [::]:0 LISTENING 4
TCP [::]:5432 [::]:0 LISTENING 3604
TCP [::]:5672 [::]:0 LISTENING 3544
TCP [::]:8081 [::]:0 LISTENING 2928
TCP [::]:16992 [::]:0 LISTENING 7056
TCP [::1]:1166 [::1]:1168 ESTABLISHED 7056
TCP [::1]:1168 [::1]:1166 ESTABLISHED 7056
UDP 0.0.0.0:123 *:* 1092
UDP 0.0.0.0:500 *:* 1128
UDP 0.0.0.0:3702 *:* 1092
UDP 0.0.0.0:3702 *:* 4152
UDP 0.0.0.0:3702 *:* 1092
UDP 0.0.0.0:3702 *:* 4152
UDP 0.0.0.0:4500 *:* 1128
UDP 0.0.0.0:5355 *:* 1452
UDP 0.0.0.0:8082 *:* 2928
UDP 0.0.0.0:54654 *:* 4152
UDP 0.0.0.0:54960 *:* 7144
UDP 0.0.0.0:59195 *:* 1092
UDP 0.0.0.0:63291 *:* 1092
UDP 10.0.0.252:137 *:* 4
UDP 10.0.0.252:138 *:* 4
UDP 127.0.0.1:48000 *:* 7060
UDP 127.0.0.1:49153 *:* 3604
UDP 127.0.0.1:61532 *:* 6316
UDP [::]:123 *:* 1092
UDP [::]:500 *:* 1128
UDP [::]:3702 *:* 4152
UDP [::]:3702 *:* 4152
UDP [::]:3702 *:* 1092
UDP [::]:3702 *:* 1092
UDP [::]:4500 *:* 1128
UDP [::]:8082 *:* 2928
UDP [::]:54655 *:* 4152
UDP [::]:59196 *:* 1092
UDP [::]:63292 *:* 1092
2 个解决方案
解决方案1
1 已采纳 2015-07-02 21:30:54
The problem was not an already-bound port in use, it was an invalid IP address.问题不是正在使用的已绑定端口，而是无效的 IP 地址。 I had re-connected to my VPN and DHCP had given me a new IP address.我重新连接到我的 VPN，DHCP 给了我一个新的 IP 地址。 My binding in the grails application was to the old IP address.我在 grails 应用程序中绑定的是旧 IP 地址。 Changing to the new, valid IP address fixed the problem.更改为新的有效 IP 地址解决了该问题。 To verify this, I modified the grails IP binding to a known invalid IP address and it reproduced the problem.为了验证这一点，我修改了 grails IP 绑定到一个已知的无效 IP 地址，并重现了该问题。 This is a case of a bad or misleading error message.这是错误或误导性错误消息的一种情况。 Normally this error is caused by a process hanging on to the port, but in my situation, as my netstat output demonstrated, that was not the problem.通常，此错误是由挂在端口上的进程引起的，但在我的情况下，正如我的 netstat 输出所示，这不是问题。 So if anyone else has this problem, check on the ports and check your IP address.因此，如果其他人遇到此问题，请检查端口并检查您的 IP 地址。
解决方案2
1 2015-07-02 21:53:11
A Bind error is caused because a process is still registered using the respective port.由于进程仍在使用相应端口注册，因此会导致绑定错误。 This also includes zombie processes that haven't died and have been lost in the either.这还包括尚未死亡且已在两者中丢失的僵尸进程。
A reboot will clean this out, but as I am apposed to the reboot solution, you can use the netstat (same command on windows, linux & mac) command to find out the zombie process.重新启动将清除此问题，但正如我所支持的重新启动解决方案一样，您可以使用netstat （Windows、linux 和 mac 上的相同命令）命令来找出僵尸进程。
What you need is the netstat command, you will need to look at the documentation on each operating system (try netstat -? ), but usually what you're looking for is something like netstat -a , which will list all ports being used.您需要的是netstat命令，您需要查看每个操作系统的文档（尝试netstat -? ），但通常您要查找的是netstat -a类的东西，它将列出所有正在使用的端口。
What we are most interested in the ones that are in a state of LISTENING , which means that something has bound that port for listening, which will include your 8080 port.我们最感兴趣的是处于LISTENING状态的那些，这意味着某些东西已绑定该端口进行侦听，其中将包括您的8080端口。
Again, you will need to have a look at the command options as each OS has different options that will allow you to display the PID (process ID).同样，您需要查看命令选项，因为每个操作系统都有不同的选项，可以让您显示 PID（进程 ID）。 You can then use your 'Task Manager'/'Activity Monitor'/'top' app to then to match the PID with your running application, and kill that application.然后，您可以使用“任务管理器”/“活动监视器”/“top”应用程序将 PID 与正在运行的应用程序匹配，然后终止该应用程序。
In Mac you will need to also use the below command for getting the PID.在 Mac 中，您还需要使用以下命令来获取 PID。
lsof -i -U -P | grep "LISTEN"
Once you have killed that process, your port will then be available and you can then run your program without the JVM_Bind issue.一旦你杀死了那个进程，你的端口就会可用，然后你就可以运行你的程序而不会出现 JVM_Bind 问题。
PS One think to note also; PS 一想注也； Java won't bind ports that are under something like 1200, unless you're running as Administrator/root user. Java 不会绑定低于 1200 的端口，除非您以管理员/root 用户身份运行。 But your 8080 should be fine.但是你的8080应该没问题。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.