“kill ” not really killing the process, why?
up vote
101
down vote
favorite
I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200
where 2200 is my PID and the process is not killed. After few minutes wait is still in the top
and ps aux
.
I have even tried typing it with sudo - no results.
Any ideas why it would be like that ?
EDIT
I have found a weird dependency, where fg
updates the processes list:
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps
command-line process
add a comment |
up vote
101
down vote
favorite
I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200
where 2200 is my PID and the process is not killed. After few minutes wait is still in the top
and ps aux
.
I have even tried typing it with sudo - no results.
Any ideas why it would be like that ?
EDIT
I have found a weird dependency, where fg
updates the processes list:
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps
command-line process
What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49
The process istop
(as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
– Patryk
Sep 3 '11 at 7:54
2
If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do afg
orbg
for the process)
– nos
Jun 10 '14 at 8:09
add a comment |
up vote
101
down vote
favorite
up vote
101
down vote
favorite
I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200
where 2200 is my PID and the process is not killed. After few minutes wait is still in the top
and ps aux
.
I have even tried typing it with sudo - no results.
Any ideas why it would be like that ?
EDIT
I have found a weird dependency, where fg
updates the processes list:
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps
command-line process
I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200
where 2200 is my PID and the process is not killed. After few minutes wait is still in the top
and ps aux
.
I have even tried typing it with sudo - no results.
Any ideas why it would be like that ?
EDIT
I have found a weird dependency, where fg
updates the processes list:
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top
x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps
command-line process
command-line process
edited Jun 6 '16 at 12:26
muru
134k19283483
134k19283483
asked Sep 3 '11 at 7:47
Patryk
4,361255996
4,361255996
What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49
The process istop
(as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
– Patryk
Sep 3 '11 at 7:54
2
If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do afg
orbg
for the process)
– nos
Jun 10 '14 at 8:09
add a comment |
What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49
The process istop
(as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
– Patryk
Sep 3 '11 at 7:54
2
If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do afg
orbg
for the process)
– nos
Jun 10 '14 at 8:09
What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49
What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49
The process is
top
(as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.– Patryk
Sep 3 '11 at 7:54
The process is
top
(as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.– Patryk
Sep 3 '11 at 7:54
2
2
If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a
fg
or bg
for the process)– nos
Jun 10 '14 at 8:09
If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a
fg
or bg
for the process)– nos
Jun 10 '14 at 8:09
add a comment |
6 Answers
6
active
oldest
votes
up vote
159
down vote
accepted
Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:
kill -9 {PID}
Learn more by reading the manual page:
man kill
18
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
15
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
3
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
You can also just usepkill process
, where process is the name of the process in stead of the process ID.
– RobinJ
Sep 6 '11 at 17:26
2
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
|
show 1 more comment
up vote
33
down vote
If kill
is invoked without any parameter, it sends the signal number 15 (SIGTERM
). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.
You can also "send" the signal number 9 (SIGKILL
) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.
One says kill -9 <pid>
always works. That's a misbelief. There are situations where even kill -9
does not kill the process. For example when a process has the state D
(uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.
2
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
add a comment |
up vote
7
down vote
Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:
kill - send a signal to a process
The default signal sent by kill [pid]
is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.
Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.
If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid]
.
add a comment |
up vote
2
down vote
It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.
1
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
add a comment |
up vote
0
down vote
From within C++, I executed:
kill(4024, SIGKILL);
And on a linux(Ubuntu) terminal,
$ ps -ax | grep my_su
The output was:
4024 pts/1 Z+ 0:00 [my_subscriber] <defunct>
Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!
add a comment |
up vote
0
down vote
You also may use kill -l
to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.
Note: as others may have mentioned, the use of kill -9 {PID}
is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.
add a comment |
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
159
down vote
accepted
Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:
kill -9 {PID}
Learn more by reading the manual page:
man kill
18
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
15
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
3
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
You can also just usepkill process
, where process is the name of the process in stead of the process ID.
– RobinJ
Sep 6 '11 at 17:26
2
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
|
show 1 more comment
up vote
159
down vote
accepted
Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:
kill -9 {PID}
Learn more by reading the manual page:
man kill
18
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
15
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
3
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
You can also just usepkill process
, where process is the name of the process in stead of the process ID.
– RobinJ
Sep 6 '11 at 17:26
2
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
|
show 1 more comment
up vote
159
down vote
accepted
up vote
159
down vote
accepted
Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:
kill -9 {PID}
Learn more by reading the manual page:
man kill
Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:
kill -9 {PID}
Learn more by reading the manual page:
man kill
edited Sep 3 '11 at 8:18
Lekensteyn
119k47262353
119k47262353
answered Sep 3 '11 at 8:09
Michał Šrajer
16.4k42528
16.4k42528
18
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
15
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
3
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
You can also just usepkill process
, where process is the name of the process in stead of the process ID.
– RobinJ
Sep 6 '11 at 17:26
2
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
|
show 1 more comment
18
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
15
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
3
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
You can also just usepkill process
, where process is the name of the process in stead of the process ID.
– RobinJ
Sep 6 '11 at 17:26
2
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
18
18
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
– Lie Ryan
Sep 3 '11 at 11:49
15
15
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
If that process steps out of line then it's KILL DASH NINE!
– scottl
Sep 5 '11 at 4:22
3
3
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
– user606723
Sep 6 '11 at 15:25
You can also just use
pkill process
, where process is the name of the process in stead of the process ID.– RobinJ
Sep 6 '11 at 17:26
You can also just use
pkill process
, where process is the name of the process in stead of the process ID.– RobinJ
Sep 6 '11 at 17:26
2
2
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
– rbaleksandar
Jul 17 '15 at 14:08
|
show 1 more comment
up vote
33
down vote
If kill
is invoked without any parameter, it sends the signal number 15 (SIGTERM
). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.
You can also "send" the signal number 9 (SIGKILL
) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.
One says kill -9 <pid>
always works. That's a misbelief. There are situations where even kill -9
does not kill the process. For example when a process has the state D
(uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.
2
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
add a comment |
up vote
33
down vote
If kill
is invoked without any parameter, it sends the signal number 15 (SIGTERM
). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.
You can also "send" the signal number 9 (SIGKILL
) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.
One says kill -9 <pid>
always works. That's a misbelief. There are situations where even kill -9
does not kill the process. For example when a process has the state D
(uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.
2
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
add a comment |
up vote
33
down vote
up vote
33
down vote
If kill
is invoked without any parameter, it sends the signal number 15 (SIGTERM
). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.
You can also "send" the signal number 9 (SIGKILL
) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.
One says kill -9 <pid>
always works. That's a misbelief. There are situations where even kill -9
does not kill the process. For example when a process has the state D
(uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.
If kill
is invoked without any parameter, it sends the signal number 15 (SIGTERM
). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.
You can also "send" the signal number 9 (SIGKILL
) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.
One says kill -9 <pid>
always works. That's a misbelief. There are situations where even kill -9
does not kill the process. For example when a process has the state D
(uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.
answered Jun 10 '14 at 6:22
chaos
18.9k85667
18.9k85667
2
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
add a comment |
2
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
2
2
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
– Sheljohn
Jul 6 '14 at 20:13
add a comment |
up vote
7
down vote
Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:
kill - send a signal to a process
The default signal sent by kill [pid]
is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.
Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.
If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid]
.
add a comment |
up vote
7
down vote
Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:
kill - send a signal to a process
The default signal sent by kill [pid]
is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.
Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.
If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid]
.
add a comment |
up vote
7
down vote
up vote
7
down vote
Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:
kill - send a signal to a process
The default signal sent by kill [pid]
is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.
Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.
If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid]
.
Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:
kill - send a signal to a process
The default signal sent by kill [pid]
is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.
Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.
If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid]
.
edited Sep 6 '11 at 17:35
answered Sep 6 '11 at 11:51
danne
422410
422410
add a comment |
add a comment |
up vote
2
down vote
It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.
1
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
add a comment |
up vote
2
down vote
It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.
1
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
add a comment |
up vote
2
down vote
up vote
2
down vote
It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.
It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.
answered Sep 6 '11 at 15:00
user24497
211
211
1
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
add a comment |
1
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
1
1
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
So how to find attached terminal?
– ruX
Mar 21 '13 at 16:58
add a comment |
up vote
0
down vote
From within C++, I executed:
kill(4024, SIGKILL);
And on a linux(Ubuntu) terminal,
$ ps -ax | grep my_su
The output was:
4024 pts/1 Z+ 0:00 [my_subscriber] <defunct>
Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!
add a comment |
up vote
0
down vote
From within C++, I executed:
kill(4024, SIGKILL);
And on a linux(Ubuntu) terminal,
$ ps -ax | grep my_su
The output was:
4024 pts/1 Z+ 0:00 [my_subscriber] <defunct>
Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!
add a comment |
up vote
0
down vote
up vote
0
down vote
From within C++, I executed:
kill(4024, SIGKILL);
And on a linux(Ubuntu) terminal,
$ ps -ax | grep my_su
The output was:
4024 pts/1 Z+ 0:00 [my_subscriber] <defunct>
Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!
From within C++, I executed:
kill(4024, SIGKILL);
And on a linux(Ubuntu) terminal,
$ ps -ax | grep my_su
The output was:
4024 pts/1 Z+ 0:00 [my_subscriber] <defunct>
Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!
answered Mar 10 '16 at 23:51
Park JongBum
1163
1163
add a comment |
add a comment |
up vote
0
down vote
You also may use kill -l
to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.
Note: as others may have mentioned, the use of kill -9 {PID}
is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.
add a comment |
up vote
0
down vote
You also may use kill -l
to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.
Note: as others may have mentioned, the use of kill -9 {PID}
is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.
add a comment |
up vote
0
down vote
up vote
0
down vote
You also may use kill -l
to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.
Note: as others may have mentioned, the use of kill -9 {PID}
is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.
You also may use kill -l
to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.
Note: as others may have mentioned, the use of kill -9 {PID}
is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.
edited Nov 19 at 10:52
answered Nov 19 at 10:47
amrx
1,135915
1,135915
add a comment |
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f59811%2fkill-pid-not-really-killing-the-process-why%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
What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49
The process is
top
(as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.– Patryk
Sep 3 '11 at 7:54
2
If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a
fg
orbg
for the process)– nos
Jun 10 '14 at 8:09