Investiga los tipos de señales del comando KILL

Investiga los tipos de señales del comando KILL

1.     Ejecuta kill -l. E investiga el uso de las señales 9,15,18,19 y 20 de kill.

·         Para utilizar el comando kill en linux y matar algún proceso solo debes indicar en identificador de proceso, este puede ser llamado PID o Process ID, para conocer el PID de un programa o proceso puedes utilizar el comando ps para obtener una lista de los procesos que están en ejecución. Aquí te pongo un ejemplo:

·         $ ps

·         PID TTY TIME CMD

·         2541 pts/0 00:00:00 bash

·         2590 pts/0 00:00:00 ps

      Uso de las señales 9, 15, 18,19 y 20 kill.

      9) SIGKILL Kill (Forzar que el proceso termine)

      Destrucción inmediata del proceso. Tratamiento: exit. No reprogramable, no ignorable.

      15) SIGTERM Terminate (Terminar normalmente el proceso)

      Terminación. Tratamiento por defecto: exit. Reprogramable.

      18) SIGCONT Continue (Corre un proceso detenido)

      Continúa si estaba parado.Tratamiento por defecto: continuar. Reprogramable.

      19) SIGSTOP Stop (Detiene un proceso)

      Detiene el proceso. Se genera al pulsar "^z" durante la ejecución. No reprogramable, no ignorable.

      20) SIGTSTP Terminal (Pausa el proceso)

      Parada de terminal.

2.     Indica claramente la diferencia entre la 15 y la 9.

      9. SIGKILL: Esta señal provoca un apagado forzoso del proceso. A diferencia de las anteriores, no puede ser ignorada ni manejada por un controlador de señales. Es la manera más segura de matar un programa si no podemos hacerlo de las formas anteriores.

·         Los procesos zombies no se pueden matar, ya que están realmente muertos y a la espera de que su proceso padre los recoja.

·         Procesos que se encuentren bloqueados, no se matarán hasta que se levanten de nuevo.

·         El proceso init es especial: Ignora SIGKILL.

·         Como SIGKILL no permite que los procesos terminen de forma limpia, en muchos sistemas el procedimiento de apagado se produce utilizando SIGTERM antes que SIGKILL.

·         Un proceso dormido no interrumpible no puede terminar (ni liberar sus recursos) aunque reciba un SIGKILL. Esta es una de las situaciones en las que un sistema UNIX debe reiniciarse.

      15. SIGTERM: Señal que se envía el proceso para comunicarle un apagado “amable” (cerrando conexiones, ficheros y limpiando sus propios búfer). También puede ser controlada o ignorada por un manejador de señales del proceso. Es la señala que mandan por defecto: kill y killall desde la terminal.Es la señal por defecto.

3.     ¿Qué señal se lanza por defecto si no se especifica una?

·         La señal por defecto es SIGTERM

4. Pon un ejemplo claro de uso para las señales 9, 15, 18,19 y 20.

·         (9) SIGKILL: Esta señal termina el proceso que la recibe de forma inmediata. Empleela sólo para detener procesos que no terminan con la señal SIGTERM.

·         Usted observa que el proceso aún se está ejecutando. No ha finalizado. Para finalizar este proceso, y cualquier proceso que se resista a ser finalizado, debe enviar una nueva señal denominada SIGKILL. La señal por defecto es SIGTERM.

·         # kill -SIGKILL 9790

·         # ps -aef|grep sqlplus|grep oracle

      (15) SIGTERM: Esta señal solicita la terminación del proceso que la recibe.

      En ocasiones usted deseará terminar algún proceso, por ejemplo porque deja de responder o tarda demasiado en completarse; para hacerlo puede emplear el programa kill para enviarle una señal de terminación. Una señal es como un "llamado de atención" que se hace a un proceso en situaciones excepcionales (por ejemplo errores), pueden ser producidas por otros procesos, por el usuario o por el sistema operativo y en la mayoría de los casos conducen a la terminación del proceso que recibe la señal. Hay diversos tipos de señales, cada una tiene un número, un nombre que la identifica y una acción predefinida (que generalmente puede ser cambiada por el proceso). Un usuario puede enviar una señal a un proceso con el programa kill seguido de la señal que enviará y del proceso que la recibirá: kill -SIGTERM 945

      Este ejemplo envía la señal SIGTERM al proceso con identificación 945 (en vez de SIGTERM pudo haberse usado 15 que es el número que corresponde a esa señal).

Ø  (18) SIGCONT: Reanuda un proceso suspendido previamente por la señal SIGTSTP.

Ø  # Kill –SIGCONT 18 5981

o   (19) SIGSTOP: Para el proceso. Algunas veces usted puede querer simplemente detener el proceso en vez de finalizarlo. Puedo utilizar la opción -SIGSTOP con el comando kill.

o   # kill –SIGSTOP19  9790

o   # ps -aef|grep sqlplus|grep oracle

§  (20) SIGTSTP: La misma señal producida por Control-z, su efecto es suspender la ejecución de un proceso ---para reanudarla después.

§  # Kill –SIGTSP 20 5981

Práctica de redes. capa de transporte (TCP, UDP)--- 1 parte

1.-    Pregunta

Respuesta              

·         PRÁCTICA DE REDES.

·         CAPA DE TRANSPORTE (TCP, UDP) --- 1 parte

·         En esta práctica sobre la pila de protocolos TCP/IP nos vamos a ocupar de lo que se conoce como  capa de transporte. La capa de transporte se encarga, entre otras cosas, de empaquetar la información en paquetes de tamaño adecuado (limitarlo, por ejemplo, a las características de la red física, que podría no soportar paquetes de tamaños superiores a…), de verificar que todos los paquetes de una comunicación han llegado a destino (dependiendo del protocolo que usemos), de comprobar que los paquetes no estén corruptos…

·         Los dos protocolos principales de la capa de transporte son TCP (Transmission Control Protocol) y UDP (User Datagram Protocol). A lo largo de la práctica veremos algunas de sus características. También recuperaremos el protocolo DNS (Domain Name Server) y veremos la necesidad de contar con servidores DNS en nuestro ordenador para poder acceder a Internet, cómo se pueden configurar los servidores DNS y cómo funciona el protocolo.

·         Antes de empezar la práctica vamos a recuperar el programa para monitorizar el tráfico de red (http://www.wireshark.org/). Instálalo en tu ordenador. Ejecútalo, y dentro del menú “Capture”, en la opción “Interfaces”, elige la interfaz de red activa. Recupera y anota la IP de tu ordenador por medio del comando “ipconfig” (de las distintas interfaces de red que aparezcan debes seleccionar la correspondiente a “Adaptador de Ethernet – Conexión de área local”).

·         Ahora crea un filtro en Wireshark como el siguiente para conseguir aislar sólo el tráfico que tiene como origen o destino tu máquina: host ip-de-tu-maquina

PUEDES VER LA SINTÁXIS DE FORMACIÓN DE LOS FILTROS EN WIRESHARK EN

ESTE LINK. http://wiki.wireshark.org/CaptureFilters.

·         A lo largo de la práctica, a medida que Wireshark captura más paquetes, es probable que su comportamiento se ralentice. En ese caso puedes detenerlo (“Capture -> Stop”) y reiniciarlo (“Capture -> Interfaces -> Start ) (ten en cuenta que empezará una nueva sesión o captura cada vez que lo arranques y se perderán los paquetes ya capturados).

·         Pregunta 1

Abre pestañas independientes en tu navegador y accede a estas direcciones:

193.147.0.103

185.15.76.85

1.1  ¿Qué páginas se han abierto?

·         Portal todo FP inicio

·         http://www.iesgrancapitan.org/portal/

·         Filtra en Wireshark toda la actividad DNS que ha habido al abrir las páginas anteriores (escribe “dns” en la ventana “Filter:”). El protocolo DNS es el que permite, a partir de una dirección URL, resolver su IP para que las cabeceras de la capa de red se puedan formar correctamente.

1.2.- ¿Ha necesitado el ordenador conectarse a los servidores DNS para resolver las anteriores direcciones? ¿Se ha conectado antes o después de hacer las solicitudes HTTP?

      No a necesitado el ordenador conectarse a los servidores DNS para resolver las anteriores direcciones. No es necesario conectarse a los servidores, pues le estamos dando una dirección IP, y no necesita resolver el nombre porque ya una dirección IP.

      Se ha conectado antes de hacer las solicitudes HTTP porque no se conecta directamente HTTP sino que realiza una conversación. Por lo tanto, se a conectado primero con protocolo TCP donde ha iniciado la conexión entre el servidor y nosotros, para permitir el envio de datos en protocolo hipertexto.

      Pregunta 2

      Vamos ahora a ver cómo funciona la capa de transporte. Dentro de la misma podemos encontrar principalmente dos protocolos, TCP y UDP. Filtra en Wireshark la comunicación que ha tenido lugar entre tu ordenador y la página web en 74.125.159.105. Puedes crear un filtro como: host la_ip_de_tu_maquina and host 185.15.76.85. Observa la lista de paquetes que has recuperado.

2.1 ¿A qué protocolos pertenecen?

      74.125.159.105 me sale página caída.

      Protocolos TCP.

      Recupera el mensaje de protocolo HTTP cuya “info” sea exactamente “GET / HTTP/1.1” y ábrelo (botón derecho sobre el mismo, opción “Show Packet in New Window”). Observa las cabeceras TCP. Anota el valor de los puertos “Src” (puerto de tu máquina) y “Dst” (puerto del servidor). La comunicación entre máquinas siempre se hace a través de puertos de las mismas. Mientras dura una comunicación, cada máquina mantiene el mismo puerto escuchando y mandando mensajes. Algunos protocolos tienen un puerto asignado por defecto; por ejemplo, cuando te conectes a un servidor a través del protocolo http, lo normal es que el servidor utilice su puerto 80 para esa comunicación (¿es cierto en este caso?). Si te conectas por ftp, por defecto el servidor utilizará el puerto 21.

      Si es correcto.

2.2 Vamos a observar ahora la comunicación que ha habido a través del puerto de tu computadora.

En primer lugar, vamos a filtrar los paquetes de los que hemos sido origen (o src). Aplica el siguiente filtro: tcp.srcport eq puerto_de_tu_maquina

 ¿Cuál es la IP de origen de dichas comunicaciones? ¿Y la de destino? ¿Qué recursos web se han solicitado por HTTP a través de ese puerto?

      IP de origen: 193.147.0.103/

      IP de destino: 192.168.1.128

      Recursos web que se han solicitado por HTTP:Control de protocolo, puertos de destino y origen…

2.3 Veamos ahora los paquetes de los que hemos sido destinatarios (dst). Aplica el siguiente filtro: tcp.dstport eq puerto_de_tu_maquina

¿Cuál es la IP de origen de dichas comunicaciones? ¿Y la de destino? ¿Qué mensajes HTTP se han enviado a través de ese puerto?

      IP de origen: 193.147.0.103/

      IP de destino: 192.168.1.128

      Recursos web que se han solicitado por HTTP:Control de protocolo, puertos de destino y origen…

Aparte de la información sobre los puertos, las cabeceras TCP contienen información que nos va a permitir asegurar la correcta recepción de los paquetes. Copia los números “Sequence number” y  “Next Sequence Number” dentro de la cabecera TCP del mensaje “GET / HTTP/1.1”.  Ahora crea el siguiente filtro: tcp.ack eq next_sequence_number 

Responde a las preguntas:

¿Qué mensajes contienen el número next_sequence_number? ¿La respuesta del servidor “HTTP/1.1 200 OK” contiene el next_sequence_number?

 los mensajes de siguientes secuencias de numeros que se transmiten al enviar el mensaje

si contiene el next - sequence-number.

Pulsa el botón derecho sobre el mensaje cuya “info” es “HTTP/1.1 200 OK”, opción “Show Packet in New Window” y trata de comprobar, en la sección de cabeceras de “Reassembled TCP Segments”, qué paquetes han sido “reensamblados” para construir el mensaje de respuesta HTTP.

Anota sus números y comprueba si aparecen también entre los mensajes filtrados por la regla “tcp.ack eq next_sequence_number”.

HTTP/1.1 201

HTTP/1.1 202

HTTP/1.1 203

HTTP/1.1 204

Tratemos de dar una explicación al anterior hecho. Cuando tu ordenador hace una solicitud a un servidor, genera números “Sequence Number” y “Next Sequence Number”. Estos números son generados de forma aleatoria.

Cuando el servidor responda a tu mensaje, siempre incluirá un campo “Acknowledgment number” en el que enviará el número que nuestro ordenador le envió como “Next Sequence Number”. Así nuestro ordenador consigue distinguir las respuestas a las distintas solicitudes que le haya hecho a ese servidor.

De no existir los números “Sequence” y “Acknowledgment”, nos sería imposible distinguir las distintas comunicaciones con una misma máquina, y por tanto no podríamos reconstruir sus mensajes