Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Using Putty on my Vista machine, I logged into my development server (Ubuntu) and fired up the Django Test server. It runs an apache-like server to test my web app. The app runs on my internal IP address, on port 8080. I can open it via web browser, and navigating to 192.168.0.130:8080.

I left my computer for a while (physically) and returned to find the Putty connection had timed out. No biggy, I just logged back into the server. However, when I try to run the Django test server now, it says the port is already in use. That means (I think) that the first test server instance is still running on port 8080.

How do I kill this process? What does the process even look like? I did a ps aux and have a feeling that this is the offending process:

garfonzo    5719  0.3  0.0      0     0 ?        D    08:58   1:07 [python]

Since I started the server this morning at about that time and Django is python-based. However, doing a kill 5719 does nothing -- the process is not killed and I still cannot start up the test server.

Any ideas!?

EDIT -- for more details:

I also ran netstat -tulpn and the output is this:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.1.130:8080      0.0.0.0:*               LISTEN      -

Isn't that convenient, the one port I want to know the process ID of doesn't have a PID!

share|improve this question
    
You need to run netstat as root. –  Hello71 Jan 24 '12 at 21:50
    
I did -- the output above is the result of sudo netstat.... –  Garfonzo Jan 24 '12 at 21:56
add comment

1 Answer 1

If you are pretty confident that this is the correct process (which seems likely) - and as the netstat is not telling you anything useful, then you can use

kill -9 5719 

The -9 switch sends a SIGKILL rather than the default SIGTERM signal, which will stop the process if it is stoppable.

The SIGTERM signal is sent to the process, and effectively asks it to shutdown. A process can choose to catch SIGTERM and do something else entirely.

The SIGKILL signal on the other hand does not go to the process, and so cannot be ignored. The kernel terminates the process immediately and so should be used only as a last resort as it does not provide the process the opportunity to clean up.

If the process is I/O blocked then it might not be stoppable with SIGKILL, in which case it is a zombie process and a reboot may be required to clear it.

Elaboration: A process cannot be killed if it is waiting on I/O, as doing such would leave a dangling callback for the kernel function that does said I/O.

Or, if the parent of the process does not call wait, the process will stay as a zombie process. A good summary of dead processes is located at http://www.linuxsa.org.au/tips/zombies.html.

What are these zombie processes that show up in ps? I kill them but they don't go away!

Zombies are dead processes. You cannot kill the dead. All processes eventually die, and when they do they become zombies. They consume almost no resources, which is to be expected because they are dead! The reason for zombies is so the zombie's parent (process) can retrieve the zombie's exit status and resource usage statistics. The parent signals the operating system that it no longer needs the zombie by using one of the wait() system calls.

When a process dies, its child processes all become children of process number 1, which is the init process. Init is ``always'' waiting for children to die, so that they don't remain as zombies.

If you have zombie processes it means those zombies have not been waited for by their parent (look at PPID displayed by ps -l). You have three choices: Fix the parent process (make it wait); kill the parent; or live with it. Remember that living with it is not so hard because zombies take up little more than one extra line in the output of ps.

share|improve this answer
    
This answer is entirely misleading. –  Hello71 Jan 25 '12 at 3:11
    
@Hello71 Care to elaborate? –  Paul Jan 25 '12 at 3:30
    
What Paul said made sense to me. I'm not sure what part is misleading. I was apprehensive of sending a kill -9 to the 5719 process as I wasn't totally confident that it was the offending process. I ended up doing a reboot -- not ideal since I feel it is kind of like cheating, but alas I had to move on. Hopefully this doesn't happen on my other server that I don't have physical access to. –  Garfonzo Jan 25 '12 at 3:49
add comment

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.