9 managing processes

178 visualizaciones

Publicado el

RHA030-6.1

Publicado en: Educación
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

9 managing processes

  1. 1. 1 Managing Processes Capítulo 1 Introducción a Procesos Conceptos clave • • • • • • • • Un proceso es una instancia de un ejecutable en ejecución identificado por un id de proceso (pid). Debido a que Linux implementa memoria virtual cada proceso posee su propio contexto distintivo de memoria. Un proceso tiene un uid y una colección de gid como credenciales. Un proceso tiene un contexto de sistema de archivos incluyendo un cwd, una umask, un directorio raíz y una colección de archivos abiertos. Un proceso tiene un contexto de programación que incluye un valor de niceness. Un proceso tiene una colección de variables de entorno. El comando ps puede utilizarse para examinar todos los procesos actuales en ejecución. El comando top puede utilizarse para controlar todos los procesos en ejecución. Los procesos tienen que ver con el cómo se hacen las cosas Casi cualquier cosa que suceda en un sistema Linux tiene lugar como un proceso. Si usted está viendo este texto en un navegador, ese navegador se está ejecutando como un proceso. Si está tecleando en una línea de comandos de la shell bash, esa shell está ejecutando como un proceso. Si está utilizando el comando chmod para cambiar un permiso de un archivo, el comando chmod funciona como un proceso por separado. Los procesos tienen que ver con el cómo se consigue hacer las cosas y la responsabilidad principal del kernel de Linux es proporcionar un lugar para que los procesos ejerzan su labor sin necesidad de tocar el campo del otro. Los procesos son una instancia de un programa en funcionamiento. En otros sistemas operativos los programas suelen ser grandes y elaboradas aplicaciones gráficas que se toman una gran cantidad de tiempo para iniciar. En el mundo de Linux (y Unix), estos tipos de programas también existen, al igual que toda una clase de programas que usualmente no tienen una contraparte en los sistemas operativos. Estos programas están diseñados para iniciar rápidamente, especializados en funciones y trabajan bien con otros programas. En un sistema de Linux, los procesos que ejecutan estos programas están constantemente apareciendo y desapareciendo. Por ejemplo, considere que el usuario maxwell escribe la siguiente línea de comandos. [maxwell@station maxwell]$ ps aux | grep httpd > daemons.$(date +%d%b%y) En una fracción de segundo que la línea de comandos utilizó para ejecutar, no menos de cuatro procesos (ps, grep, bash y date) se iniciaron, hicieron lo que tenían que hacer y salieron. ¿Qué es un proceso?
  2. 2. 2 Managing Processes En este momento ya estará cansado de escuchar la misma pregunta: un proceso en una instancia de un programa en ejecución. No obstante, aquí ofrecemos una lista detallada de componentes que constituyen un proceso. Contexto de ejecución Cada proceso existe (al menos hasta cierto punto) dentro de una memoria física de la máquina. Puesto que Linux (y Unix) están diseñados para ser un entorno multiusuario, la memoria asignada a un proceso está protegida y ningún otro proceso puede acceder a ésta. Un proceso carga en su memoria una copia de las instrucciones ejecutables y almacena cualquier otra información dinámica que esté manejando. Un proceso también lleva parámetros asociados con la frecuencia de acceso que se tiene a la CPU, tales como su estado de ejecución y su valor de niceness (pronto hablaremos más en detalle sobre esto). Contexto de E/S Cada proceso interactúa hasta cierto punto con el sistema de archivos para leer y escribir información que existe o existirá después del ciclo de vida del proceso. Los elementos de entrada y salida (E/S) de un proceso incluyen lo siguiente: Descriptores de archivo abierto Casi todos los procesos suelen leer información de o escribir información a fuentes externas. En Linux, los descriptores de archivos abiertos actúan como fuentes o receptores de información. Los procesos leen información de o escriben información a los descriptores de archivos abiertos que pueden estar conectados a archivos regulares, nodos de dispositivos, conexiones de red o incluso entre sí como tuberías (permitiendo la comunicación entre procesos). Archivos de trazado de memoria Los archivos de trazado de memoria son los archivos cuyo contenido se ha trazado directamente en la memoria del proceso. En lugar de leer o escribir en un descriptor de archivo, el proceso sólo accede a la dirección de memoria apropiada. Los mapas de memoria suelen utilizarse para cargar el código ejecutable, pero también sirven para otros tipos de acceso no secuencial a los datos. Contexto del sistema de archivos Hemos encontrado varias partes de información relacionadas con el sistema de archivos que mantiene los procesos, tales como el directorio de trabajo actual del proceso (para traducir referencias de archivos) y la umask del proceso (para establecer permisos en archivos recién creados). [1] Variables de entorno
  3. 3. 3 Managing Processes Cada proceso mantiene su propia lista de pares nombre-valor, conocida como variables de entorno o en general como el entorno del proceso. Los procesos por lo general heredan su entorno en el inicio y pueden referirse a éste para obtener datos tales como el lenguaje preferido o el editor favorito del usuario. Información de herencia Cada proceso se identifica con un PID o id del proceso asignado en el momento de su creación. En una próxima lección, veremos que cada proceso tiene claramente definido un padre y posiblemente unos hijos también. La identidad del propio proceso, la identidad de sus hijos y hasta cierto punto la identidad de sus hermanos son mantenidos por el proceso. Credenciales Cada proceso se ejecuta bajo el contexto de un determinado usuario (o más exactamente de un id de usuario determinado) y bajo el contexto de una colección de id de grupo (generalmente, todos los grupos a los que pertenezca el usuario). Estas credenciales limitan los recursos a los que el proceso puede acceder tales como qué archivos pueden abrir o con qué otros procesos se les permite comunicarse. Estadísticas de recursos y límites Cada proceso también registra estadísticas para trazar la cantidad de recursos del sistema utilizados, el número de archivos abiertos, la cantidad de tiempo de CPU, etc. La cantidad de recursos que se le permite utilizar a un proceso también puede limitarse con un concepto llamado límite de recursos. Ver procesos con el comando ps Ya hemos visto varias veces el comando ps. Ahora, trataremos de familiarizarnos con una selección más amplia de opciones asociadas a éste. Una ejecución rápida de ps -help mostrará un resumen de más de 50 opciones diferentes para personalizar la conducta del comando ps. las cosas se complican un poco porque diferentes versiones de Linux han desarrollado sus propias versiones del comando ps, las cuales no utilizan las mismas convenciones para las opciones. La versión de Linux del comando ps trata de acomodarse a diferentes versiones anteriores de Unix y suele haber opciones múltiples para cualquier opción determinada, algunas de las cuales comienzan con un guión inicial (“-”). Selección de procesos De forma predeterminada, el comando ps lista todos los procesos iniciados desde una terminal de usuario. Aunque esta conducta es razonable, cuando los usuarios están conectados a cajas de UNIX con terminales seriales de línea, parece un poco simplista cuando cada ventana de una terminal dentro de un entorno gráfico X se trata como una
  4. 4. 4 Managing Processes terminal independiente. Los siguientes modificadores de línea de comandos pueden utilizarse para expandir (o reducir) los procesos listados por el comando ps . Table 1. Opciones comunes del comando ps para la selección de procesos Opción -A, -e, ax Procesos listados Todos los procesos. -C command Todas las instancias de command -U, --user, --User user Todos los procesos que pertenecen a user -t, --tty terminal Todos los procesos iniciados desde terminal -p, p, --pid N Procesos con pid N Selección de salida Como se deduce de los párrafos iniciales de esta lección hay muchos parámetros asociados con procesos, demasiados para mostrar en una anchura estándar de terminal de 80 columnas. El siguiente cuadro lista las opciones de línea de comando comunes que se utilizan para seleccionar qué aspectos de un proceso se listan. Table 1. Opciones comunes del comando ps para la selección de salida Opción Formato de la salida -f listado "completo" -l, l formato largo -j, j formato de trabajos formato definido del usuario utilizando campos especificados por str -o, o, -(campos disponibles para str se pueden listar con ps L o consultando la formato str página de manual ps(1)). Además, las siguientes opciones pueden utilizarse para modificar la forma de presentar la información. Table 2. Opciones comunes del comando ps para dar formato a la salida Opción Formato de la salida -H Muestra la jerarquía del proceso f, --forest Muestra la jerarquía de proceso incluyendo las representaciones ASCII h No imprime las líneas del encabezado -w salida "ancha" (incluye nombres de los comandos más largos)
  5. 5. 5 Managing Processes Rarezas del comando ps El comando ps, posiblemente más que cualquier otro comando en Linux, tiene sus rarezas asociadas con sus opciones. En la práctica, los usuarios tienden a experimentar hasta encontrar combinaciones que les funcionen y luego se habitúan a ellas. Por ejemplo, el autor prefiere el comando ps aux para propósitos generales de todos los procesos, mientras que otros preferirían el comando ps -ef. El cuadro anterior ofrece una "ayuda de trabajo" bastante buena para el principiante. Las opciones de línea de comandos tienden a clasificarse en dos categorías, aquellas con el tradicional guión inicial (opciones de estilo "Unix98") y otras sin (opciones de estilo "BSD"). A menudo, una funcionalidad determinada se representa por una de cada una de ellas. Al agrupar opciones de una sola letra, sólo pueden agruparse opciones del mismo estilo. Por ejemplo, ps axf es lo mismo que ps a x f, pero diferente de ps a x -f. Control de procesos con el comando top El comando ps muestra estadísticas para procesos especificados en el momento que se ejecuta el comando, proporcionando una instantánea de una instancia en tiempo. En contraste, el comando top sirve para controlar el estado general de los asuntos de procesos en la máquina. Se espera que el comando top se ejecute desde dentro de una terminal. Éste remplazará la línea de comandos por una tabla de los actuales procesos en ejecución, el cual se actualiza a cada instante. A continuación se muestra la pantalla de un usuario después de ejecutar el comando top. 17:46:38 up 4:28, 7 users, load average: 0.07, 0.02, 0.00 101 processes: 100 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.4% user 1.0% system 0.0% nice 0.0% iowait idle Mem: 255232k av, 232796k used, 22436k free, 0k shrd, 32404k buff 146208k actv, 33884k in_d, 4716k in_c Swap: 522104k av, 88368k used, 433736k free 104280k cached PID USER PRI COMMAND 1150 einstein 15 metacity 1186 einstein 15 battstat-appl 3057 einstein 15 galeon-bin 3622 maxwell 22 1 root 15 2 root 15 keventd 3 root 15 kapmd NI SIZE RSS SHARE STAT %CPU %MEM 95.4% TIME CPU 0 4468 4108 2252 S 2.9 1.6 0:51 0 0 3132 2112 1436 S 0.9 0.8 0:04 0 18M 12356 S 0.9 7.5 0:06 0 856 R 52 S 0 SW 0.9 0.0 0.0 0.4 0.0 0.0 0:00 0:04 0:00 0 top 0 init 0 0 SW 0.0 0.0 0:00 0 0 19596 0 0 0 0 1088 1088 108 76 0 0 0 0
  6. 6. 6 Managing Processes 4 root ksoftirqd_CPU 9 root bdflush 5 root kswapd 6 root kscand/DMA 7 root kscand/Normal 8 root kscand/HighMe 10 root kupdated 11 root mdrecoveryd 15 root kjournald 34 19 0 0 0 SWN 0.0 0.0 0:00 0 25 0 0 0 0 SW 0.0 0.0 0:00 0 15 0 0 0 0 SW 0.0 0.0 0:00 0 15 0 0 0 0 SW 0.0 0.0 0:00 0 15 0 0 0 0 SW 0.0 0.0 0:06 0 15 0 0 0 0 SW 0.0 0.0 0:00 0 15 0 0 0 0 SW 0.0 0.0 0:00 0 25 0 0 0 0 SW 0.0 0.0 0:00 0 15 0 0 0 0 SW 0.0 0.0 0:01 0 Mientras el comando está ejecutándose, el teclado está "vivo". En otras palabras, el comando top responderá a pulsaciones sin esperar a la tecla enter. El siguiente cuadro lista algunas de las teclas más utilizadas. Table 1. Comandos top más utilizados Comando Presionar tecla q quit ho? ayuda s establecer el retraso entre las actualizaciones (en segundos) space mostrar actualización M Clasificar procesos por tamaño de memoria P Clasificar procesos por actividad de la CPU (procesador) u Reducir procesos visualizados pertenecientes a un usuario específico k Matar un proceso (enviar una señal a un proceso) r renice un proceso Los últimos dos comandos, los cuales pueden matar o renice un proceso utilizan conceptos que cubriremos con más detalle en una próxima lección. Aunque por lo general top funciona sin la configuración de línea de comandos es compatible con las siguientes opciones: Table 2. Opciones para el comando top Opción -d Efecto Demora segundos segundos entre actualizaciones (por defecto = 5
  7. 7. 7 Managing Processes Opción Efecto segundos segundos). -q Actualiza tan pronto como sea posible. -n N Se ejecuta para iteraciones N, luego sale. -b Se ejecuta en "modo por lote" simplemente como si escribiera a una terminal tonta. Procesos de control con la aplicación gnome-system-monitor Si se ejecuta un servidor X, el entorno de escritorio de GNOME proporciona una aplicación similar en función a top con los beneficios (y problemas) de una aplicación gráfica. La aplicación se puede iniciar desde una línea de comandos como gnomesystem-monitor o desde el menú de aplicaciones predeterminado, seleccionando Herramientas: monitor del sistema. Figure 1. Monitor del sistema GNOME Al igual que el comando top, la aplicación Monitor del sistema presenta una lista de procesos ejecutándose en la máquina local, actualizando la lista cada pocos segundos. En su configuración por defecto, la aplicación Monitor del sistema provee una interfaz mucho más simple: lista sólo los procesos pertenecientes al usuario que inició la aplicación y reduce el número de columnas a la memoria del comando del proceso, el propietario, ID de proceso, las medidas simples de la memoria del proceso y la utilización de la CPU. Los procesos pueden clasificarse por cualquiera de estos campos con un sólo clic en el título de la columna. En la esquina superior derecha de la ventana, un menú emergente permite al usuario escoger entre desplegar todos los procesos pertenecientes al usuario (por defecto) o sólo los procesos en el estado de "ejecución". Cuando se hace click derecho en un proceso, un menú emergente permite al usuario realizar muchas de las acciones que top le permitió, tales como reniciar o matar un proceso a través de una interfaz más sencilla (y no tan flexible). Figure 2. Haciendo click derecho en un proceso en el Monitor del sistema GNOME El Monitor del Sistema puede configurarse abriendo el menú de selecciónEditor:Preferencias. Dentro del diálogo de Preferencias, el usuario puede establecer el intervalo de actualización (en segundos) y configurar muchos más campos para ser visualizados. Figure 3. Campos de configuración en el monitor de sistema GNOME
  8. 8. 8 Managing Processes Por último, el Monitor de Sistema provee un segundo panel, el cual muestra gráficas de todo el uso de la CPU y de la memoria versus tiempo y un cuadro de uso del disco (esencialmente la salida del comando df). Figure 4. Panel del monitor de sistema GNOME Localización de procesos con el comando pgrep. A menudo, los usuarios tratan de localizar información acerca de procesos identificados por el comando que están ejecutando o el usuario que está ejecutándolos. Una técnica es listar todos los procesos y utilizar el comando grep para reducir la información. A continuación, maxwell primero busca todas las instancias del demonio sshd y luego busca los procesos pertenecientes al usuario maxwell. [maxwell@station maxwell]$ ps aux | grep sshd root 829 0.0 0.0 3436 4 ? S /usr/sbin/sshd maxwell 2200 0.0 0.2 3572 640 pts/8 S sshd [maxwell@station maxwell]$ ps aux | grep maxwell root 2109 0.0 0.3 4108 876 pts/8 S maxwell maxwell 2112 0.0 0.4 4312 1268 pts/8 S maxwell 2146 1.4 8.3 89256 21232 pts/8 S /usr/lib/mozillamaxwell 2201 0.0 0.2 2676 724 pts/8 R maxwell 2202 0.0 0.2 3576 644 pts/8 S maxwell 09:13 0:00 10:10 0:00 grep 10:05 0:00 su - 10:05 10:05 0:00 -bash 0:04 10:10 10:10 0:00 ps aux 0:00 grep Aunque maxwell puede encontrar la información que necesita hay algunos aspectos no muy agradables. 1. El método no es exacto. Observe que, en la segunda búsqueda, apareció un proceso su no porque le perteneciera a maxwell, sino porque la palabra maxwell era uno se sus argumentos. 2. Igualmente, el comando grep suele aparecerse en la salida. 3. El comando compuesto puede ser complicado de teclear. El comando pgrep fue creado para tratar estos problemas. pgrep permite a los usuarios listar rápidamente procesos por nombre de comando, usuario, terminal o grupo. pgrep [OPCIONES] [PATRÓN] Su argumento opcional, si se suministra, se interpreta como un patrón de expresión regular extendido coincidente con nombres de comando. Las siguientes opciones también pueden utilizarse para clasificar la búsqueda.
  9. 9. 9 Managing Processes Table 1. Opciones comunes para especificar el criterio de selección del proceso pgrep. Opción Efecto -n Selecciona únicamente los procesos coincidentes iniciados más recientemente. -u USER Selecciona procesos pertenecientes al usuario USER. -t TERM Selecciona procesos controlados por terminal TERM. Además, la siguiente opción puede utilizarse para modificar el formato de la salida del comando. Table 2. Opciones comunes para especificar el formato de salida pgrep Opción Efecto delimitador Usa delimitador para delimitar cada ID de proceso (por defecto se utiliza una nueva línea). -l Lista el nombre del proceso y el ID del proceso. -d Para una lista completa de opciones consulte la página de manual pgrep(1). A manera de ejemplo, maxwell repetirá dos listados del proceso anterior mediante el comando pgrep. [1] [maxwell@station maxwell]$ pgrep -l sshd 829 sshd [maxwell@station maxwell]$ pgrep -lu maxwell 2112 bash 2146 mozilla-bin 2155 mozilla-bin 2156 mozilla-bin 2157 mozilla-bin Ejemplos Ver todos los procesos con el formato de "usuario orientado" En la siguiente transcripción, maxwell utiliza el comando ps -e u para listar todos los procesos (-e) con el formato de "usuario orientado" (u). [maxwell@station maxwell]$ ps -e u USER PID %CPU %MEM VSZ RSS root 1 0.0 0.0 1380 76 root 2 0.0 0.0 0 0 [keventd] root 3 0.0 0.0 0 0 ... TTY ? ? STAT START S Oct12 SW Oct12 TIME COMMAND 0:04 init [ 0:00 ? SW 0:00 [kapmd] Oct12
  10. 10. 10 Managing Processes root 174 0.0 [kjournald] root 250 0.0 /sbin/mingetty tt root 496 0.0 /sbin/dhclient -1 root 566 0.0 -m 0 root 570 0.0 x rpc 588 0.0 ... maxwell 4202 0.0 nautilus --no-def maxwell 4204 0.0 magicdev --sm-cli maxwell 4207 0.0 --sm-clie maxwell 4210 0.0 panel-icon -maxwell 4212 0.1 /usr/bin/python / root 4213 0.0 /sbin/pam_timesta maxwell 4220 0.0 /usr/libexec/noti maxwell 4293 2.4 system-moni apache 5048 0.0 /usr/sbin/httpd ... maxwell 13166 0.7 maxwell 13200 0.0 0.0 0 0 ? SW Oct12 0:00 0.0 1356 4 tty2 S Oct12 0:00 0.1 2104 448 ? S Oct12 0:00 0.0 1448 160 ? S Oct12 0:00 syslogd 0.0 1376 164 ? S Oct12 0:00 klogd - 0.0 1548 104 ? S Oct12 0:00 portmap 1.3 57948 3400 ? S Oct12 0:02 0.1 16392 436 ? S Oct12 0:00 0.5 16784 1500 ? S Oct12 0:00 eggcups 0.3 11596 988 ? S Oct12 0:00 pam- 0.8 24464 2152 ? S Oct12 0:41 0.0 136 ? S Oct12 0:00 0.3 17024 1012 ? S Oct12 0:00 1.4 18356 3760 ? S Oct12 0.6 18424 1776 ? S Oct12 0:00 0.5 0.2 S R 07:35 07:35 0:00 -bash 0:00 ps -e u 1416 4304 1392 pts/5 2696 744 pts/5 15:28 gnome- El "usuario orientado"muestra el usuario que está ejecutando el proceso, el id de proceso y una estimación aproximada de la cantidad de CPU y memoria que el proceso está consumiendo como también el estado del proceso. (los estados de procesos se tratarán en una próxima lección). Ver los procesos de un usuario con el formato "largo" En la siguiente transcripción, maxwell utiliza el comando ps -U maxwell l para listar todos sus procesos (-U maxwell) con el formato "largo " (l). [maxwell@station maxwell]$ ps -U maxwell l F UID PID PPID PRI NI VSZ RSS WCHAN COMMAND 4 515 4132 1062 15 0 18632 4 schedu /usr/bin/gnom 1 515 4175 4132 15 0 3068 72 schedu /usr/bin/ssh0 515 4180 1 15 0 11384 776 schedu /usr/libexec/ 0 515 4182 1 15 0 6364 4 schedu /usr/libexec/ STAT TTY TIME S ? 0:02 S ? 0:00 S ? 0:00 S ? 0:00
  11. 11. 11 Managing Processes 0 515 4184 1 gnome-setting 0 515 4193 1 xscreensaver 0 515 4196 1 /usr/bin/meta 0 515 4200 1 gnome-panel 0 515 4202 1 nautilus --no 0 515 4204 1 magicdev --sm 0 515 4207 1 eggcups --sm0 515 4210 1 pam-panel-ico 0 515 4212 1 /usr/bin/pyth 0 0 4213 4210 /sbin/pam_tim 0 515 4220 1 /usr/libexec/ 0 515 4293 1 gnome-system4 515 13166 13163 bash 0 515 13201 4193 pulsar -root 0 515 13265 13166 -U maxwell 15 0 17336 4 schedu S ? 0:00 15 0 620 schedu S ? 0:00 15 0 12816 1884 schedu S ? 0:08 15 0 21160 3340 schedu S ? 0:05 15 0 57948 3192 schedu S ? 0:02 15 0 16392 424 schedu S ? 0:00 15 0 16784 1348 schedu S ? 0:00 15 0 11596 908 schedu S ? 0:00 15 0 24464 2152 schedu S ? 0:43 15 0 1416 136 schedu S ? 0:00 15 0 17024 756 schedu S ? 0:00 15 0 18356 3760 schedu S ? 15:43 15 0 pts/5 0:00 - 25 10 6676 2592 schedu SN ? 0:00 20 0 3140 1188 - pts/5 0:00 ps 3728 4304 1388 wait4 S R El formato largo se enfoca en parámetros de programación, tales como la prioridad y el niceness del proceso, los cuales se tratarán más adelante. Ver un comando determinado con el formato "trabajo orientado" En la siguiente transcripción, maxwell utiliza el comando ps -C bash j para listar todas las instancias del comando bash (-C bash) con el formato de "trabajo orientado" (j). [maxwell@station maxwell]$ ps -C bash j PPID PID PGID SID TTY TPGID STAT 1184 2311 2311 2311 pts/4 2311 S 1184 2565 2565 2565 pts/0 2565 S 1184 2757 2757 2757 pts/2 2757 S 1184 3024 3024 3024 pts/3 3052 S 1184 3348 3348 3348 pts/6 3348 S 1184 6033 6033 6033 pts/5 13414 S 1184 6534 6534 6534 pts/8 6534 S 13163 13166 13166 6033 pts/5 13414 S UID 2291 2291 2291 2291 2291 2291 2291 515 TIME 0:01 0:04 0:00 0:00 0:00 0:00 0:00 0:00 COMMAND bash bash bash bash bash bash bash -bash El formato de trabajo orientado se enfoca en los procesos padre, grupos de proceso, grupos de sesión y terminales de control. Muchos de estos conceptos se discutirán más tarde en otros cuadernos.
  12. 12. 12 Managing Processes Intrigado porque el proceso padre de muchas de estas shells parece ser el proceso ID 1184, maxwell continúa examinando ese proceso individual. [maxwell@station maxwell]$ ps u 1184 USER PID %CPU %MEM VSZ RSS TTY einstein 1184 0.2 3.3 26900 8660 ? /usr/bin/gnome-te STAT START S Oct12 TIME COMMAND 2:51 Aparentemente, todas las shells bash se iniciaron desde dentro de una gnome-terminal. Ver procesos con el formato personalizado Intrigado por ver los aspectos que un proceso puede visualizar con el comando ps, maxwell utiliza ps L para listar los posibles encabezados. [maxwell@station maxwell]$ ps L %cpu %CPU %mem %MEM alarm ALARM args COMMAND blocked BLOCKED bsdstart START bsdtime TIME c C ... vsize VSZ vsz VSZ wchan WCHAN Intrigado por el campo alarm, maxwell desea ver los procesos que tienen alarmas pendientes. Utiliza la opción -o para listar todas las alarmas pendientes y comandos. [maxwell@station maxwell]$ ps -e -o alarm,cmd ALARM CMD - init [ - [keventd] - [kapmd] ... 30.00 syslogd -m 0 ... Observando que todas las entradas "interesantes" comienzan con números, maxwell utiliza el comando grep para reducir su salida a líneas que comienzan con cualquier número o espacio pero cuyo primer caracter de no espacio sea un dígito. [maxwell@station maxwell]$ ps -e -o alarm,cmd | grep "^ *[0-9]" 30.00 syslogd -m 0 15.00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc 3600 /usr/sbin/sshd 3600 sendmail: accepting connections 3600 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue 300 /usr/bin/gdm-binary -nodaemon 10.00 /usr/bin/ssh-agent /etc/X11/xinit/Xclients
  13. 13. 13 Managing Processes 10.00 /usr/bin/ssh-agent /etc/X11/xinit/Xclients Estas son las utilidades que piden ser notificadas cada 15 minutos, cada hora, etc., presumiblemente para sondear alguna actividad. Ejercicios en línea Lab Exercise Objetivo: Ver la información sobre los procesos Tiempo estimado: 20 minutos. Especificaciones Con el fin de tener un conjunto fijo de procesos para examinar, usted debe tomar una instantánea de todos los procesos actuales en su máquina. Utilice la siguiente secuencia de comandos para capturar primero los encabezados de las columnas del comando ps aux dentro de un archivo llamado snapshot. Luego vuelva a ejecutar el comando ps aux, eliminando el encabezado y clasificando el resto de la salida de acuerdo al tamaño de la memoria virtual de cada proceso. La lista clasificada de procesos se agregará luego al encabezado previamente capturado en el archivo snapshot. Es más fácil de lo que parece. [student@station student]$ ps aux | head -1 > snapshot [student@station student]$ ps aux | tail +2 | sort -rn -k4 >> snapshot [student@station student]$ head -5 snapshot USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND einstein 3057 0.2 7.4 97088 18932 ? S Oct12 2:01 /usr/bin/galeonroot 1063 14.3 6.2 36528 15936 ? S Oct12 163:48 /usr/X11R6/bin/X einstein 1184 0.2 3.8 27160 9868 ? S Oct12 3:00 /usr/bin/gnome-t einstein 1164 0.0 3.0 27856 7792 ? S Oct12 0:11 /usr/bin/python Utilice su archivo de snapshot para contestar las siguientes preguntas. 1. En el archivo ~/biggest.pid almacene el ID de proceso del proceso con el mayor tamaño de memoria virtual (la columna VSZ). 2. Experimente con el comando cut, hasta que pueda extraer la letra inicial de la columna del campo STAT. Esta estará llena casi exclusivamente de letras “R” y “S”, lo que implica que está en estado de ejecución o dormido. Grabe esta columna extraída (a excepción del encabezado) dentro de un archivo llamado ~/pstates.txt. 3. Utilice el comando grep, quizás con el comando wc para determinar el número de instancias en ejecución del programa /sbin/mingetty. Almacene la pregunta como un sólo número en el archivo ~/nmingetty.txt.
  14. 14. 14 Managing Processes 4. Utilice el comando grep, quizás con el comando wc, para determinar la cantidad de procesos en ejecución como usuario root. Almacene la respuesta como un sólo número en el archivo ~/nroot.txt. 5. Inicie el comando top en una terminal y déjelo ejecutando mientras califica su ejercicio. No modifique ni suprima su archivo snapshot hasta no haber terminado de calificar su ejercicio. Deliverables Question 1 1. El archivo ~/biggest.pid que contiene el ID de proceso del proceso con la memoria virtual más grande. 2. El archivo ~/pstates.txt que contiene la columna extraída de los estados de proceso, a excepción de la línea de encabezado. 3. El archivo ~/nmingetty.txt que contiene el número de instancias del programa /sbin/mingetty ejecutándose en su máquina. 4. El archivo ~/nroot.txt que contiene el número de procesos ejecutándose como el usuario root de la máquina. 5. Una instancia en ejecución del comando top. Capítulo 2 Estados del proceso Conceptos clave • • • • • • • En Linux, el primer proceso, /sbin/init, lo inicia el kernel en el arranque. Todos los demás procesos son el resultado de un proceso padre que se duplica o bifurca. Un proceso comienza a ejecutar un nuevo comando a través de un proceso llamado execing. Los nuevos comandos suelen ejecutarse mediante un proceso (a menudo una shell) primero mediante una bifurcación y luego ejecutando un nuevo comando. Este mecanismo se conoce como el mecanismo fork y exec. Los procesos siempre pueden encontrarse en uno de los cinco estados: ejecutable, dormido voluntario, dormido involuntario, detenido o zombi. La ascendencia del proceso puede verse con el comando pstree. Cuando un proceso muere, el padre del proceso debe recolectar su información del código de retorno y del uso de recursos. Cuando un padre muere antes que sus hijos, el primer proceso hereda los huérfanos (usualmente /sbin/init).
  15. 15. 15 Managing Processes Ciclo de vida de un proceso Cómo se inician los procesos En Linux (y Unix), a diferencia de muchos otros sistemas operativos, la creación de proceso y la ejecución de comandos son conceptos separados. Aunque un nuevo proceso es creado para que pueda ejecutarse en un comando especificado (tal como la shell bash creando un proceso para ejecutar el comando chmod), los procesos pueden crearse sin ejecutar un nuevo comando y los nuevos comandos pueden ejecutarse sin crear un nuevo proceso. Creación de un nuevo proceso (forking) Los nuevos procesos se crean mediante una técnica llamada forking. Cuando un proceso se bifurca, crea un duplicado de sí mismo. Inmediatamente después de una bifurcación, el proceso recién creado (el hijo) es un duplicado exacto del proceso original (el padre). El hijo hereda una copia idéntica de la memoria del proceso original, los archivos abiertos de padre, copias idénticas de los parámetros del padre, tales como el directorio de trabajo actual o umask. La única diferencia entre el padre y el hijo es la información heredada del hijo (el hijo tiene un ID de proceso diferente y un proceso de padre diferente, para los principiantes), y (para los programadores en la audiencia) el valor de retorno de la llamada al sistema fork(). Como un aparte rápido para los programadores en la audiencia, un fork suele implementarse mediante una estructura similar a la siguiente: int rc, child_pid; rc = fork(); if (rc == -1) { perror("bad fork"); } else if (rc == 0) { do_child(); } else { child_pid = rc; do_parent(child_pid); } Cuando un proceso desea crear un nuevo proceso, acude al sistema de llamado fork() (sin argumentos). Aunque sólo un proceso entra en el llamado fork(), dos procesos retornan. Para el proceso recién creado (el hijo), el valor de retorno es 0. Para el proceso original (el padre), el valor de retorno es el ID del proceso de hijo. Al bifurcar este valor, el hijo puede ahora salir a hacer cualquier cosa que hubiera empezado a hacer (que suele involucrar exec(), ver lo siguiente) y el padre puede continuar haciendo sus cosas. Ejecución de un nuevo comando (Execing)
  16. 16. 16 Managing Processes Los nuevos comandos se ejecutan a través de un técnica llamada execing (acortamiento en inglés para executing). Cuando se ejecuta un nuevo comando, el proceso actual borra y libera la mayoría de sus recursos y carga una nueva colección de instrucciones desde el comando especificado en el sistema de archivos. La ejecución inicia con el punto de entrada del nuevo programa. Después de utilizar ejecutar un nuevo comando, el nuevo comando todavía es el mismo proceso. Tiene el mismo ID de proceso y muchos de los mismos parámetros (tales como su utilización de recursos, la umask y el directorio actual de trabajo). Apenas olvida su comando anterior y adopta uno nuevo. De nuevo para algunos programadores, la ejecución de un nuevo comando se realiza mediante una o varias variantes de la llamada al sistema execve() tal como la llamada de la biblioteca execl(). rc = execl("chmod", "chmod 755 /etc/passwd"); perror("bad exec"); El proceso escribe la llamada execl(...), especificando el nuevo comando que se va a ejecutar. Si todo sale bien, la llamada execl(...) nunca retorna. En su lugar, la ejecución se realiza en el punto de entrada (por ejemplo, main()) del nuevo programa. Si por la misma razón execl(...) retorna, debe ser un error (tal como no poder localizar el ejecutable del comando en el sistema de archivos). Combinación de dos: Fork y Exec Algunos de los programas pueden utilizar fork sin ejecutar un nuevo comando. Ejemplos incluyen demonios de red, que bifurcan un nuevo hijo para manejar una conexión de un cliente específico, mientras el padre retorna para escuchar nuevos clientes. Otros programas podrían utilizar exec sin bifurcación. Ejemplos incluyen al comando login, el cual se convierte en la shell de inicio de sesión del usuario después de confirmar la contraseña del usuario. Sin embargo, para las shells en particular, fork y exec suelen ir de la mano. Cuando se ejecuta un comando, la shell bash primero bifurca una nueva shell bash. Luego, el hijo ejecuta el nuevo comando apropiado, mientras que el padre espera que el hijo muera para generar un nuevo intérprete de comandos. El linaje de los procesos (y el comando pstree) Tras el arranque del sistema, una de las responsabilidades del sistema del Kernel de Linux es iniciar el proceso por primera vez (usualmente/sbin/init). Todos los otros procesos son iniciados porque se bifurcó un proceso ya existente.[1] Debido a que cada proceso a excepción del primero se crea por bifurcación, dentro de los procesos existe un linaje bien definido de relaciones padre e hijo. El primer proceso iniciado por el kernel inicia fuera del árbol de familia, el cual puede examinarse con el comando pstree.
  17. 17. 17 Managing Processes [maxwell@station maxwell]$ pstree init-+-apmd |-atd |-automount |-battstat-applet ... |-evolution-execu |-evolution-mail |-fetchmail |-galeon-bin |-gconfd-1 |-2*[gconfd-2] |-gdm-binary-+-gdm-binary-+-X | | `-gnome-session---ssh-agent | `-gdm-binary---gnome-session---ssh-agent |-2*[gnome-panel] |-2*[gnome-settings-] |-gnome-system-mo |-gnome-terminal-+-3*[bash] | |-bash---man---sh---sh---less | |-bash---mutt | |-bash---su---bash---pstree | `-gnome-pty-helpe |-gpm |-gvim |-httpd---11*[httpd] |-kapmd |-keventd |-khubd ... Cómo muere un proceso Cuando un proceso muere ya sea que muera normalmente seleccionando exit o anormalmente como el resultado de recibir una señal. Aquí tratamos la salida normal del proceso, dejando para más adelante la discusión acerca sobre la señales. Hemos mencionado anteriormente que los procesos dejan atrás un código de estatus cuando mueren (también llamado valor de retorno) en la forma de un número entero, (recuerde la shell bash que utiliza la variable $? para almacenar el valor de retorno del comando ejecutado previamente). Cuando un proceso sale, todos sus recursos se liberan, a excepción del código de retorno (y alguna información de utilización de recursos contables). Es responsabilidad del padre del proceso coleccionar esta información y liberar los últimos recursos del hijo muerto. Por ejemplo, cuando la shell se bifurca y exec el comando chmod, es responsabilidad de la shell bash padre recoger el valor de retorno del comando cerrado chmod. Huérfanos Si es responsabilidad de los padres limpiar después de sus hijos, ¿qué sucede si el padre muere antes que el hijo? El hijo queda huérfano. Una de las responsabilidades especiales del primer proceso iniciado por el kernel es "adoptar" huérfanos, (observe que en la salida del comando pstree, el primer proceso tiene un número
  18. 18. 18 Managing Processes desproporcionado de hijos. La mayoría de estos fueron adoptados como huérfanos de otros procesos). Zombis Entre el momento en que un proceso sale, liberando la mayoría de sus recursos, y el momento en que su padre recoge su valor de retorno, liberando el resto de sus recursos, el proceso hijo se encuentra en un estado especial conocido como Zombi. Cada proceso pasa a través de un estado transitorio zombi. Los usuarios tienen que estar mirando justo en el momento preciso (con el comando ps, por ejemplo) para ver un zombi. Ellos se aparecen en la lista de procesos, pero no ocupan memoria, ni tiempo de CPU, ni ningún otro sistema de recursos. Ellos son sólo la sombra de un proceso anterior esperando que su padre llegue y los termine. Padres negligentes y zombis de larga vida Ocasionalmente, los procesos padres pueden ser descuidados. Comienzan procesos hijos pero nunca regresan a limpiar lo que dejan. Cuando esto ocurre (usualmente debido a un error de programador), el hijo puede salir, entrar en estado zombi y quedarse ahí. Esto suele suceder cuando los usuarios son testigos de procesos zombis mediante el comando ps, por ejemplo. Deshacerse de zombis es quizás el concepto básico más incomprendido de Linux (y Unix). Mucha gente dirá que no hay forma de deshacerse de ellos, excepto volviendo a arrancar la máquina. ¿Sabe cómo deshacerse de zombis de larga vida utilizando las claves tratadas en esta sección? Los 5 estados del proceso La sección anterior trató la manera como se inician y mueren los procesos. Mientras los procesos están vivos, siempre están en uno de los cinco estados del proceso, los cuales efectúan el cómo y cuándo tienen acceso a la CPU. El siguiente listado muestra los cinco estados, junto con la letra convencional utilizada por ps, top y otros comandos para identificar el estado actual de un proceso. Ejecutable (R) Los procesos en un estado ejecutable son procesos que si tienen la oportunidad de acceder la CPU, la aprovecharían. Los procesos múltiples suelen estar en un estado de ejecución, pero como sólo puede ejecutarse un proceso en la CPU en determinado tiempo, sólo uno de estos procesos en realidad estará ejecutándose en un momento dado. Puesto que los procesos de ejecución entran y salen de la CPU tan rápidamente en el sistema de Linux, parece como si todos los procesos se estuvieran ejecutando de manera simultánea. [1] Dormido voluntario (interrumpible) (S)
  19. 19. 19 Managing Processes Como el nombre lo implica, un proceso que está dormido voluntario ha elegido estar así. Por lo general, este es un proceso que no tiene nada que hacer hasta que suceda algo interesante. Un ejemplo clásico es el demonio de red httpd, el cual es un proceso que implementa un servidor de red. En medio de solicitudes de un cliente (navegador de red), el servidor no tiene nada que hacer, y elige irse a dormir. Otro ejemplo sería el comando top, que lista procesos cada cinco segundos. Mientras espera que pasen los cinco segundos, se duerme voluntariamente. Cuando el proceso esté interesado en que algo suceda (tal como cuando el cliente de red hace una solicitud o los cinco segundos expiran), el proceso dormido vuelve al estado ejecutable. Dormido involuntario (no interrumpible) (D) En ocasiones, dos procesos tratan de acceder el mismo recurso de sistema al mismo tiempo. Por ejemplo, un proceso trata de leer de un bloque o un disco mientras que el bloque está siendo escrito debido a otro proceso. En estas situaciones, el kernel fuerza al proceso a dormir. El proceso no eligió dormir, éste hubiera preferido ser ejecutable para poder hacer las cosas. Cuando el recurso es liberado, el kernel pondrá el proceso de nuevo en su estado ejecutable. Aunque los procesos están constantemente durmiendo involuntariamente, no suelen estarlo por mucho tiempo. Como resultado, los usuarios no suelen ver los procesos en dormido involuntario, excepto en sistemas ocupados. Procesos detenidos (suspendidos) (T) Ocasionalmente, los usuarios deciden suspender procesos. Los procesos suspendidos no realizarán ninguna acción hasta no ser reiniciados por el usuario. En la shell bash, la secuencia de teclas CONTROL-Z puede utilizarse para suspender un proceso. En programación, los depuradores suelen suspender los programas que están depurándose cuando ciertos eventos suceden (como cuando se producen puntos de interrupción). Procesos zombi (Z) Como lo mencionamos antes, cada proceso muriendo pasa a través de un estado zombi transitorio. No obstante, en ocasiones, algunos se quedan en ese estado. Los procesos zombis han terminado de ejecutar, han liberado toda su memoria y casi todos sus recursos. Dado que no están consumiendo recursos, son poco más que una molestia que puede aparecer en listados de procesos. Ver estados de procesos Cuando se ve la salida de comandos tales como ps y top, los estados de procesos suelen enumerase bajo el encabezado STAT. El proceso es identificado por una de las siguientes letras:
  20. 20. 20 Managing Processes • • • • • Ejecutable - R Dormido - S Detenido - T Dormido ininterrumpible - D Zombi – Z Ejemplos Identificación de estados de procesos [maxwell@station F UID PID COMMAND 100 0 1 init 100 500 4248 bash 100 500 4292 bash 004 0 1829 updatedb 004 0 1827 updatedb 000 500 4333 vim proj1_s 000 500 4334 top 004 501 5486 [netstat 000 501 5793 vim c 000 501 5798 /bin/bash 040 501 5799 /bin/bash 000 501 5800 ps -alx 000 501 5801 tail maxwell]$ ps -alx PPID PRI NI VSZ RSS WCHAN STAT TTY 0 15 0 1344 775 15 0 4136 1412 wait4 S tty3 0:00 - 776 15 0 4144 1420 schedu S tty4 0:00 - 1774 17 0 1472 528 down D 1774 16 0 1464 520 - R 4292 15 0 7612 2616 do_sig T 4248 15 0 3612 1052 schedu S 1220 16 0 2600 15 0 7708 2816 wait4 S pts/0 0:00 5793 16 0 3804 944 wait4 S pts/0 0:00 5798 17 0 3808 1000 wait4 S pts/0 0:00 5799 17 0 3148 1240 - R 5799 17 0 3144 0 436 schedu S TIME 0 do_exi Z 420 pipe_w S ? pts/3 pts/3 tty4 tty3 ? pts/0 pts/0 0:06 0:00 0:00 0:00 2:57 0:00 0:00 0:00 Un proceso dormido (voluntario). El proceso init está esperando que algo "interesante" suceda tal como un huérfano recién creado a heredar. Un proceso dormido(involuntario) o "bloqueado". El comando updatedb está compitiendo por algún recurso en el sistema probablemente con la otra instancia del proceso updatedb justo debajo de éste. Un proceso detenido. Este editor vim probablemente ha sido suspendido manualmente con la secuencia de teclas CONTROL-Z. Un proceso zombi probablemente abandonado por un navegador de red galeon negligente. Un proceso ejecutable en este caso el comando ejecutable ps.
  21. 21. 21 Managing Processes Ejercicios en línea Lab Exercise Objetivo: Explorar diferentes estados de procesos Estimated Time: 10 mins. Especificaciones 1. Con el fin de explorar los estados de procesos debemos crear procesos que estén compitiendo por los mismos recursos. Utilice un editor de texto sencillo para crear el siguiente guión, almacénelo como ~/clobber_it.sh y hágalo ejecutable. 2. 3. 4. 5. 6. 7. [maxwell@station maxwell]$ cat clobber_it.sh #!/bin/bash for i in $(seq 1000); do echo "hello world" > poor_overworked_file done 8. Aunque este guión escribirá al pobre archivo sobrecargado 1000 veces, lo hará de forma secuencial y así nunca estará compitiendo por acceder al archivo. Dado que necesitamos procesos múltiples compitiendo por el mismo recurso, cree también el mismo script. Nómbrelo ~/clobber_it_lots.sh y hágalo ejecutable. 9. 10. 11. 12. 13. 14. [maxwell@station maxwell]$ cat clobber_it_lots.sh #!/bin/bash for i in $(seq 1000); do ./clobber_it.sh & done Esto debería funcionar. 15. In one terminal, run the command top -d1. This should run the top command, updating continuously. While top is running, use the U command to limit the display to your own processes (i.e., type in your own username). 16. When we say go, in a separate terminal (either another terminal window in an X graphical environment, or a separate virtual console), run the script clobber_it_lots.sh. This will start about 1000 processes on your machine, which will obviously stress the system, but it should be able to handle it. [1] The system may seem sluggish, but with patience, it should still be responsive. If things get unbearable, the script can be canceled with a CTRL-C. We haven't said go yet. 17. Mientras el guión esté ejecutándose, observe la terminal con el comando top. Usted debería ver muchos procesos iniciándose y deteniéndose como también muchos procesos en el estado “D”. Si tiene suerte, podría capturar incluso un zombi. Aún no hemos dicho que empiece. 18. También mientras se esté ejecutando el script, en otro terminal, ejecute el comando ps aux y redirija la salida al archivo ~/lotsa_processes.txt.
  22. 22. 22 Managing Processes Observe el contenido del script y asegúrese que al menos cinco procesos en el estado “D” hayan sido registrados. Aún no hemos dicho que empiece. 19. ¡Empiece! 20. Después de crear su archivo ~/lotsa_processes.txt y de sentir que ha entendido, puede cancelar el script clobber_it_lots.sh con la secuencia CONTROL-C y abandone el comando top. Deliverables Question 1 1. El archivo ~/lotsa_processes.txt que contiene la salida del comando ps aux con al menos 5 instancias del proceso en el estado “D” (ininterrumpible). Capítulo 3 Programación de procesos: nice y renice Conceptos clave • • • Una tarea primaria del kernel de Linux es la programación de procesos. Cada proceso tiene un valor de niceness que influye en su programación. Los comandos nice y renice pueden cambiar la prioridad de programación de un proceso. Nomenclatura de programación de procesos Una de las tareas fundamentales del kernel de Linux es asegurar que los procesos compartan recursos del sistema de manera efectiva. Uno de los recursos más importantes que tiene que compartirse es la CPU. La forma en que el kernel decide qué proceso tiene que ejecutarse en la CPU y la hora se conoce como programación. Cada proceso tiene dos valores que influyen en su programación. El primero es un valor dinámico que el kernel cambia constantemente. El segundo, es un valor fijo que sólo de vez en cuando el usuario lo cambia. En la comunidad de código abierto, la nomenclatura utilizada para describir estos dos valores ha sido inconsistente lo que lleva a la confusión. En lo posible, este texto tratará de ser consistente con los comandos ps y top y se referirá al primer valor (dinámico) como la prioridad del proceso y al segundo valor (fijo) como el niceness del proceso. Programación de procesos en esencia Recientemente, se ha prestado mucha atención a los métodos utilizados por el kernel de Linux para implementar programación y la técnica ha variado con cada lanzamiento del kernel. Aunque la siguiente discusión no es correcta en detalle comunica en esencia la forma como el kernel de Linux programa procesos.
  23. 23. 23 Managing Processes Para ilustrar la programación de un modo más fácil, maxwell iniciará cuatro versiones del comando cat, ejecutándose en el segundo plano, (los procesos se pueden ejecutar en segundo plano agregando el signo “&”), como se discutirá en una lección más adelante. Los comandos cat leen desde /dev/zero (un seudo dispositivo que actúa como una fuente infinita de ceros binarios) y escriben en /dev/null (un seudo dispositivo que bota todo lo que se escribe en él). [maxwell@station [1] 6698 [maxwell@station [2] 6699 [maxwell@station [3] 6700 [maxwell@station [4] 6701 maxwell]$ cat /dev/zero > /dev/null & maxwell]$ cat /dev/zero > /dev/null & maxwell]$ cat /dev/zero > /dev/null & maxwell]$ cat /dev/zero > /dev/null & ¿Por cuánto tiempo se ejecutarán estos comandos cat? Para siempre. El usuario maxwell controla los procesos en su máquina mediante el comando top. 00:25:43 up 11:07, 10 users, load average: 6.02, 5.08, 3.01 128 processes: 121 sleeping, 7 running, 0 zombie, 0 stopped CPU states: 8.5% user 3.2% system 4.6% nice 0.0% iowait idle Mem: 255232k av, 251560k used, 3672k free, 0k shrd, 36592k buff 162724k actv, 33644k in_d, 3952k in_c Swap: 522104k av, 145148k used, 376956k free 74780k cached PID USER PRI COMMAND 6698 maxwell 25 6699 maxwell 22 6700 maxwell 24 6757 einstein 21 6701 maxwell 25 6686 maxwell 35 xlyap 6758 maxwell 19 1063 root 15 1 root 15 2 root 15 keventd ... NI SIZE RSS SHARE STAT %CPU %MEM 0 404 400 0 400 400 0 400 372 0 25992 24M 0 400 400 10 6608 4836 352 352 352 3596 352 1108 0 1120 1120 0 33304 16M 0 108 76 0 0 0 852 692 52 0 R R R R R R N R S S SW 83.5% TIME CPU 19.3 19.3 19.3 17.4 16.4 4.8 0.1 0.1 0.1 9.7 0.1 1.8 0:24 0:24 0:24 0:04 0:24 0:44 2.9 1.9 0.0 0.0 0.4 6.5 0.0 0.0 0:00 33:56 0:04 0:00 0 0 0 0 0 0 cat cat cat jade cat 0 top 0 X 0 init 0 Mientras observa el comando top, maxwell observa que los valores en la tercera columna (con la etiqueta PRI) están en constante cambio. Estos son los valores de "prioridad" dinámicos del proceso mencionados anteriormente. La cuarta columna (con la etiqueta NI) es el valor fijo de "niceness" del proceso. Prioridades del proceso
  24. 24. 24 Managing Processes Cuando se programan los procesos, el kernel da a cada proceso un puñado de contadores. Cada vez que un proceso se programa en la CPU, entrega uno de sus contadores. Cuando decide qué proceso programar en la próxima CPU, el kernel escoge un proceso ejecutable con la mayoría de contadores. Eventualmente, el kernel alcanzará un estado donde todos los procesos ejecutables han utilizado sus contadores. Esto se conoce como el final de una programación epoch y en este punto el kernel inicia todos los procesos otra vez con un puñado de contadores. Observe que los procesos que no están en estado ejecutable nunca entregan sus contadores. Sin embargo, si un proceso dormido se despertara de repente (porque algo interesante ha sucedido) y fuera enviado al estado ejecutable, muy probablemente tendría más contadores que procesos ejecutándose por un tiempo y le gustaría que fueran programados rápidamente en la CPU. ¿Cómo se relaciona esto con los valores demostrados en la columna PRI? Piense en esta columna como si fuera un número de procesos de contadores, restados de 40. Por lo tanto, los procesos con una prioridad inferior (como es listado por el comando top) tienen una ventaja en la programación. En la salida de arriba, los comandos cat, en constante ejecución, están consumiendo sus contadores. Sin embargo, el proceso init que está durmiendo en el segundo plano, no lo está. Proceso niceness Como se mencionó anteriormente, cada proceso también tiene un valor estático conocido como su valor de niceness. Este valor tiene un rango que va de -20 a 19 para cualquier proceso, iniciando en 0 por defecto. ¿Cómo influye un niceness de un proceso en su programación? Al comienzo de la programación puede pensar que el kernel resta un valor de niceness del proceso del número de contadores del proceso que se le ha asignado. Como resultado de procesos más, "amables" (aquellos con un alto valor de niceness) obtienen menos contadores y por lo tanto menos tiempo en la CPU, mientras que procesos más "ambiciosos" (aquellos con un valor de niceness menor que 0) obtienen más contadores y más tiempo en la CPU. Si un proceso "amable" es el único ejecutándose en la máquina entonces obtendría acceso total a la CPU. Cambio del valor niceness de un proceso Suponga que maxwell fuera a ejecutar una simulación física que le tomaría varios días completar. Al incrementar el valor de niceness del proceso, el proceso pacientemente esperaría si alguien más estuviera ejecutando procesos en la máquina. Si nadie más estuviera en la máquina, la simulación física tendría acceso total a la CPU. Hay varias técnicas por las cuales maxwell podría alterar su valor de niceness del proceso. Uso del comando nice para iniciar un comando con prioridad baja
  25. 25. 25 Managing Processes El comando nice se utiliza para establecer un valor de niceness del proceso al iniciar el proceso. Cuando maxwell inicia su simulación (la cual es un ejecutable en su directorio de inicio llamado ~/simulation) lo hace lo más nice posible, con el valor de +19, (también coloca el proceso en segundo plano. No se preocupe por esto en este momento puesto que lo abarcaremos en una próxima lección). [maxwell@station maxwell]$ nice -19 ./simulation & Observe que la sintaxis puede confundir. El símbolo -19 no debería considerarse negativo 19 sino en cambio la opción numérica 19. El usuario maxwell de nuevo controla los procesos mediante el comando top. Los primeros pocos procesos listados se enumeran a continuación. PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 7192 maxwell 25 0 400 400 352 R 22.7 0.1 0:35 0 cat 7193 maxwell 25 0 400 400 352 R 22.7 0.1 0:35 0 cat 7191 maxwell 25 0 400 400 352 R 21.9 0.1 0:36 0 cat 7194 maxwell 25 0 404 404 352 R 21.9 0.1 0:35 0 cat 1184 einstein 15 0 11140 8708 3144 R 4.7 3.4 1:28 0 gnome-termina 7198 maxwell 39 19 404 404 352 R N 2.1 0.1 0:02 0 simulation 4293 maxwell 15 0 5164 5016 2384 S 1.7 1.9 6:07 0 gnome-system- Como algo conveniente, el comando ps representa el estado de proceso con una “N” para indicar que el proceso ha aumentado su valor de niceness. Dado que otros comandos cat están utilizando la máquina, la simulación de maxwell sólo está usando cerca del 2.1 % de la CPU. Luego, maxwell se deshace de los comandos cat (mediante las técnicas que veremos en la siguiente lección). [maxwell@station maxwell]$ killall cat [maxwell@station maxwell]$ [3] Terminated cat /dev/zero >/dev/null [4] Terminated cat /dev/zero >/dev/null [5] Terminated cat /dev/zero >/dev/null [6] Terminated cat /dev/zero >/dev/null Cuando observa el comando top una vez más, su simulación, ahora el (casi) único proceso en la máquina, está recibiendo todo el tiempo de la CPU. PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM COMMAND 7198 maxwell 39 19 404 404 352 R N 94.4 0.1 simulation 7210 maxwell 20 0 1120 1120 852 R 2.8 0.4 1063 root 15 0 33516 17M 832 S 1.9 7.0 4212 maxwell 15 0 5828 3012 1072 S 0.9 1.1 applet-gu 1 root 15 0 108 76 52 S 0.0 0.0 TIME CPU 0:51 0 0:00 47:01 0:21 0 top 0 X 0 rhn- 0:04 0 init
  26. 26. 26 Managing Processes Como una sutileza adicional, el número especificado es el número que va a agregarse al valor de niceness de la shell actual. Esto rara vez se nota, dado que la mayoría de las shells se ejecutan con un niceness de 0. No obstante, si una shell estuviera ejecutándose con un valor de niceness de 10, la siguiente opción de línea de comando resultaría en la simulación que está ejecutándose con un valor de niceness de 15. [maxwell@station maxwell]$ nice -5 ./simulation & Uso de renice para alterar un proceso en ejecución El comando renice puede utilizarse para cambiar el niceness de un proceso en ejecución. Los procesos pueden ser especificados por el ID del proceso, nombre de usuario, o nombre de grupo, dependiendo de cuál de las siguientes opciones se utilicen. Table 1. Opciones para el comando renice Opción Efecto -p interpreta los argumentos restantes como ID del proceso (por defecto) -u interpreta los argumentos restantes como nombres de usuarios. -g interpreta los argumentos restantes como ID de grupo. Suponga que maxwell ya ha iniciado su simulación sin alterar su valor de niceness. [maxwell@station maxwell]$ ps -C simulation u USER PID %CPU %MEM VSZ RSS TTY STAT START maxwell 7348 58.9 0.1 3408 400 pts/5 R 01:29 simulation [maxwell@station maxwell]$ ps -C simulation l F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY COMMAND 0 515 7348 6064 25 0 3408 400 R pts/5 simulation TIME COMMAND 0:50 TIME 0:51 El proceso está recibiendo una gran cantidad de tiempo de la CPU. El proceso tiene por defecto un valor de niceness de 0. Decide ser más cortés con otras personas que podrían estar utilizando la máquina y utiliza el comando renice para elevar el valor de niceness del proceso. En la ausencia de cualquier opción, el comando renice espera un valor de niceness y un ID de proceso como sus dos argumentos. [maxwell@station maxwell]$ renice 19 7347 7348: old priority 0, new priority 19 Observe la inconsistencia en la sintaxis. El comando renice a diferencia del comando nice, no espera que el valor de niceness sea especificado como una opción, sino como un argumento. De hecho, renice -19 7347 sería interpretado como un valor de niceness de -19. Enlodando más las aguas, la salida del comando renice se refiere al
  27. 27. 27 Managing Processes valor como una prioridad en lugar de un niceness, (como también lo hace alguna de la documentación relacionada). Uso del comando top para otorgar otro valor de nice a un proceso Como se mencionó antes, el comando top utiliza la tecla r para cambiar el valor nice de un proceso. Mientras controla procesos con top, al presionar r abrirá el siguiente diálogo que aparece encima de la lista de procesos. PID to renice: 7347 Renice PID 7347 to value: 19 Hacer procesos mucho más ambiciosos ¿Qué sucedería si maxwell fuera malintencionado y quisiera hacer su simulación mucho más ambiciosa en lugar de más amable? Afortunadamente, para otros usuarios en la máquina, los usuarios normales no pueden bajar el niceness de un proceso. Esto trae dos implicaciones. 1. Debido a que los procesos inician con un niceness de 0 por defecto, los usuarios normales no pueden hacer procesos "ambiciosos" con valores de niceness negativos. 2. Una vez un proceso ha sido hecho nice, los usuarios normales no pueden volverlo "normal" otra vez . Suponga que el administrador observó que la simulación de maxwell estaba tomando mucho tiempo de la CPU. Ella pudo utilizar el comando renice como root para elevar el niceness de maxwell y maxwell no pudo restaurarlo. Ejemplos Ver prioridades Abajo hay varias tomas de pantalla ps -alx a medida que se ejecuta el proceso. Observe los campos "PRI" y "nice" a lo largo del tiempo. Son los campos 5 y 6 de izquierda a derecha. [maxwell@station [1] 2739 [maxwell@station F UID PID COMMAND ... 000 501 2676 bash 000 501 2739 find / 000 501 2740 /bin/bash - maxwell]$ find / 2>/dev/null >/dev/null & maxwell]$ ps -alx PPID PRI NI VSZ 898 15 2676 18 2611 16 0 0 0 RSS WCHAN 4232 1544 wait4 3284 3804 STAT TTY TIME S 0:00 644 948 wait4 pts/0 R S pts/0 pts/1 0:00 0:00
  28. 28. 28 Managing Processes 040 501 2741 /bin/bash 000 501 2742 ps -alx 000 501 2743 tail ... 2740 16 0 3808 1004 wait4 S pts/1 0:00 2741 17 0 3144 1232 - R pts/1 0:00 2741 17 0 3144 420 pipe_w S pts/1 0:00 [maxwell@station F UID PID COMMAND ... 000 501 2676 bash 000 501 2718 /bin/bash 040 501 2719 /bin/bash 000 501 2720 ps -alx 000 501 2721 tail 000 501 2739 find / ... maxwell]$ ps -alx PPID PRI NI VSZ RSS WCHAN STAT TTY TIME 898 16 0 4232 1544 wait4 S pts/0 0:00 2611 15 0 3808 944 wait4 S pts/1 0:00 2718 16 0 3812 1000 wait4 S pts/1 0:00 2719 17 0 3148 1232 - R pts/1 0:00 2719 17 0 3136 R pts/1 0:00 2676 17 0 3248 384 576 - R pts/0 0:00 La prioridad del proceso find fluctúa con el tiempo. El niceness, por el contrario, permanece fijo en 0. Luego, maxwell utiliza el comando renice para alterar el valor de niceness del proceso. [maxwell@station [maxwell@station 000 501 2982 bash 000 501 2739 find / 000 501 3010 /bin/bash 040 501 3011 /bin/bash 000 501 3012 ps -alx 000 501 3013 tail maxwell]$ renice 5 2739 maxwell]$ ps -alx 898 15 0 4228 1544 schedu S 5 3248 576 - pts/0 RN pts/0 0:00 2676 20 0:00 2611 16 0 3804 948 wait4 S pts/1 0:00 3010 17 0 3808 1004 wait4 S pts/1 0:00 3011 17 0 3140 1228 - R pts/1 0:00 3011 17 0 3140 416 pipe_w S pts/1 0:00 Debido a que el valor de niceness se ha incrementado, el proceso tiene valores más altos de prioridad (implicando menos acceso a la CPU por una época de programación). El nuevo valor de niceness. Cambiando de parecer, maxwell decide restaurar el niceness a su valor predeterminado de 0. [maxwell@station maxwell]$ renice 0 2739
  29. 29. 29 Managing Processes renice: 2739: setpriority: Permission denied Dado que a los usuarios estándar no se les permiten valores de niceness más bajos, el comando falla. Cambio de prioridades con renice Al utilizar la opción -u, el usuario maxwell puede cambiar los valores de niceness para todos los procesos al mismo tiempo. [maxwell@station maxwell]$ ps -lu maxwell F S UID PID PPID C PRI NI ADDR SZ WCHAN CMD 4 S 515 3031 3028 0 75 0 - 1078 wait4 bash 1 S 515 8954 1 0 79 0 - 3313 schedu gvim 0 S 515 8958 3031 1 80 0 - 1078 wait4 bash 0 R 515 8984 8958 0 83 0 779 ps [maxwell@station maxwell]$ renice 5 -u maxwell 515: old priority 0, new priority 5 [maxwell@station maxwell]$ ps -lu maxwell F S UID PID PPID C PRI NI ADDR SZ WCHAN CMD 4 S 515 3031 3028 0 85 5 - 1078 wait4 bash 1 S 515 8954 1 0 85 5 - 3313 schedu gvim 0 S 515 8958 3031 0 80 5 - 1078 wait4 bash 0 R 515 8986 8958 0 86 5 779 ps TTY TIME pts/4 00:00:00 ? 00:00:00 pts/4 00:00:00 pts/4 00:00:00 TTY TIME pts/4 00:00:00 ? 00:00:00 pts/4 00:00:00 pts/4 00:00:00 Ejercicios en línea Lab Exercise Objetivo: Cambiar las prioridades de los procesos. Estimated Time: 10 mins. Especificaciones 1. Ejecutar el siguiente comando en una terminal. 2. [student@station student]$ cat /dev/zero > /dev/null 3. En otra terminal, utilice el comando renice para cambiar el valor de niceness de todos los procesos que le pertenezcan hasta 5 (podría considerar el utilizar el comando pgrep junto con el comando xargs para este paso). 4. Después de completar el último paso, cambie el valor de niceness del proceso cat (iniciado en el paso 1) a 10.
  30. 30. 30 Managing Processes 5. Utilice el comando nice para iniciar otro comando cat (de nuevo leyendo /dev/zero redirigido a /dev/null) con el valor de niceness de 15. Califique su ejercicio con ambas instancias del comando cat aún ejecutándose. Question 1 1. Un comando cat ejecutándose con el valor de niceness de 10. 2. Un comando cat ejecutándose con el valor de niceness de 15. 3. Todos los otros procesos ejecutados por usted tienen un valor de niceness de 5. Limpieza Cuando haya terminado de calificar su ejercicio puede detener todos sus procesos cat con la secuencia de control CTRL-C. Capítulo 4 Envío de señales Conceptos clave • • • • • • • • Las señales son una forma de bajo nivel de la comunicación entre procesos que surgen de una variedad de recursos, incluyendo el kernel, la terminal y otros procesos. Las señales se distinguen por los números de señales que tienen nombres y usos simbólicos. Los nombres simbólicos para los nombres de señales pueden listarse con el comando kill -l. El comando kill envía señales a otros procesos. Tras recibir una señal, un proceso puede ya sea, ignorarla, reaccionar de un modo especificado por defecto de kernel o implementar un manejador de señal personalizado. Convencionalmente, el número de señal 15 (SIGTERM) se utiliza para solicitar la terminación de un proceso. La señal número 9 (SIGKILL) termina un proceso y no puede anularse. Los comandos pkill y killall pueden utilizarse para enviar señales a procesos especificados por nombre de comando o el usuario a quienes pertenecen. Otras utilidades, tales como top y el Monitor de sistema GNOME, también pueden utilizarse para enviar señales. Señales Linux (y Unix) utiliza señales para notificar procesos de eventos anormales, y como un mecanismo primitivo de comunicación entre procesos. Algunas veces, las señales se conocen como interrupciones de software, porque pueden interrumpir el flujo normal de ejecución de un proceso. El kernel utiliza señales para notificar procesos de conducta
  31. 31. 31 Managing Processes anormal, como si el proceso tratase de dividir un número por cero o tratase de acceder memoria que no le perteneciera. Los procesos también pueden enviar señales a otros procesos. Por ejemplo, una shell bash podría enviar una señal a un proceso xclock. El proceso receptor sabe muy poco acerca de los orígenes de la señal. No sabe si la señal se originó del kernel o de algún otro proceso, todo lo que sabe es que recibió una señal. Figure 1. Xclock recibe un señal número 15 de Bash Sin embargo, hay diferentes sabores de señales. Los diferentes sabores tienen números simbólicos pero también se identifican con números enteros. Los varios números enteros y el nombre simbólico que les son asignados pueden listarse por medio del comando kill -l o los puede encontrar en la página del manual signal(7). [einstein@station einstein]$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 5) SIGTRAP 6) SIGABRT 7) SIGBUS 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 13) SIGPIPE 14) SIGALRM 15) SIGTERM 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 22) SIGTTOU 23) SIGURG 24) SIGXCPU 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 30) SIGPWR 31) SIGSYS 33) SIGRTMIN 35) SIGRTMIN+2 36) SIGRTMIN+3 37) SIGRTMIN+4 39) SIGRTMIN+6 40) SIGRTMIN+7 41) SIGRTMIN+8 43) SIGRTMIN+10 44) SIGRTMIN+11 45) SIGRTMIN+12 47) SIGRTMIN+14 48) SIGRTMIN+15 49) SIGRTMAX-15 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 63) SIGRTMAX-1 4) 8) 12) 17) 21) 25) 29) 34) 38) 42) 46) 50) 54) 58) 62) SIGILL SIGFPE SIGUSR2 SIGCHLD SIGTTIN SIGXFSZ SIGIO SIGRTMIN+1 SIGRTMIN+5 SIGRTMIN+9 SIGRTMIN+13 SIGRTMAX-14 SIGRTMAX-10 SIGRTMAX-6 SIGRTMAX-2 Linux, al igual que varias versiones de Unix, implementa 32 señales "normales". En Linux, las señales se numeran a partir de 32 hasta 63 (que no son estándar entre las varias versiones de Unix) y son señales en "tiempo real" y van más alla del objetivo de este texto. ¿Por qué se envían las señales?
  32. 32. 32 Managing Processes Hay una variedad de razones por las cuales las señales se pueden enviar a un proceso como se ilustra con los siguientes ejemplos. Excepciones de hardware El proceso le pidió al hardware realizar alguna operación errónea. Por ejemplo, el kernel enviará un proceso SIGFPE (señal número 8) si realiza una división por 0. Condiciones del software Los procesos pueden necesitar ser notificados de alguna condición anormal del software. Por ejemplo, cada vez que muere un proceso, el kernel envía un SIGCHLD (número de señal 17) al padre del proceso. Otro ejemplo, las aplicaciones gráficas X reciben un SIGCHLD (número de señal 17) cada vez que su ventana cambia de tamaño, para poder responder a la nueva geometría. Interrupciones de terminal Varias secuencias de control de teclas de la terminal envían señales al proceso de la shell bash. Por ejemplo, CONTROL-C envía un SIGINT (número de señal 2) mientras que CONTROL-Z envía un SIGTSTP (número de señal 20). Otros procesos Los procesos pueden elegir enviar señales a cualquier otro proceso perteneciente al mismo usuario. El comando kill está diseñado para hacer justo esto. Envíar señales: el comando kill El comando kill se utiliza para enviar señales a otros procesos. Éste espera ser llamado con una opción numérica o simbólica que especifica la señal a enviar y un ID de proceso que especifica el proceso que debería recibirlo. A manera de ejemplo, las siguientes líneas de comando envían un SIGCHLD (número de señal 17) al proceso xclock, el ID del proceso número 8060. [einstein@station einstein]$ ps PID TTY TIME CMD 7985 pts/5 00:00:00 bash 8060 pts/5 00:00:01 xclock 8061 pts/5 00:00:00 ps [einstein@station einstein]$ kill -17 8060 [einstein@station einstein]$ kill -CHLD 8060 [einstein@station einstein]$ kill -SIGCHLD 8060 Cuando se utiliza el nombre simbólico para especificar una señal, el prefijo “SIG” (compartido por todas las señales) puede ser incluído u omitido. Recepción de señales
  33. 33. 33 Managing Processes Cuando un proceso recibe una señal puede realizar una de las siguientes tres acciones. Implementar un manejador de señal predeterminado del kernel Para cada tipo de señal hay una respuesta predeterminada implementada por el kernel. A cada señal se le asigna una de las siguientes conductas. • • • • Terminar: El proceso de recepción se cierra. Ignorar: El proceso de recepción ignora la señal Núcleo: El proceso de recepción termina, pero bota una imagen de su memoria en un archivo llamado core en el actual directorio de trabajo del proceso. El archivo core puede ser utilizado por desarrolladores para ayudar a depurar el programa. [1] Pare: detenga o (suspenda) el proceso. La página de manual signal(7) documenta la conducta asignada para cada señal. Escoja ignorar la señal Los programadores pueden elegir que su aplicación simplemente ignore señales especificadas. Escoger implementar un manejador de señal personalizado Los programadores pueden elegir implementar su propia conducta cuando se recibe una señal específica. La respuesta del programa es completamente determinada por el programador. A no ser que la documentación del programa diga lo contrario, usted puede asumir que un proceso responderá con la conducta implementada de kernel. Cualquier otra respuesta debe estar documentada. Uso de señales para terminar procesos De las 32 señales utilizadas en Linux (y Unix) los usuarios normales en práctica (explícitamente) sólo hacen uso de unas pocas. Table 1. Señales importantes para usuarios normales Número Symbol Acción 2 SIGINT Interrumpe (solicita terminar) el proceso. Esta es la señal generada por la secuencia de control CTRL-C. 9 SIGKILL Fuerza el terminar el proceso (esta señal puede no ser anulada por el proceso) 15 SIGTERM Solicita la terminación del proceso.
  34. 34. 34 Managing Processes Número Symbol 20 SIGTSTP Acción Detiene (suspende) el proceso. Esta es una señal generada por la secuencia de control CTRL-Z. Los usuarios estándar suelen utilizar señales para terminar un proceso (razón del nombre del comando kill). Por convención, si los programadores quieren implementar la conducta personalizada cuando se apaga (como por ejemplo botando memoria importante al disco, etc), ellos implementan un manejador de señal personalizado de 15 para realizar la acción. El número de señal 9 se maneja especialmente por el kernel y no puede anularse por un manejador de señal personalizado o ser ignorado. Este se reserva como un último recurso, la técnica de nivel de kernel para matar un proceso. A manera de ejemplo, einstein iniciará un comando cat que en un principio se ejecutaría para siempre. Luego traza el ID del proceso del comando y termina con un SIGTERM. [einstein@station einstein]$ cat /dev/zero > /dev/null & [1] 8375 [einstein@station einstein]$ ps PID TTY TIME CMD 7985 pts/5 00:00:00 bash 8375 pts/5 00:00:01 cat 8376 pts/5 00:00:00 ps [einstein@station einstein]$ kill -15 8375 [einstein@station einstein]$ [1]+ Terminated cat /dev/zero >/dev/null SIGTERM (número de señal 15) es la señal por defecto para el comando kill, por lo tanto einstein pudo haber utilizado kill 8375 para el mismo efecto. A continuación, einstein repite la secuencia, esta vez enviando un SIGKILL. [einstein@station einstein]$ cat /dev/zero > /dev/null & [1] 8387 [einstein@station einstein]$ ps PID TTY TIME CMD 7985 pts/5 00:00:00 bash 8387 pts/5 00:00:01 cat 8388 pts/5 00:00:00 ps [einstein@station einstein]$ kill -9 8387 [einstein@station einstein]$ [1]+ Killed cat /dev/zero >/dev/null Alternativas para el comando kill El uso de señales para controlar procesos es una ocurrencia tan común que las alternativas para usar el comando kill abundan. Las siguientes secciones mencionan unas cuantas. El comando pkill
  35. 35. 35 Managing Processes En cada uno de los ejemplos anteriores, einstein necesita determinar el ID de un proceso antes de enviar una señal a éste con el comandokill. El comando pkill se puede utilizar para enviar señales a procesos seleccionados por medios más generales. El comando pkill espera la siguiente sintaxis. pkill [-signal] [OPCIONES] [PATRÓN] El primer símbolo especifica opcionalmente el número de señal para enviar (por defecto, el número de señal 15). PATTERN es una expresión regular extendida que coincidirá con nombres de comandos. El siguiente cuadro lista las opciones de comando más utilizadas. Los procesos que cumplen con todos los criterios especificados enviarán la señal especificada. Table 1. Opciones para el comando pkill Opción -n Efecto Selecciona únicamente los procesos coincidentes iniciados más recientemente. -u USER Selecciona procesos pertenecientes al usuario USER. -t TERM Selecciona procesos controlados por terminal TERM. De manera conveniente, el comando pkill se omite a si mismo y la shell que lo inició cuando mataba todos los proceso pertenecientes a un usurario particular o a una terminal. Considere el siguiente ejemplo. [maxwell@station maxwell]$ ps PID TTY TIME CMD 10353 pts/4 00:00:00 bash 10396 pts/4 00:00:00 xclock 10397 pts/4 00:00:03 mozilla-bin 10422 pts/4 00:00:00 ps [maxwell@station maxwell]$ pkill -u maxwell [1]- Terminated xclock [maxwell@station maxwell]$ ps PID TTY TIME CMD 10353 pts/4 00:00:00 bash 10424 pts/4 00:00:00 ps [2]+ Exit 15 mozilla Observe que aunque la shell bash se clasifica como un proceso perteneciente al usuario maxwell, ésta sobrevivió. El comando killall Igual que pkill, el comando killall envía señales a procesos especificados por el nombre de comando. El comando killall soporta las siguientes opciones. Table 1. Opciones para el comando killall
  36. 36. 36 Managing Processes Opción Efecto -i, -interactive De modo interactivo pregunta al usuario antes de enviar la señal a un proceso. -w, --wait Espera hasta que todos los procesos estén muertos antes de retornar. El Monitor del sistema La aplicación del Monitor de sistema GNOME, presentada en una lección anterior, también puede utilizarse para enviar señales a los procesos. Al hacer click derecho en un proceso, un menú emergente le permite al usuario seleccionar End Process, el cual tiene el efecto de entregar un SIGTERM al proceso. ¿Qué hace la opción del menú Matar proceso? Figure 1. Terminación de procesos mediante el monitor del sistema. El comando top El comando top puede también utilizarse para entregar señales a procesos. Al utilizar la tecla K, aparece el siguiente diálogo encima de la lista de procesos, permitiéndole al usuario especificar qué procesos ID deberían recibir la señal y qué señal entregar. PID to kill: 4859 Kill PID 4859 with signal [15]: 9 Ejemplos Uso de señales para terminar procesos Las señales suelen ser la única forma de terminar procesos que están siendo manejados por una línea de comando de shell. Por ejemplo, los clientes (aplicaciones) gráficos X pueden matarse al entregar un SIGTERM al proceso apropiado. En el siguiente ejemplo, el usuario maxwell está ejecutando el navegador de red Mozilla y el reloj gráfico xclock. Utiliza el comando pgrep para localizar sus ID de procesos, mata el primero mediante el comando kill y el segundo mediante el comando pkill. [maxwell@station maxwell]$ pgrep -lu maxwell 2112 bash 2146 mozilla-bin 2155 mozilla-bin 2156 mozilla-bin 2157 mozilla-bin 2329 mozilla-bin 2597 xclock [maxwell@station maxwell]$ kill 2146 [maxwell@station maxwell]$ pkill xclock [1]- Exit 15 mozilla
  37. 37. 37 Managing Processes [2]+ Terminated xclock [maxwell@station maxwell]$ pgrep -lu maxwell 2112 bash Pero, ¡espere! Hay una forma diferente para terminar aplicaciones gráficas aparte del envío de señales. Solamente haga click en la casilla "cerrar" en la esquina superior derecha o seleccione Cerrar en menú desplegable en la esquina superior izquierda. Entre bastidores, esta es precisamente la labor de estas acciones: entregar una señal SIGTERM a una aplicación adjunta. Uso de señales para matar procesos Cada vez que sea posible la señal SIGTERM debería utilizarse para terminar procesos. Sin embargo, algunas veces, los procesos están "encerrados" y completamente insensibles, incluso para las señales SIGTERM. En estos casos, la señal SIGKILL (número de señal 9) puede utilizarse como un último recurso. La señal SIGKILL mata un proceso en el kernel sin ninguna interacción con el proceso mismo. A continuación, maxwell intenta terminar una simulación física (el proceso sim) con la señal por defecto SIGTERM. Por alguna razón, el proceso es insensible por lo tanto maxwell lo mata con la señal SIGKILL. [maxwell@station 2112 bash 4489 sim [maxwell@station [maxwell@station 2112 bash 4489 sim [maxwell@station [1]+ Killed [maxwell@station 2112 bash maxwell]$ pgrep -lu maxwell maxwell]$ pkill sim maxwell]$ pgrep -lu maxwell maxwell]$ pkill -KILL sim sim maxwell]$ pgrep -lu maxwell ¡Hágalo que pare! La combinación de la habilidad de pkill para seleccionar todos los procesos pertenecientes a un usuario particular, y la señal SIGKILL de bajo nivel letal, conforman una técnica conveniente para que un usuario mate todos los procesos que puedan estar ejecutándose en la máquina local. A continuación, maxwell observa primero cuántos procesos está ejecutando en la máquina local. Luego mata todos los procesos. [maxwell@station maxwell]$ pgrep -u maxwell | wc -l 22 [maxwell@station maxwell]$ pkill -KILL -u maxwell Como resultado, maxwell se saca de la máquina (matando su propia sesión X o inicio de sesión de consola virtual) y debe iniciar sesión otra vez.
  38. 38. 38 Managing Processes Ejercicios en línea Lab Exercise Objetivo: Terminar la ejecución de procesos de manera efectiva. Estimated Time: 10 mins. Especificaciones 1. Crear un script corto de shell llamado ~/bin/kill_all_cats y hacerlo ejecutable. Cuando se ejecute, el guión debería matar todos los procesos cat en ejecución. 2. En una terminal, iniciar un proceso cat mediante la siguiente línea de comandos. Deje el proceso en ejecución mientras califica su ejercicio (pero no se sorprenda si no está en ejecución cuando termine). 3. [student@station student]$ cat /dev/zero > /dev/null Deliverables Question 1 1. Un script de shell llamado ~/bin/kill_all_cats que al ejecutarse, entregue una señal SIGTERM a todas las instancias actuales en ejecución del comando cat. 2. Un proceso cat en ejecución. Capítulo 5 Control de trabajo Conceptos clave • • • • • • La shell bash permite a los comandos ejecutarse en segundo plano como "trabajos". La shell bash permite a un trabajo ejecutarse en segundo plano y puede tener múltiples trabajos en segundo plano. El comando jobs listará todos los trabajos en segundo plano. La secuencia de teclas CONTROL-Z suspenderá y enviará a segundo plano el actual trabajo que se encuentra en primer plano. El comando bg reanuda un trabajo de segundo plano. El comando fg trae un trabajo de segundo plano a primer plano.
  39. 39. 39 Managing Processes Los temas tratados en este cuaderno hasta el momento, es decir la información sobre listado de procesos, el cambio de un valor niceness de un proceso y el envío de señales a procesos son características compartidas por todos los procesos, ya sean iniciados desde una línea de comandos de shell o de otro modo. A diferencia de estos temas anteriores, el tema que nos resta, control de trabajo tiene que ver el manejo de procesos iniciados desde un intérprete de comandos de una shell interactiva y se enfocará en la shell bash. Ejecución de comandos en el primer plano Cuando se ejecuta un comando desde un intérprete de comandos shell bash, a no ser que usted especifique lo contrario, el comando se ejecuta en el primer plano. La shell bash espera que el comando de primer plano termine antes de expedir otro intérprete de comandos y cualquier cosa escrita con el teclado se lee generalmente como la stdin para este comando. Todo esto debería sonar familiar porque los comandos utilizados hasta el momento se han ejecutado en el primer plano. Ejecución de comandos en segundo plano como trabajos En contraste, cualquier comando que usted especifique puede también ejecutarse en el segundo plano, adjuntándole el signo (“&”) a la línea de comandos. Por lo general, sólo los comandos de larga ejecución que no requieren entradas desde el teclado y no generan grandes cantidades de salida son apropiados para un segundo plano. Cuando la shell bash envía a segundo plano un comando, el comando se conoce como un trabajo y se le asigna un número de trabajo. En el siguiente ejemplo, einstein está realizando una búsqueda de los archivos que mayores de 1 megabyte en tamaño en su sistema de archivos. Dado que espera este comando para ejecutar por un tiempo, dirige la stdout a un archivo, bota la stderr y la ejecuta como un trabajo de segundo plano. [einstein@station einstein]$ find / -size +1024k > bigfiles.txt 2> /dev/null & [1] 7022 Después de iniciar el trabajo en el segundo plano, la shell bash reporta dos partes de información a einstein. La primera es el número de trabajo reportado entre paréntesis cuadrados. La segunda es el ID del proceso del trabajo de segundo plano. En este caso, el trabajo es el número de trabajo 1 y el ID del proceso del comando find es 7022. Mientras que este comando se ejecuta en el segundo plano, einstein decide buscar los archivos que le pertenecen y que no ha modificado en dos semanas. Escribe el comando apropiado find y de nuevo envía a segundo plano el trabajo. [einstein@station einstein]$ find / -user einstein -and -mtime +14 oldfiles.txt 2> /dev/null & [2] 7023 [1] Exit 1 find / -size +1M >bigfiles.txt 2>/dev/null >
  40. 40. 40 Managing Processes De nuevo, bash reporta el número de trabajo (2) y el ID del proceso del segundo comando find (7023). El segundo mensaje de shell bash está notificando a einstein el número de trabajo que se ha terminado. La shell bash reporta que ésta ha salido con un código de retorno de 1 (opuesto a ser matado por una señal) y revisualiza la línea de comando para recordar a einstein lo que ha ejecutado. La shell bash no reporta inmediátamente la muerte de los trabajos, sino espera hasta la próxima vez que interprete una línea de comandos. Cuando einstein ha digerido todo esto sospecha que su segundo trabajo también ha terminado. Simplemente, pulsa la tecla ENTER (para que bash "interpretará" la línea de comandos vacía). Igualmente, la shell bash reporta su nuevo número de trabajo 2. [einstein@station einstein]$ [2]+ Exit 1 >oldfiles.tx t 2>/dev/null find / -user einstein -and -mtime +14 Administración de múltiples trabajos El usuario einstein, al igual que maxwell, suele realizar cálculos físicos que toman mucho tiempo para ejecutar. Inicia varias versiones de la simulación enviándolas al segundo plano. [einstein@station bin sim_a sim_b [einstein@station [1] 7309 [einstein@station [2] 7311 [einstein@station [3] 7313 [einstein@station [4] 7315 einstein]$ ls sim_c sim_d einstein]$ ./sim_a & einstein]$ ./sim_b & einstein]$ ./sim_c & einstein]$ ./sim_d & Listado de trabajos actuales con jobs El usuario einstein puede utilizar el comando incorporado jobs para reportar todos sus trabajos en ejecución. [einstein@station einstein]$ jobs [1] Running ./sim_a [2] Running ./sim_b [3]- Running ./sim_c [4]+ Running ./sim_d & & & & Cada uno de sus trabajos de segundo plano son listados junto con el número de trabajo. El trabajo más reciente se conoce como el trabajo actual y es representado por el comando jobs con un “+”. Traer un trabajo al primer plano con fg
  41. 41. 41 Managing Processes Un trabajo de segundo plano puede traerse al primer plano con el comando incorporado fg. El comando fg espera un número de trabajo como un argumento o si ninguno es provisto pondrá el trabajo actual en primer plano. [einstein@station einstein]$ fg 3 ./sim_c Ahora, el trabajo sim_c está ejecutándose en el primer plano. Como consecuencia, la shell no generará ningún intérprete de comandos cuando el proceso esté en ejecución. Suspensión del trabajo de primer plano con CONTROLZ Previamente, se introdujo la secuencia CONTROL-Z como un método para suspender procesos. Ahora, al observar de cerca la salida de la shell bash cuando einstein suspende el comando de primer plano, vemos que la shell bash trata como un trabajo a cualquier proceso de primer plano suspendido. [einstein@station einstein]$ fg 3 ./sim_c CTRL-Z [3]+ Stopped ./sim_c [einstein@station einstein]$ jobs [1] Running ./sim_a & [2] Running ./sim_b & [3]+ Stopped ./sim_c [4]- Running ./sim_d & [einstein@station einstein]$ ps u USER PID %CPU %MEM VSZ RSS TTY einstein 6987 0.0 0.3 4316 976 pts/8 einstein 7309 0.0 0.3 4112 1004 pts/8 /bin/bash ./sim_a einstein 7311 0.0 0.3 4112 1004 pts/8 /bin/bash ./sim_b einstein 7313 0.0 0.3 4112 1004 pts/8 /bin/bash ./sim_c einstein 7315 0.0 0.3 4112 1000 pts/8 /bin/bash ./sim_d einstein 7446 0.0 0.2 2616 660 pts/8 STAT START S 15:56 S 16:20 TIME COMMAND 0:00 -bash 0:00 S 16:20 0:00 T 16:20 0:00 S 16:20 0:00 R 16:34 0:00 ps u Cuando está suspendido (o para utilizar la terminología de shell, detenido), el proceso recibe el número de trabajo (si es que aún no lo tiene) y se envía al segundo plano. El comando jobs reporta el trabajo como un trabajo "detenido" y el comando ps confirma que está detenido. Reiniciar un trabajo detenido en el segundo plano Un trabajo detenido puede reiniciarse en el segundo plano con el comando incorporado bg. Al igual que el comando fg, el comando bg espera un número de trabajo como un argumento o si no se provee ninguno entonces se utiliza el trabajo actual.
  42. 42. 42 Managing Processes A continuación, einstein reinicia su trabajo detenido en el segundo plano. [einstein@station einstein]$ bg 3 [3]+ ./sim_c & [einstein@station einstein]$ jobs [1] Running ./sim_a [2] Running ./sim_b [3]- Running ./sim_c [4]+ Running ./sim_d & & & & Ahora el número de trabajo 3 está otra vez en estado de ejecución. Matar trabajos El comando kill, utilizado para entregar señales para procesos se implementa como un comando incorporado de shell, (confusamente, también se encuentra otra versión en el sistema de archivos /bin/kill. Probablemente usted está utilizando la versión de shell incorporada). Como resultado, está consciente de los trabajos que la shell está administrando. Cuando se especifica qué proceso debería recibir una señal, el número de trabajo del proceso (si lo hay) puede especificarse en vez de su ID de proceso. Para distinguir los dos, los números de trabajo están precedidos por un caracter de porcentaje (“%”) como se ilustra en el siguiente ejemplo. [einstein@station einstein]$ [1] Running [2] Running [3]- Running [4]+ Running [einstein@station einstein]$ -bash: kill: (2) - Operation [einstein@station einstein]$ [einstein@station einstein]$ [2] Terminated [einstein@station einstein]$ [1] Running [3]- Running [4]+ Running jobs ./sim_a & ./sim_b & ./sim_c & ./sim_d & kill 2 not permitted kill %2 ./sim_b jobs ./sim_a & ./sim_c & ./sim_d & Aquí einstein erróneamente utilizó la sintaxis para especificar un ID de proceso, en vez del número de trabajo. Puesto que él no posee su propio proceso con el ID de proceso número 2, el comando falla. Aquí, einstein utilizó la sintaxis correcta para especificar un número de trabajo y la señal fue enviada al proceso sim_b. Resumen El siguiente cuadro resume los comandos y técnicas para administrar trabajos dentro de la shell bash.
  43. 43. 43 Managing Processes Table 1. Administración de trabajos en la shell bash Comando Acción trabajos Lista todos los trabajos fg [N] Trae el trabajo N de segundo plano al primer plano (por defecto, el trabajo de segundo plano "actual"). CTRL-Z Suspende y envía al segundo plano el actual comando de primer plano bg [N] Inicia el trabajo de segundo plano detenido N (por defecto, el trabajo "actual"en segundo plano). kill %N Termina el trabajo de segundo plano N (enviando la señal SIGTERM). Ejemplos Decidir enviar a segundo plano un comando ejecutándose en el primer plano La discusión mencionó que los comandos se pueden iniciar en el segundo plano, agregando un signo “&” a la línea de comandos. A continuación, einstein inicia un comando en el primer plano y luego, dándose cuenta que le tomaría mucho tiempo completar, deseá haberlo iniciado en el segundo plano. [einstein@station einstein]$ ./sim_a Con el fin de enviar al segundo plano el comando, primero lo suspende con la secuencia de control CONTROL-Z, la cual lo abandona como un trabajo de segundo plano detenido. Luego reinicia el trabajo en el segundo plano mediante bg. [einstein@station einstein]$ ./sim_a CTRL-Z [1]+ Stopped ./sim_a [einstein@station einstein]$ bg [1]+ ./sim_a & [einstein@station einstein]$ Uso de CONTROLC para matar un trabajo en segundo plano. Como una alternativa para el comando kill, la siguiente técnica se utiliza para cancelar trabajos enviados al segundo plano. Primero, se trae el trabajo al primer plano con el comando y luego se mata con la secuencia CONTROL-C. [einstein@station einstein]$ jobs [1] Running ./sim_a & [2]- Running ./sim_b & [3]+ Running ./sim_c & [einstein@station einstein]$ fg 2 ./sim_b CTRL-C
  44. 44. 44 Managing Processes [einstein@station einstein]$ jobs [1]- Running ./sim_a & [3]+ Running ./sim_c & Ejercicios en línea Lab Exercise Objetivo: Uso del control de trabajo bash para administrar trabajos múltiples. Estimated Time: 10 mins. Especificaciones 1. Inicie los siguientes cuatro comandos, colocando a cada uno en el segundo plano. 2. 3. 4. 5. ls -R / | grep "*.conf" > lsconf 2>/dev/null cat /dev/zero > /dev/null find / -name "[Aa]*[Cc]*[Ff]*" sleep 100000 6. Mediante los comandos de control de trabajos y las secuencias comunes de control, parar (suspender) los trabajos ls y find. Deliverables Question 1 1. Cuatro trabajos enviados al segundo plano administrados por la shell bash. Los trabajos cat y sleep deberían estar ejecutándose, mientras que los trabajos find y ls deberían suspenderse. Limpieza Después de haber calificado su ejercicio, utilice el comando kill (o la combinación fg/ CONTROL-C) para matar todos los cuatro trabajos. Capítulo 6 Programación de tareas retrasadas: at Conceptos clave • El comando at puede someter comandos para que se ejecuten más tarde.
  45. 45. 45 Managing Processes • • • • El comando batch puede emitir comandos para que se ejecuten cuando la carga de las máquinas sea baja. Los comandos pueden escribirse directamente o someterse como un script. la stdout de los trabajos at se envía por correo al usuario. Los comandos atq y atrm se utilizan para examinar y quitar trabajos actualmente programados. Demonios Antes de abordar el comando at directamente comenzamos con una corta discusión de un concepto común en Unix: los demonios. Con un nombre inspirado por Daemon del físico Maxwell, los demonios Unix son procesos que se ejecutan en el segundo plano, separados de una terminal, realizan tareas que no suelen estar relacionadas con el teclado de un usuario. Los demonios suelen asociarse con servicios de red tales como el servidor de red (httpd) o el servidor FTP (vsftpd). Otros demonios administran tareas del sistema tal como el demonio de inicio de sesión (syslogd) y el demonio administrador de potencia (apmd). Esta y la siguiente lección describirán dos demonios que permiten a los usuarios retrasar tareas (atd), o ejecutar comandos en intervalos fijos (crond). Hasta el momento, usted habrá notado una convención para nombres: los programas diseñados para ejecutarse como demonios suelen terminar con la letra d. Los demonios son procesos como cualquier otro proceso. Suelen iniciar como parte de la secuencia de un sistema de arranque o por el usuario root, por lo tanto, usted nunca sabría que están ahí a menos que los busque. [elvis@station elvis]$ ps aux | root 890 0.0 0.0 1572 elvis 5035 0.0 0.2 3572 crond [elvis@station elvis]$ ps aux | daemon 4730 0.0 0.2 1420 /usr/sbin/atd elvis 5037 0.0 0.2 3572 atd grep crond 132 ? 640 pts/4 S S 09:57 16:17 0:00 crond 0:00 grep grep atd 532 ? S 15:42 0:00 640 pts/4 S 16:17 0:00 grep Algunos demonios se ejecutan como el usuario root, mientras otros adquieren la identidad de otro usuario de sistema por asuntos de seguridad. Arriba, el demonio crond se está ejecutando como root pero el demonio atd está ejecutándose como el demonio de usuario. El demonio atd El demonio atd le permite a los usuarios someter trabajos para ser realizados más tarde, tal como a las "at 2:00am". Para utilizar el demonio atd, éste debe estar ejecutándose.
  46. 46. 46 Managing Processes Los usuarios pueden confirmar que atd se está ejecutando simplemente al examinar la lista de procesos en ejecución: [madonna@station madonna]$ ps aux | grep atd daemon 4730 0.0 0.2 1420 532 ? S /usr/sbin/atd madonna 5570 0.0 0.2 3572 640 pts/2 S atd 15:42 0:00 16:43 0:00 grep Observe que la séptima columna especifica con qué terminal se asocia un proceso. Para el comando grep de blondie, la terminal es pts/2, la cual probablemente se refiere a una shell de red o a una terminal gráfica dentro de una sesión X. Observe que el demonio atd no tiene terminal asociada. Una de las características de un demonio es que quita su asociación con la terminal que la inició. Envío de trabajos con at El comando at se utiliza para someter trabajos al demonio atd para que se ejecuten en una hora específica. Los comandos que se van a ejecutar son sometidos ya sea como script (con la opción -f) o escritos directamente via la stdin. La salida estándar del comando se envía por correo al usuario. at [[-f filename] | [-m]] TIME Opción Efecto -f filename ejecuta el script especificado por el nombre de archivo -m Notifica al usuario por correo electrónico cuando se ejecuta, incluso si no hay salida. La hora del día se puede especificar utilizando HH:MM, con el sufijo "am" o "pm". Los términos en inglés "midnight", "noon", y "teatime" también pueden utilizarse. Igualmente, mediante varios formatos incluyendo MM/DD/YY. (mes/día/año/). Para mayor información refiérase a la página del manual at(1). El luchador hogan desearía imprimir un archivo con todo el correo que ha recibido de sus admiradores, fanmail.txt. Está un poco preocupado porque comparte la impresora con ventura, quien también utiliza mucho la impresora. Como quiere evitar peleas, decide demorar su trabajo de impresión hasta las 2:00 de la mañana. [hogan@station hogan]$ at 2:00 am warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh at> lpr fanmail.txt at> CTRL-D job 7 at 2003-06-17 02:00
  47. 47. 47 Managing Processes Dado que hogan no utilizó la opción -f, el comando at le pidió teclear sus comandos mediante la stdin (el teclado). Afortunadamente, hogan sabía que cuando la secuencia CONTROL-D, se escribe directamente desde una terminal indica un "fin de archivo". Como alternativa pudo haber entubado el comando dentro de la stadin directamente: [hogan@station hogan]$ echo "lpr fanmail" | at 2:00 am warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh job 7 at 2003-06-17 02:00 Luego, hogan confirma que su trabajo se ha registrado con atq. [hogan@station hogan]$ atq 7 2003-06-17 02:00 a hogan Por último, hogan recuerda que ventura está en vacaciones por lo tanto puede imprimir la correspondencia de sus admiradores sin ningún problema. Decide cancelar su trabajo at e imprimir el archivo directamente. [hogan@station hogan]$ atrm 7 [hogan@station hogan]$ atq [hogan@station hogan]$ lpr fanmail.txt Retraso de tareas con batch El comando batch, al igual que el comando at, se utiliza para retrasar tareas. A diferencia del comando at, batch no ejecuta el comando at en un tiempo específico, sino que espera hasta que el sistema se desocupe de otras tareas a cualquier hora. Si la máquina no está ocupada cuando se somete un trabajo, el trabajo podría ejecutarse inmediatamente. El demonio atd controla el loadavg (promedio de carga) del sistema y espera que baje por debajo de 0.8 antes de ejecutar el trabajo. El comando batch tiene una sintaxis idéntica al comando at, donde los trabajos pueden ser especificados con la stadin o sometidos como un lote con la opción -f. Si la hora se especifica, el batch se demorará observando la máquina hasta el tiempo especificado. En ese momento batch comenzará a controlar el loadavg del sistema, y ejecutará el trabajo cuando el sistema no esté de otra manera ocupado. Resumen de los comandos at El siguiente cuadro resume el comando utilizado al registrar trabajos con el demonio atd. Table 1. Comandos relacionados con el servicio at
  48. 48. 48 Managing Processes command uso atd El demonio que ejecuta trabajos sometidos. Los usuarios no utilizan el comando atd directamente. at Somete trabajos al demonio atd para que se ejecuten en un tiempo específico. batch Somete trabajos al demonio atd para que se ejecuten cuando el sistema no esté ocupado. atq Lista trabajos en espera con el demonio atd. atrm Cancela un trabajo en espera con el demonio atd antes de ejecutarse. Ejemplos Someter un trabajo at como un archivo El usuario hogan ha desarrollado ahora el hábito de imprimir su correspondencia de sus admiradores a las 2:00 de la mañana. También ha descubierto el comando enscript, el cual reformatea archivos de texto imprimiéndolos "2up" (dos páginas de texto impresas por páginas) y representa la página impresa con encabezados informativos y pies de página. Después de una corta experiencia desarrolla la siguiente opción para formatear la página a su gusto: enscript -r2 -G --header="Fan Mail" --borders fanmail.txt. Dado que hogan no quiere teclear este comando y todas las opciones a cada rato, crea un guión corto con el (o los) comando(s) que desearía ejecutar en un archivo llamado fanmail.at: [hogan@station hogan]$ cat fanmail.at enscript -r2 -G --header="Fan Mail" --borders fanmail.txt Ahora, cuando hogan quiere someter a impresión su correspondencia de la fanaticada puede simplemente especificar el script a at con la opción -f. [hogan@station hogan]$ at -f fanmail.at 2:00 am warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh job 11 at 2003-06-18 02:00 [hogan@station hogan]$ atq 11 2003-06-18 02:00 a hogan Examen de la sintaxis Spool El usuario ventura ha notado que hogan tiene la costumbre de imprimir la correspondencia de sus admiradores a las 2:00 am y como un chiste práctico decide someter un trabajo de su propiedad. Crea el archivo bogus_fanmail.txt, que falsifica correspondencia no muy elogiosa de sus fanáticos. Somete un trabajo que imprimirá el archivo a la 1:59 am confiando que hogan no notará la inserción cuando recoja los papeles de la impresora en la mañana.

×