Killed process blocks TCP ports
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I've had this issue on several machines. Is there some way to free this blocked port? Here is an example:
Let me explain. I've killed some JAVA-Process on SUSE Linux Enterprise Server 11 SP4, which had some ports open. I used the command "kill -9 " with root user. Now it is not possible to start the process again, because the port is still blocked. The application dies when the port is still open. But the process is definitively gone!
When I have a look with command netstat -anop | grep -E "Sta|37941"
(also with root user), I'll get the following results:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer
[...]
tcp 0 0 172.21.63.27:42034 172.21.63.28:37941 ESTABLISHED - keepalive (2861.75/0/0)
[...]
It shows no PID! Before killing the process, it showed the PID of the process. Is there any way to free such a "dead" port? We are always need to restart the operating system to get the application started again. But this is really, really critical in our high-availability systems... so what to do if we need to kill the process in the future? This issue also happened on other unix operating systems in the past.
Any help in solving this issue for the future would be highly appreciated. Thank you all very much in advance!
process kill netstat
 |Â
show 1 more comment
up vote
0
down vote
favorite
I've had this issue on several machines. Is there some way to free this blocked port? Here is an example:
Let me explain. I've killed some JAVA-Process on SUSE Linux Enterprise Server 11 SP4, which had some ports open. I used the command "kill -9 " with root user. Now it is not possible to start the process again, because the port is still blocked. The application dies when the port is still open. But the process is definitively gone!
When I have a look with command netstat -anop | grep -E "Sta|37941"
(also with root user), I'll get the following results:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer
[...]
tcp 0 0 172.21.63.27:42034 172.21.63.28:37941 ESTABLISHED - keepalive (2861.75/0/0)
[...]
It shows no PID! Before killing the process, it showed the PID of the process. Is there any way to free such a "dead" port? We are always need to restart the operating system to get the application started again. But this is really, really critical in our high-availability systems... so what to do if we need to kill the process in the future? This issue also happened on other unix operating systems in the past.
Any help in solving this issue for the future would be highly appreciated. Thank you all very much in advance!
process kill netstat
2
Are you settingSO_REUSEADDR
? Also don't usekill -9
, it does not let things clean up.
â thrig
Nov 10 '17 at 0:30
This is what @thrig mentioned in his comment above: docs.oracle.com/javase/7/docs/api/java/net/â¦
â Andy Dalton
Nov 10 '17 at 1:09
Is it complaining about port 37941? The line you quote doesnâÂÂt indicate that itâÂÂs open locally...
â Stephen Kitt
Nov 10 '17 at 5:45
@StephenKitt The problem is that the OS thinks there's still a process listening on this port. When the JVM is started again it fails, because the port is already "occupied", what means it cannot start listening on that port.The adress 172.21.63.27 is the adress of the host, where the JVM was running and the adress of the host where I tried to start the JVM again.
â mstrd308
Nov 13 '17 at 13:32
@thrig I don't know, it is configured as the JVM remote debug port, I don't know how the JVM handles this connections. Btw same thing happened with the JMX port of the JVM. And unfortunately there are some situations, where it is not possible to "clean" stop the process, where it needs to be "hard stopped".
â mstrd308
Nov 13 '17 at 13:32
 |Â
show 1 more comment
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I've had this issue on several machines. Is there some way to free this blocked port? Here is an example:
Let me explain. I've killed some JAVA-Process on SUSE Linux Enterprise Server 11 SP4, which had some ports open. I used the command "kill -9 " with root user. Now it is not possible to start the process again, because the port is still blocked. The application dies when the port is still open. But the process is definitively gone!
When I have a look with command netstat -anop | grep -E "Sta|37941"
(also with root user), I'll get the following results:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer
[...]
tcp 0 0 172.21.63.27:42034 172.21.63.28:37941 ESTABLISHED - keepalive (2861.75/0/0)
[...]
It shows no PID! Before killing the process, it showed the PID of the process. Is there any way to free such a "dead" port? We are always need to restart the operating system to get the application started again. But this is really, really critical in our high-availability systems... so what to do if we need to kill the process in the future? This issue also happened on other unix operating systems in the past.
Any help in solving this issue for the future would be highly appreciated. Thank you all very much in advance!
process kill netstat
I've had this issue on several machines. Is there some way to free this blocked port? Here is an example:
Let me explain. I've killed some JAVA-Process on SUSE Linux Enterprise Server 11 SP4, which had some ports open. I used the command "kill -9 " with root user. Now it is not possible to start the process again, because the port is still blocked. The application dies when the port is still open. But the process is definitively gone!
When I have a look with command netstat -anop | grep -E "Sta|37941"
(also with root user), I'll get the following results:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer
[...]
tcp 0 0 172.21.63.27:42034 172.21.63.28:37941 ESTABLISHED - keepalive (2861.75/0/0)
[...]
It shows no PID! Before killing the process, it showed the PID of the process. Is there any way to free such a "dead" port? We are always need to restart the operating system to get the application started again. But this is really, really critical in our high-availability systems... so what to do if we need to kill the process in the future? This issue also happened on other unix operating systems in the past.
Any help in solving this issue for the future would be highly appreciated. Thank you all very much in advance!
process kill netstat
asked Nov 10 '17 at 0:03
mstrd308
1
1
2
Are you settingSO_REUSEADDR
? Also don't usekill -9
, it does not let things clean up.
â thrig
Nov 10 '17 at 0:30
This is what @thrig mentioned in his comment above: docs.oracle.com/javase/7/docs/api/java/net/â¦
â Andy Dalton
Nov 10 '17 at 1:09
Is it complaining about port 37941? The line you quote doesnâÂÂt indicate that itâÂÂs open locally...
â Stephen Kitt
Nov 10 '17 at 5:45
@StephenKitt The problem is that the OS thinks there's still a process listening on this port. When the JVM is started again it fails, because the port is already "occupied", what means it cannot start listening on that port.The adress 172.21.63.27 is the adress of the host, where the JVM was running and the adress of the host where I tried to start the JVM again.
â mstrd308
Nov 13 '17 at 13:32
@thrig I don't know, it is configured as the JVM remote debug port, I don't know how the JVM handles this connections. Btw same thing happened with the JMX port of the JVM. And unfortunately there are some situations, where it is not possible to "clean" stop the process, where it needs to be "hard stopped".
â mstrd308
Nov 13 '17 at 13:32
 |Â
show 1 more comment
2
Are you settingSO_REUSEADDR
? Also don't usekill -9
, it does not let things clean up.
â thrig
Nov 10 '17 at 0:30
This is what @thrig mentioned in his comment above: docs.oracle.com/javase/7/docs/api/java/net/â¦
â Andy Dalton
Nov 10 '17 at 1:09
Is it complaining about port 37941? The line you quote doesnâÂÂt indicate that itâÂÂs open locally...
â Stephen Kitt
Nov 10 '17 at 5:45
@StephenKitt The problem is that the OS thinks there's still a process listening on this port. When the JVM is started again it fails, because the port is already "occupied", what means it cannot start listening on that port.The adress 172.21.63.27 is the adress of the host, where the JVM was running and the adress of the host where I tried to start the JVM again.
â mstrd308
Nov 13 '17 at 13:32
@thrig I don't know, it is configured as the JVM remote debug port, I don't know how the JVM handles this connections. Btw same thing happened with the JMX port of the JVM. And unfortunately there are some situations, where it is not possible to "clean" stop the process, where it needs to be "hard stopped".
â mstrd308
Nov 13 '17 at 13:32
2
2
Are you setting
SO_REUSEADDR
? Also don't use kill -9
, it does not let things clean up.â thrig
Nov 10 '17 at 0:30
Are you setting
SO_REUSEADDR
? Also don't use kill -9
, it does not let things clean up.â thrig
Nov 10 '17 at 0:30
This is what @thrig mentioned in his comment above: docs.oracle.com/javase/7/docs/api/java/net/â¦
â Andy Dalton
Nov 10 '17 at 1:09
This is what @thrig mentioned in his comment above: docs.oracle.com/javase/7/docs/api/java/net/â¦
â Andy Dalton
Nov 10 '17 at 1:09
Is it complaining about port 37941? The line you quote doesnâÂÂt indicate that itâÂÂs open locally...
â Stephen Kitt
Nov 10 '17 at 5:45
Is it complaining about port 37941? The line you quote doesnâÂÂt indicate that itâÂÂs open locally...
â Stephen Kitt
Nov 10 '17 at 5:45
@StephenKitt The problem is that the OS thinks there's still a process listening on this port. When the JVM is started again it fails, because the port is already "occupied", what means it cannot start listening on that port.The adress 172.21.63.27 is the adress of the host, where the JVM was running and the adress of the host where I tried to start the JVM again.
â mstrd308
Nov 13 '17 at 13:32
@StephenKitt The problem is that the OS thinks there's still a process listening on this port. When the JVM is started again it fails, because the port is already "occupied", what means it cannot start listening on that port.The adress 172.21.63.27 is the adress of the host, where the JVM was running and the adress of the host where I tried to start the JVM again.
â mstrd308
Nov 13 '17 at 13:32
@thrig I don't know, it is configured as the JVM remote debug port, I don't know how the JVM handles this connections. Btw same thing happened with the JMX port of the JVM. And unfortunately there are some situations, where it is not possible to "clean" stop the process, where it needs to be "hard stopped".
â mstrd308
Nov 13 '17 at 13:32
@thrig I don't know, it is configured as the JVM remote debug port, I don't know how the JVM handles this connections. Btw same thing happened with the JMX port of the JVM. And unfortunately there are some situations, where it is not possible to "clean" stop the process, where it needs to be "hard stopped".
â mstrd308
Nov 13 '17 at 13:32
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
-1
down vote
try some tool such ss or htop and try to kill 15 first , if no respond then kill 9 , and sometime application wont exit if it crash or zombied ,you need something like htop to kill all process/thread in the same time. hope this gona help u
add a comment |Â
up vote
-1
down vote
Try it to view which process (include PID) are using the port:
netstat -tupln |grep ":<Your_Port_Here>"
Then kill the PID (nearby process name) normally. Do not use kill command with any parameter.
kill <pid>
Note: Do not vote down if have never tried!
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
-1
down vote
try some tool such ss or htop and try to kill 15 first , if no respond then kill 9 , and sometime application wont exit if it crash or zombied ,you need something like htop to kill all process/thread in the same time. hope this gona help u
add a comment |Â
up vote
-1
down vote
try some tool such ss or htop and try to kill 15 first , if no respond then kill 9 , and sometime application wont exit if it crash or zombied ,you need something like htop to kill all process/thread in the same time. hope this gona help u
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
try some tool such ss or htop and try to kill 15 first , if no respond then kill 9 , and sometime application wont exit if it crash or zombied ,you need something like htop to kill all process/thread in the same time. hope this gona help u
try some tool such ss or htop and try to kill 15 first , if no respond then kill 9 , and sometime application wont exit if it crash or zombied ,you need something like htop to kill all process/thread in the same time. hope this gona help u
answered Nov 10 '17 at 1:32
Alceatraz
1
1
add a comment |Â
add a comment |Â
up vote
-1
down vote
Try it to view which process (include PID) are using the port:
netstat -tupln |grep ":<Your_Port_Here>"
Then kill the PID (nearby process name) normally. Do not use kill command with any parameter.
kill <pid>
Note: Do not vote down if have never tried!
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
add a comment |Â
up vote
-1
down vote
Try it to view which process (include PID) are using the port:
netstat -tupln |grep ":<Your_Port_Here>"
Then kill the PID (nearby process name) normally. Do not use kill command with any parameter.
kill <pid>
Note: Do not vote down if have never tried!
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
Try it to view which process (include PID) are using the port:
netstat -tupln |grep ":<Your_Port_Here>"
Then kill the PID (nearby process name) normally. Do not use kill command with any parameter.
kill <pid>
Note: Do not vote down if have never tried!
Try it to view which process (include PID) are using the port:
netstat -tupln |grep ":<Your_Port_Here>"
Then kill the PID (nearby process name) normally. Do not use kill command with any parameter.
kill <pid>
Note: Do not vote down if have never tried!
edited Nov 13 '17 at 7:32
answered Nov 10 '17 at 3:05
Tech. Pro
303
303
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
add a comment |Â
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
Netstat didn't show any port...
â mstrd308
Nov 13 '17 at 13:33
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
If the command has not show any port then your problem is not port conflict. After start your service or java app, let getback the root process id. When you want kill process (with child processes), use command: kill -9 -s <root_pid>
â Tech. Pro
Nov 13 '17 at 17:27
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403630%2fkilled-process-blocks-tcp-ports%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
Are you setting
SO_REUSEADDR
? Also don't usekill -9
, it does not let things clean up.â thrig
Nov 10 '17 at 0:30
This is what @thrig mentioned in his comment above: docs.oracle.com/javase/7/docs/api/java/net/â¦
â Andy Dalton
Nov 10 '17 at 1:09
Is it complaining about port 37941? The line you quote doesnâÂÂt indicate that itâÂÂs open locally...
â Stephen Kitt
Nov 10 '17 at 5:45
@StephenKitt The problem is that the OS thinks there's still a process listening on this port. When the JVM is started again it fails, because the port is already "occupied", what means it cannot start listening on that port.The adress 172.21.63.27 is the adress of the host, where the JVM was running and the adress of the host where I tried to start the JVM again.
â mstrd308
Nov 13 '17 at 13:32
@thrig I don't know, it is configured as the JVM remote debug port, I don't know how the JVM handles this connections. Btw same thing happened with the JMX port of the JVM. And unfortunately there are some situations, where it is not possible to "clean" stop the process, where it needs to be "hard stopped".
â mstrd308
Nov 13 '17 at 13:32