Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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
share|improve this question
    
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
    
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 at 8:09

4 Answers 4

up vote 37 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
share|improve this answer
7  
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
6  
If that process steps out of line then it's KILL DASH NINE! –  scottl Sep 5 '11 at 4:22
1  
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
    
Thank you so much ! –  user01 Mar 10 at 15:13

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.

share|improve this answer
    
So how to find attached terminal? –  ruX Mar 21 '13 at 16:58

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].

share|improve this answer

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.

share|improve this answer
    
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? –  Sh3ljohn Jul 6 at 20:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.