Linux -- Django test server running in background... somewhere

Question

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!

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.