Kill a process that keeps restarting
What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.
I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>
.
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)
It's not a Zombie process.
$ ps -Al
4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python
I have even tried sudo pkill -f <processname>
with no luck. It doesn't want to die.
Update:
It's parent process is sh
whose parent is sudo
as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.
process kill
add a comment |
What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.
I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>
.
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)
It's not a Zombie process.
$ ps -Al
4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python
I have even tried sudo pkill -f <processname>
with no luck. It doesn't want to die.
Update:
It's parent process is sh
whose parent is sudo
as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.
process kill
Looks like it's dying just fine. Yourlsof
output shows a new pid every single time. The process is simply restarting.
– Patrick
Sep 29 '14 at 12:50
Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02
add a comment |
What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.
I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>
.
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)
It's not a Zombie process.
$ ps -Al
4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python
I have even tried sudo pkill -f <processname>
with no luck. It doesn't want to die.
Update:
It's parent process is sh
whose parent is sudo
as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.
process kill
What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.
I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>
.
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)
It's not a Zombie process.
$ ps -Al
4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python
I have even tried sudo pkill -f <processname>
with no luck. It doesn't want to die.
Update:
It's parent process is sh
whose parent is sudo
as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.
process kill
process kill
edited Apr 13 '17 at 12:36
Community♦
1
1
asked Sep 29 '14 at 12:40
Lakshminarayanan Guptha
68117
68117
Looks like it's dying just fine. Yourlsof
output shows a new pid every single time. The process is simply restarting.
– Patrick
Sep 29 '14 at 12:50
Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02
add a comment |
Looks like it's dying just fine. Yourlsof
output shows a new pid every single time. The process is simply restarting.
– Patrick
Sep 29 '14 at 12:50
Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02
Looks like it's dying just fine. Your
lsof
output shows a new pid every single time. The process is simply restarting.– Patrick
Sep 29 '14 at 12:50
Looks like it's dying just fine. Your
lsof
output shows a new pid every single time. The process is simply restarting.– Patrick
Sep 29 '14 at 12:50
Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02
Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02
add a comment |
2 Answers
2
active
oldest
votes
Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL
is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.
To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid()
combo). In this case, I find the output of ps faux
(from procps
at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).
Its parent issh
whose parent issudo
. Is it ok to kill them?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linuxprocps
, I usually find the output ofps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
– peterph
Sep 29 '14 at 13:13
Great.ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
ps faux
for the win, thanks!
– hoitomt
Aug 28 '17 at 17:25
|
show 1 more comment
If you know the listening port of the process, you can use fuser
with -k
flag.
Something like,
fuser -k 3002/tcp
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f158194%2fkill-a-process-that-keeps-restarting%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL
is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.
To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid()
combo). In this case, I find the output of ps faux
(from procps
at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).
Its parent issh
whose parent issudo
. Is it ok to kill them?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linuxprocps
, I usually find the output ofps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
– peterph
Sep 29 '14 at 13:13
Great.ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
ps faux
for the win, thanks!
– hoitomt
Aug 28 '17 at 17:25
|
show 1 more comment
Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL
is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.
To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid()
combo). In this case, I find the output of ps faux
(from procps
at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).
Its parent issh
whose parent issudo
. Is it ok to kill them?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linuxprocps
, I usually find the output ofps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
– peterph
Sep 29 '14 at 13:13
Great.ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
ps faux
for the win, thanks!
– hoitomt
Aug 28 '17 at 17:25
|
show 1 more comment
Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL
is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.
To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid()
combo). In this case, I find the output of ps faux
(from procps
at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).
Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL
is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.
To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid()
combo). In this case, I find the output of ps faux
(from procps
at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).
edited 9 hours ago
answered Sep 29 '14 at 13:02
peterph
23k24457
23k24457
Its parent issh
whose parent issudo
. Is it ok to kill them?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linuxprocps
, I usually find the output ofps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
– peterph
Sep 29 '14 at 13:13
Great.ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
ps faux
for the win, thanks!
– hoitomt
Aug 28 '17 at 17:25
|
show 1 more comment
Its parent issh
whose parent issudo
. Is it ok to kill them?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linuxprocps
, I usually find the output ofps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
– peterph
Sep 29 '14 at 13:13
Great.ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?
– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
ps faux
for the win, thanks!
– hoitomt
Aug 28 '17 at 17:25
Its parent is
sh
whose parent is sudo
. Is it ok to kill them?– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Its parent is
sh
whose parent is sudo
. Is it ok to kill them?– Lakshminarayanan Guptha
Sep 29 '14 at 13:09
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux
procps
, I usually find the output of ps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).– peterph
Sep 29 '14 at 13:13
Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux
procps
, I usually find the output of ps -faux
to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).– peterph
Sep 29 '14 at 13:13
Great.
ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Great.
ps -faux
helped to start killing from the parent. Can you please update your answer with the solution from the comment?– Lakshminarayanan Guptha
Sep 29 '14 at 13:25
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
Yes, I was thinking about it... :)
– peterph
Sep 29 '14 at 13:33
ps faux
for the win, thanks!– hoitomt
Aug 28 '17 at 17:25
ps faux
for the win, thanks!– hoitomt
Aug 28 '17 at 17:25
|
show 1 more comment
If you know the listening port of the process, you can use fuser
with -k
flag.
Something like,
fuser -k 3002/tcp
add a comment |
If you know the listening port of the process, you can use fuser
with -k
flag.
Something like,
fuser -k 3002/tcp
add a comment |
If you know the listening port of the process, you can use fuser
with -k
flag.
Something like,
fuser -k 3002/tcp
If you know the listening port of the process, you can use fuser
with -k
flag.
Something like,
fuser -k 3002/tcp
answered Sep 29 '14 at 13:20
Ramesh
23.2k32101181
23.2k32101181
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f158194%2fkill-a-process-that-keeps-restarting%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Looks like it's dying just fine. Your
lsof
output shows a new pid every single time. The process is simply restarting.– Patrick
Sep 29 '14 at 12:50
Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02