Linux - Servidor de teste do Django rodando em segundo plano… em algum lugar

Question

Usando o Putty na minha máquina do Vista, eu entrei no meu servidor de desenvolvimento (Ubuntu) e liguei o servidor de teste do Django. Ele executa um servidor semelhante ao apache para testar meu aplicativo da web. O aplicativo é executado no meu endereço IP interno, na porta 8080. Posso abri-lo pelo navegador da Web e navegar até 192.168.0.130:8080 .

Deixei meu computador por um tempo (fisicamente) e voltei para descobrir que a conexão do Putty tinha expirado. Não biggy, acabei de entrar de volta no servidor. No entanto, quando tento executar o servidor de teste do Django agora, ele diz que a porta já está em uso. Isso significa (acho) que a primeira instância do servidor de teste ainda está em execução na porta 8080.

Como eu mato este processo? Como é o processo? Eu fiz um ps aux e tenho a sensação de que este é o processo ofensivo:

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

Desde que iniciei o servidor esta manhã mais ou menos naquela época e o Django é baseado em python. No entanto, fazer um kill 5719 não faz nada - o processo não é eliminado e ainda não consigo inicializar o servidor de teste.

Alguma idéia?

EDITAR - para mais detalhes:

Também corri netstat -tulpn e a saída é esta:

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      -

Não é conveniente, a porta que eu quero conhecer o ID do processo não tem um PID!

    

Answer 1

Se você está confiante de que este é o processo correto (o que parece provável) - e como o netstat não está dizendo nada de útil, então você pode usar

kill -9 5719 

O switch -9 envia um SIGKILL em vez do sinal SIGTERM padrão, que interromperá o processo se for interrompido.

O sinal SIGTERM é enviado para o processo e, efetivamente, solicita o desligamento. Um processo pode escolher pegar o SIGTERM e fazer algo totalmente diferente.

O sinal SIGKILL, por outro lado, não vai para o processo e, portanto, não pode ser ignorado. O kernel encerra o processo imediatamente e, portanto, deve ser usado apenas como último recurso, pois não fornece ao processo a oportunidade de limpar.

Se o processo for bloqueado por E / S, pode ser que ele não seja interrompido com o SIGKILL. Nesse caso, é um processo zumbi e uma reinicialização pode ser necessária para limpá-lo.

Elaboração: Um processo não pode ser eliminado se estiver aguardando a E / S, pois isso deixaria um retorno de chamada pendente para a função do kernel que faz o E / S.

Ou, se o pai do processo não chamar wait , o processo permanecerá como um processo zumbi. Um bom resumo dos processos mortos está localizado no link .

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.