Linux: servidor de prueba Django ejecutándose en segundo plano... en algún lugar

Linux: servidor de prueba Django ejecutándose en segundo plano... en algún lugar

Usando Putty en mi máquina Vista, inicié sesión en mi servidor de desarrollo (Ubuntu) y encendí el servidor de prueba Django. Ejecuta un servidor tipo Apache para probar mi aplicación web. La aplicación se ejecuta en mi dirección IP interna, en el puerto 8080. Puedo abrirla a través del navegador web y navegar a 192.168.0.130:8080.

Dejé mi computadora por un tiempo (físicamente) y regresé para encontrar que la conexión de Putty había expirado. No es gran cosa, acabo de volver a iniciar sesión en el servidor. Sin embargo, cuando intento ejecutar el servidor de prueba Django ahora, dice que el puerto ya está en uso. Eso significa (creo) que la primera instancia del servidor de prueba todavía se está ejecutando en el puerto 8080.

¿Cómo mato este proceso? ¿Cómo es el proceso? Hice un ps auxy tengo la sensación de que este es el proceso ofensivo:

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

Desde que inicié el servidor esta mañana aproximadamente a esa hora y Django está basado en Python. Sin embargo, hacer a kill 5719no hace nada: el proceso no finaliza y todavía no puedo iniciar el servidor de prueba.

¿¡Algunas ideas!?

EDITAR-- para más detalles:

También ejecuté netstat -tulpny el resultado es este:

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      -

¿No es tan conveniente? ¡El único puerto del que quiero saber el ID del proceso no tiene un PID!

Respuesta1

Si está bastante seguro de que este es el proceso correcto (lo que parece probable), y como netstat no le dice nada útil, puede usar

kill -9 5719 

El interruptor -9 envía una señal SIGKILL en lugar de la señal SIGTERM predeterminada, que detendrá el proceso si se puede detener.

La señal SIGTERM se envía al proceso y efectivamente le pide que se apague. Un proceso puede optar por capturar SIGTERM y hacer algo completamente distinto.

Por otro lado, la señal SIGKILL no va al proceso y, por lo tanto, no puede ignorarse. El kernel finaliza el proceso inmediatamente y, por lo tanto, debe usarse sólo como último recurso, ya que no brinda al proceso la oportunidad de limpiarse.

Si el proceso tiene E/S bloqueada, es posible que no se pueda detener con SIGKILL, en cuyo caso es un proceso zombie y es posible que sea necesario reiniciar para borrarlo.

Elaboración: No se puede finalizar un proceso si está esperando una E/S, ya que hacerlo dejaría una devolución de llamada pendiente para la función del núcleo que realiza dicha E/S.

O, si el padre del proceso no llama wait, el proceso permanecerá como un proceso zombie. Un buen resumen de los procesos muertos se encuentra enhttp://www.linuxsa.org.au/tips/zombies.html.

¿Cuáles son estos procesos zombies que aparecen en ps? ¡Los mato pero no se van!

Los zombis son procesos muertos. No puedes matar a los muertos. Todos los procesos finalmente mueren y, cuando lo hacen, se convierten en zombis. Casi no consumen recursos, lo cual es de esperarse porque ¡están muertos! La razón de los zombies es para que el padre (proceso) del zombie pueda recuperar el estado de salida del zombie y las estadísticas de uso de recursos. El padre le indica al sistema operativo que ya no necesita al zombie usando una de las llamadas al sistema wait().

Cuando un proceso muere, todos sus procesos secundarios se convierten en hijos del proceso número 1, que es el proceso inicial. Init "siempre" está esperando que los niños mueran, para que no sigan siendo zombies.

Si tiene procesos zombies, significa que sus padres no han esperado a esos zombies (mire el PPID que se muestra en ps -l). Tiene tres opciones: arreglar el proceso principal (hacerlo esperar); matar al padre; o vivir con ello. Recuerda que vivir con esto no es tan difícil porque los zombies ocupan poco más de una línea extra en la salida de ps.

información relacionada