Está en la página 1de 59

1

Managing Processes Captulo 1 Introduccin a Procesos Conceptos clave


Un proceso es una instancia de un ejecutable en ejecucin 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 coleccin de gid como credenciales. Un proceso tiene un contexto de sistema de archivos incluyendo un cwd, una umask, un directorio raz y una coleccin de archivos abiertos. Un proceso tiene un contexto de programacin que incluye un valor de niceness. Un proceso tiene una coleccin de variables de entorno. El comando ps puede utilizarse para examinar todos los procesos actuales en ejecucin. El comando top puede utilizarse para controlar todos los procesos en ejecucin.

Los procesos tienen que ver con el cmo 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 lnea 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 cmo 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 grficas que se toman una gran cantidad de tiempo para iniciar. En el mundo de Linux (y Unix), estos tipos de programas tambin existen, al igual que toda una clase de programas que usualmente no tienen una contraparte en los sistemas operativos. Estos programas estn diseados para iniciar rpidamente, especializados en funciones y trabajan bien con otros programas. En un sistema de Linux, los procesos que ejecutan estos programas estn constantemente apareciendo y desapareciendo. Por ejemplo, considere que el usuario maxwell escribe la siguiente lnea de comandos.
[maxwell@station maxwell]$ ps aux | grep httpd > daemons.$(date +%d%b%y)

En una fraccin de segundo que la lnea de comandos utiliz para ejecutar, no menos de cuatro procesos (ps, grep, bash y date) se iniciaron, hicieron lo que tenan que hacer y salieron. Qu es un proceso?

Managing Processes En este momento ya estar cansado de escuchar la misma pregunta: un proceso en una instancia de un programa en ejecucin. No obstante, aqu ofrecemos una lista detallada de componentes que constituyen un proceso. Contexto de ejecucin Cada proceso existe (al menos hasta cierto punto) dentro de una memoria fsica de la mquina. Puesto que Linux (y Unix) estn diseados para ser un entorno multiusuario, la memoria asignada a un proceso est protegida y ningn otro proceso puede acceder a sta. Un proceso carga en su memoria una copia de las instrucciones ejecutables y almacena cualquier otra informacin dinmica que est manejando. Un proceso tambin lleva parmetros asociados con la frecuencia de acceso que se tiene a la CPU, tales como su estado de ejecucin y su valor de niceness (pronto hablaremos ms en detalle sobre esto). Contexto de E/S Cada proceso interacta hasta cierto punto con el sistema de archivos para leer y escribir informacin que existe o existir despus 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 informacin de o escribir informacin a fuentes externas. En Linux, los descriptores de archivos abiertos actan como fuentes o receptores de informacin. Los procesos leen informacin de o escriben informacin a los descriptores de archivos abiertos que pueden estar conectados a archivos regulares, nodos de dispositivos, conexiones de red o incluso entre s como tuberas (permitiendo la comunicacin 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 slo accede a la direccin de memoria apropiada. Los mapas de memoria suelen utilizarse para cargar el cdigo ejecutable, pero tambin sirven para otros tipos de acceso no secuencial a los datos. Contexto del sistema de archivos Hemos encontrado varias partes de informacin 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 recin creados). [1] Variables de entorno

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. Informacin de herencia Cada proceso se identifica con un PID o id del proceso asignado en el momento de su creacin. En una prxima leccin, veremos que cada proceso tiene claramente definido un padre y posiblemente unos hijos tambin. 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 ms exactamente de un id de usuario determinado) y bajo el contexto de una coleccin 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. Estadsticas de recursos y lmites Cada proceso tambin registra estadsticas para trazar la cantidad de recursos del sistema utilizados, el nmero de archivos abiertos, la cantidad de tiempo de CPU, etc. La cantidad de recursos que se le permite utilizar a un proceso tambin puede limitarse con un concepto llamado lmite de recursos. Ver procesos con el comando ps Ya hemos visto varias veces el comando ps. Ahora, trataremos de familiarizarnos con una seleccin ms amplia de opciones asociadas a ste. Una ejecucin rpida de ps -help mostrar un resumen de ms 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 versin de Linux del comando ps trata de acomodarse a diferentes versiones anteriores de Unix y suele haber opciones mltiples para cualquier opcin determinada, algunas de las cuales comienzan con un guin inicial (-). Seleccin 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 estn conectados a cajas de UNIX con terminales seriales de lnea, parece un poco simplista cuando cada ventana de una terminal dentro de un entorno grfico X se trata como una

Managing Processes terminal independiente. Los siguientes modificadores de lnea de comandos pueden utilizarse para expandir (o reducir) los procesos listados por el comando ps . Table 1. Opciones comunes del comando ps para la seleccin de procesos Opcin -A, -e, ax -C command -t, --tty terminal -p, p, --pid N Seleccin de salida Como se deduce de los prrafos iniciales de esta leccin hay muchos parmetros asociados con procesos, demasiados para mostrar en una anchura estndar de terminal de 80 columnas. El siguiente cuadro lista las opciones de lnea de comando comunes que se utilizan para seleccionar qu aspectos de un proceso se listan. Table 1. Opciones comunes del comando ps para la seleccin de salida Opcin -f -l, l -j, j listado "completo" formato largo formato de trabajos Formato de la salida Procesos listados Todos los procesos. Todas las instancias de command Todos los procesos iniciados desde terminal Procesos con pid N

-U, --user, --User user Todos los procesos que pertenecen a user

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 pgina de manual ps(1)). Adems, las siguientes opciones pueden utilizarse para modificar la forma de presentar la informacin. Table 2. Opciones comunes del comando ps para dar formato a la salida Opcin Formato de la salida -H Muestra la jerarqua del proceso f, --forest Muestra la jerarqua de proceso incluyendo las representaciones ASCII h -w No imprime las lneas del encabezado salida "ancha" (incluye nombres de los comandos ms largos)

Managing Processes Rarezas del comando ps El comando ps, posiblemente ms que cualquier otro comando en Linux, tiene sus rarezas asociadas con sus opciones. En la prctica, los usuarios tienden a experimentar hasta encontrar combinaciones que les funcionen y luego se habitan a ellas. Por ejemplo, el autor prefiere el comando ps aux para propsitos generales de todos los procesos, mientras que otros preferiran el comando ps -ef. El cuadro anterior ofrece una "ayuda de trabajo" bastante buena para el principiante. Las opciones de lnea de comandos tienden a clasificarse en dos categoras, aquellas con el tradicional guin 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, slo 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 estadsticas para procesos especificados en el momento que se ejecuta el comando, proporcionando una instantnea de una instancia en tiempo. En contraste, el comando top sirve para controlar el estado general de los asuntos de procesos en la mquina. Se espera que el comando top se ejecute desde dentro de una terminal. ste remplazar la lnea de comandos por una tabla de los actuales procesos en ejecucin, el cual se actualiza a cada instante. A continuacin se muestra la pantalla de un usuario despus 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 0 0 SIZE RSS SHARE STAT %CPU %MEM 2252 S 1436 S 2.9 0.9 0.9 0.9 0.0 0.0 0.0 1.6 0.8 7.5 0.4 0.0 0.0 0.0 TIME CPU 0:51 0:04 0:06 0:00 0:04 0:00 0:00 0 0 0 0 top 0 init 0 0

95.4%

4468 4108 3132 2112

0 19596 0 0 0 0

18M 12356 S 856 R 52 S 0 SW 0 SW

1088 1088 108 76 0 0 0 0

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 25 15 15 15 15 15 25 15 19 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SWN 0 SW 0 SW 0 SW 0 SW 0 SW 0 SW 0 SW 0 SW 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0:00 0:00 0:00 0:00 0:06 0:00 0:00 0:00 0:01 0 0 0 0 0 0 0 0 0

Mientras el comando est ejecutndose, 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 ms utilizadas. Table 1. Comandos top ms utilizados Presionar tecla q ho? s space M P u k r quit ayuda establecer el retraso entre las actualizaciones (en segundos) mostrar actualizacin Clasificar procesos por tamao de memoria Clasificar procesos por actividad de la CPU (procesador) Reducir procesos visualizados pertenecientes a un usuario especfico Matar un proceso (enviar una seal a un proceso) renice un proceso Comando

Los ltimos dos comandos, los cuales pueden matar o renice un proceso utilizan conceptos que cubriremos con ms detalle en una prxima leccin. Aunque por lo general top funciona sin la configuracin de lnea de comandos es compatible con las siguientes opciones: Table 2. Opciones para el comando top Opcin -d Efecto Demora segundos segundos entre actualizaciones (por defecto = 5

Managing Processes Opcin


segundos

Efecto segundos). Actualiza tan pronto como sea posible. Se ejecuta para iteraciones N, luego sale. Se ejecuta en "modo por lote" simplemente como si escribiera a una terminal tonta.

-q -n N -b

Procesos de control con la aplicacin gnome-system-monitor Si se ejecuta un servidor X, el entorno de escritorio de GNOME proporciona una aplicacin similar en funcin a top con los beneficios (y problemas) de una aplicacin grfica. La aplicacin se puede iniciar desde una lnea 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 aplicacin Monitor del sistema presenta una lista de procesos ejecutndose en la mquina local, actualizando la lista cada pocos segundos. En su configuracin por defecto, la aplicacin Monitor del sistema provee una interfaz mucho ms simple: lista slo los procesos pertenecientes al usuario que inici la aplicacin y reduce el nmero de columnas a la memoria del comando del proceso, el propietario, ID de proceso, las medidas simples de la memoria del proceso y la utilizacin de la CPU. Los procesos pueden clasificarse por cualquiera de estos campos con un slo clic en el ttulo 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 slo los procesos en el estado de "ejecucin". 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 travs de una interfaz ms 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 seleccinEditor:Preferencias. Dentro del dilogo de Preferencias, el usuario puede establecer el intervalo de actualizacin (en segundos) y configurar muchos ms campos para ser visualizados. Figure 3. Campos de configuracin en el monitor de sistema GNOME

Managing Processes Por ltimo, el Monitor de Sistema provee un segundo panel, el cual muestra grficas 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

Localizacin de procesos con el comando pgrep. A menudo, los usuarios tratan de localizar informacin acerca de procesos identificados por el comando que estn ejecutando o el usuario que est ejecutndolos. Una tcnica es listar todos los procesos y utilizar el comando grep para reducir la informacin. A continuacin, 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 10:10 0:00 0:00 grep

10:05 10:05 10:05 10:10 10:10

0:00 su 0:00 -bash 0:04 0:00 ps aux 0:00 grep

Aunque maxwell puede encontrar la informacin que necesita hay algunos aspectos no muy agradables. 1. El mtodo no es exacto. Observe que, en la segunda bsqueda, 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 rpidamente procesos por nombre de comando, usuario, terminal o grupo.
pgrep

[OPCIONES] [PATRN]

Su argumento opcional, si se suministra, se interpreta como un patrn de expresin regular extendido coincidente con nombres de comando. Las siguientes opciones tambin pueden utilizarse para clasificar la bsqueda.

Managing Processes Table 1. Opciones comunes para especificar el criterio de seleccin del proceso pgrep. Opcin Efecto -n Selecciona nicamente los procesos coincidentes iniciados ms recientemente. -u USER Selecciona procesos pertenecientes al usuario USER. -t TERM Selecciona procesos controlados por terminal TERM. Adems, la siguiente opcin puede utilizarse para modificar el formato de la salida del comando. Table 2. Opciones comunes para especificar el formato de salida pgrep Opcin -d
delimitador

Efecto Usa delimitador para delimitar cada ID de proceso (por defecto se utiliza una nueva lnea). Lista el nombre del proceso y el ID del proceso.

-l

Para una lista completa de opciones consulte la pgina 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 transcripcin, 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 SW Oct12 TIME COMMAND 0:04 init [ 0:00 0:00 [kapmd]

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 0.1 0.0 0.0 0.0 0 1356 2104 1448 1376 1548 0 ? 4 tty2 448 ? 160 ? 164 ? 104 ? SW S S S S S S S S S S S S S S Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 Oct12 0:00 0:00 0:00 0:00 syslogd 0:00 klogd 0:00 portmap 0:02 0:00 0:00 eggcups 0:00 pam0:41 0:00 0:00 15:28 gnome0:00

1.3 57948 3400 ? 0.1 16392 436 ?

0.5 16784 1500 ? 0.3 11596 988 ?

0.8 24464 2152 ? 0.0 1416 136 ?

0.3 17024 1012 ? 1.4 18356 3760 ? 0.6 18424 1776 ?

0.5 0.2

4304 1392 pts/5 2696 744 pts/5

S R

07:35 07:35

0:00 -bash 0:00 ps -e u

El "usuario orientado"muestra el usuario que est ejecutando el proceso, el id de proceso y una estimacin aproximada de la cantidad de CPU y memoria que el proceso est consumiendo como tambin el estado del proceso. (los estados de procesos se tratarn en una prxima leccin). Ver los procesos de un usuario con el formato "largo" En la siguiente transcripcin, 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 S S S S ? ? ? ? TIME 0:02 0:00 0:00 0:00

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 15 15 15 15 15 15 15 15 15 15 15 15 25 20 0 17336 0 3728 4 schedu S 620 schedu S ? ? ? ? ? ? ? ? ? ? ? ? pts/5 ? pts/5 0:00 0:00 0:08 0:05 0:02 0:00 0:00 0:00 0:43 0:00 0:00 15:43 0:00 0:00 0:00 ps

0 12816 1884 schedu S 0 21160 3340 schedu S 0 57948 3192 schedu S 0 16392 424 schedu S

0 16784 1348 schedu S 0 11596 908 schedu S

0 24464 2152 schedu S 0 1416 136 schedu S 756 schedu S

0 17024

0 18356 3760 schedu S 0 10 0 4304 1388 wait4 S

6676 2592 schedu SN 3140 1188 R

El formato largo se enfoca en parmetros de programacin, tales como la prioridad y el niceness del proceso, los cuales se tratarn ms adelante. Ver un comando determinado con el formato "trabajo orientado" En la siguiente transcripcin, 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 sesin y terminales de control. Muchos de estos conceptos se discutirn ms tarde en otros cuadernos.

12

Managing Processes Intrigado porque el proceso padre de muchas de estas shells parece ser el proceso ID 1184, maxwell contina 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 opcin -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 nmeros, maxwell utiliza el comando grep para reducir su salida a lneas que comienzan con cualquier nmero o espacio pero cuyo primer caracter de no espacio sea un dgito.
[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

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 lnea Lab Exercise Objetivo: Ver la informacin sobre los procesos Tiempo estimado: 20 minutos. Especificaciones Con el fin de tener un conjunto fijo de procesos para examinar, usted debe tomar una instantnea de todos los procesos actuales en su mquina. 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 tamao de la memoria virtual de cada proceso. La lista clasificada de procesos se agregar luego al encabezado previamente capturado en el archivo snapshot. Es ms fcil 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 tamao 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 ejecucin o dormido. Grabe esta columna extrada (a excepcin del encabezado) dentro de un archivo llamado ~/pstates.txt. 3. Utilice el comando grep, quizs con el comando wc para determinar el nmero de instancias en ejecucin del programa /sbin/mingetty. Almacene la pregunta como un slo nmero en el archivo ~/nmingetty.txt.

14

Managing Processes 4. Utilice el comando grep, quizs con el comando wc, para determinar la cantidad de procesos en ejecucin como usuario root. Almacene la respuesta como un slo nmero en el archivo ~/nroot.txt. 5. Inicie el comando top en una terminal y djelo 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 ms grande. 2. El archivo ~/pstates.txt que contiene la columna extrada de los estados de proceso, a excepcin de la lnea de encabezado. 3. El archivo ~/nmingetty.txt que contiene el nmero de instancias del programa /sbin/mingetty ejecutndose en su mquina. 4. El archivo ~/nroot.txt que contiene el nmero de procesos ejecutndose como el usuario root de la mquina. 5. Una instancia en ejecucin del comando top.

Captulo 2 Estados del proceso Conceptos clave

En Linux, el primer proceso, /sbin/init, lo inicia el kernel en el arranque. Todos los dems procesos son el resultado de un proceso padre que se duplica o bifurca. Un proceso comienza a ejecutar un nuevo comando a travs de un proceso llamado execing. Los nuevos comandos suelen ejecutarse mediante un proceso (a menudo una shell) primero mediante una bifurcacin 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 informacin del cdigo de retorno y del uso de recursos. Cuando un padre muere antes que sus hijos, el primer proceso hereda los hurfanos (usualmente /sbin/init).

15

Managing Processes

Ciclo de vida de un proceso Cmo se inician los procesos En Linux (y Unix), a diferencia de muchos otros sistemas operativos, la creacin de proceso y la ejecucin 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. Creacin de un nuevo proceso (forking) Los nuevos procesos se crean mediante una tcnica llamada forking. Cuando un proceso se bifurca, crea un duplicado de s mismo. Inmediatamente despus de una bifurcacin, el proceso recin creado (el hijo) es un duplicado exacto del proceso original (el padre). El hijo hereda una copia idntica de la memoria del proceso original, los archivos abiertos de padre, copias idnticas de los parmetros del padre, tales como el directorio de trabajo actual o umask. La nica diferencia entre el padre y el hijo es la informacin 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 rpido 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 slo un proceso entra en el llamado fork(), dos procesos retornan. Para el proceso recin 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. Ejecucin de un nuevo comando (Execing)

16

Managing Processes Los nuevos comandos se ejecutan a travs de un tcnica llamada execing (acortamiento en ingls para executing). Cuando se ejecuta un nuevo comando, el proceso actual borra y libera la mayora de sus recursos y carga una nueva coleccin de instrucciones desde el comando especificado en el sistema de archivos. La ejecucin inicia con el punto de entrada del nuevo programa. Despus de utilizar ejecutar un nuevo comando, el nuevo comando todava es el mismo proceso. Tiene el mismo ID de proceso y muchos de los mismos parmetros (tales como su utilizacin 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 ejecucin 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 ejecucin se realiza en el punto de entrada (por ejemplo, main()) del nuevo programa. Si por la misma razn execl(...) retorna, debe ser un error (tal como no poder localizar el ejecutable del comando en el sistema de archivos). Combinacin 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 conexin de un cliente especfico, mientras el padre retorna para escuchar nuevos clientes. Otros programas podran utilizar exec sin bifurcacin. Ejemplos incluyen al comando login, el cual se convierte en la shell de inicio de sesin del usuario despus de confirmar la contrasea 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 intrprete 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 excepcin del primero se crea por bifurcacin, 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

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 ...

Cmo muere un proceso Cuando un proceso muere ya sea que muera normalmente seleccionando exit o anormalmente como el resultado de recibir una seal. Aqu tratamos la salida normal del proceso, dejando para ms adelante la discusin acerca sobre la seales. Hemos mencionado anteriormente que los procesos dejan atrs un cdigo de estatus cuando mueren (tambin llamado valor de retorno) en la forma de un nmero 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 excepcin del cdigo de retorno (y alguna informacin de utilizacin de recursos contables). Es responsabilidad del padre del proceso coleccionar esta informacin 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. Hurfanos Si es responsabilidad de los padres limpiar despus de sus hijos, qu sucede si el padre muere antes que el hijo? El hijo queda hurfano. Una de las responsabilidades especiales del primer proceso iniciado por el kernel es "adoptar" hurfanos, (observe que en la salida del comando pstree, el primer proceso tiene un nmero

18

Managing Processes desproporcionado de hijos. La mayora de estos fueron adoptados como hurfanos de otros procesos). Zombis Entre el momento en que un proceso sale, liberando la mayora 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 travs 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 ningn otro sistema de recursos. Ellos son slo 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 quizs el concepto bsico ms incomprendido de Linux (y Unix). Mucha gente dir que no hay forma de deshacerse de ellos, excepto volviendo a arrancar la mquina. Sabe cmo deshacerse de zombis de larga vida utilizando las claves tratadas en esta seccin? Los 5 estados del proceso La seccin anterior trat la manera como se inician y mueren los procesos. Mientras los procesos estn vivos, siempre estn en uno de los cinco estados del proceso, los cuales efectan el cmo y cundo 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 aprovecharan. Los procesos mltiples suelen estar en un estado de ejecucin, pero como slo puede ejecutarse un proceso en la CPU en determinado tiempo, slo uno de estos procesos en realidad estar ejecutndose en un momento dado. Puesto que los procesos de ejecucin entran y salen de la CPU tan rpidamente en el sistema de Linux, parece como si todos los procesos se estuvieran ejecutando de manera simultnea. [1] Dormido voluntario (interrumpible) (S)

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 clsico 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 sera 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 estn 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 realizarn ninguna accin hasta no ser reiniciados por el usuario. En la shell bash, la secuencia de teclas CONTROL-Z puede utilizarse para suspender un proceso. En programacin, los depuradores suelen suspender los programas que estn depurndose cuando ciertos eventos suceden (como cuando se producen puntos de interrupcin). Procesos zombi (Z) Como lo mencionamos antes, cada proceso muriendo pasa a travs 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 estn consumiendo recursos, son poco ms 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

Managing Processes

Ejecutable - R Dormido - S Detenido - T Dormido ininterrumpible - D Zombi Z

Ejemplos Identificacin 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 0 775 776 1774 1774 4292 4248 1220 2600 5793 5798 5799 5799 15 15 15 17 16 15 15 16 15 16 17 17 17 0 0 0 0 0 0 0 0 0 0 0 0 0 1344 RSS WCHAN STAT TTY ? tty3 tty4 pts/3 pts/3 tty4 tty3 ? pts/0 pts/0 pts/0 pts/0 pts/0 TIME 0:06 0:00 0:00 0:00 0:00 0:00 2:57 0:00 0:00 0:00 0:00 0:00 0:00

436 schedu S S

4136 1412 wait4

4144 1420 schedu S 1472 1464 528 down 520 D R

7612 2616 do_sig T 3612 1052 schedu S 0 0 do_exi Z S S S R

7708 2816 wait4 3804 944 wait4

3808 1000 wait4 3148 1240 3144

420 pipe_w S

Un proceso dormido (voluntario). El proceso init est esperando que algo "interesante" suceda tal como un hurfano recin creado a heredar. Un proceso dormido(involuntario) o "bloqueado". El comando updatedb est compitiendo por algn 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

Managing Processes Ejercicios en lnea 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 estn compitiendo por los mismos recursos. Utilice un editor de texto sencillo para crear el siguiente guin, almacnelo como ~/clobber_it.sh y hgalo 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 guin 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 mltiples compitiendo por el mismo recurso, cree tambin el mismo script. Nmbrelo ~/clobber_it_lots.sh y hgalo 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 debera 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 guin est ejecutndose, observe la terminal con el comando top. Usted debera ver muchos procesos inicindose y detenindose como tambin muchos procesos en el estado D. Si tiene suerte, podra capturar incluso un zombi. An no hemos dicho que empiece. 18. Tambin mientras se est ejecutando el script, en otro terminal, ejecute el comando ps aux y redirija la salida al archivo ~/lotsa_processes.txt.

22

Managing Processes Observe el contenido del script y asegrese que al menos cinco procesos en el estado D hayan sido registrados. An no hemos dicho que empiece. 19. Empiece! 20. Despus 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).

Captulo 3 Programacin de procesos: nice y renice Conceptos clave


Una tarea primaria del kernel de Linux es la programacin de procesos. Cada proceso tiene un valor de niceness que influye en su programacin. Los comandos nice y renice pueden cambiar la prioridad de programacin de un proceso.

Nomenclatura de programacin 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 ms 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 programacin. Cada proceso tiene dos valores que influyen en su programacin. El primero es un valor dinmico que el kernel cambia constantemente. El segundo, es un valor fijo que slo de vez en cuando el usuario lo cambia. En la comunidad de cdigo abierto, la nomenclatura utilizada para describir estos dos valores ha sido inconsistente lo que lleva a la confusin. En lo posible, este texto tratar de ser consistente con los comandos ps y top y se referir al primer valor (dinmico) como la prioridad del proceso y al segundo valor (fijo) como el niceness del proceso. Programacin de procesos en esencia Recientemente, se ha prestado mucha atencin a los mtodos utilizados por el kernel de Linux para implementar programacin y la tcnica ha variado con cada lanzamiento del kernel. Aunque la siguiente discusin no es correcta en detalle comunica en esencia la forma como el kernel de Linux programa procesos.

23

Managing Processes Para ilustrar la programacin de un modo ms fcil, maxwell iniciar cuatro versiones del comando cat, ejecutndose en el segundo plano, (los procesos se pueden ejecutar en segundo plano agregando el signo &), como se discutir en una leccin ms adelante. Los comandos cat leen desde /dev/zero (un seudo dispositivo que acta 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 cunto tiempo se ejecutarn estos comandos cat? Para siempre. El usuario maxwell controla los procesos en su mquina 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 352 352 352 3596 352 1108 852 692 52 0 R R R R R R N R S S SW 19.3 19.3 19.3 17.4 16.4 4.8 2.9 1.9 0.0 0.0 0.1 0.1 0.1 9.7 0.1 1.8 0.4 6.5 0.0 0.0 TIME CPU 0:24 0:24 0:24 0:04 0:24 0:44 0:00 33:56 0:04 0:00 0 0 0 0 0 0 cat cat cat jade cat

83.5%

0 404 400 0 400 400 0 400 372 0 25992 24M 0 400 400 10 6608 4836 0 1120 1120 0 33304 16M 0 108 76 0 0 0

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) estn en constante cambio. Estos son los valores de "prioridad" dinmicos del proceso mencionados anteriormente. La cuarta columna (con la etiqueta NI) es el valor fijo de "niceness" del proceso. Prioridades del proceso

24

Managing Processes Cuando se programan los procesos, el kernel da a cada proceso un puado de contadores. Cada vez que un proceso se programa en la CPU, entrega uno de sus contadores. Cuando decide qu proceso programar en la prxima CPU, el kernel escoge un proceso ejecutable con la mayora 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 programacin epoch y en este punto el kernel inicia todos los procesos otra vez con un puado de contadores. Observe que los procesos que no estn 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 tendra ms contadores que procesos ejecutndose por un tiempo y le gustara que fueran programados rpidamente en la CPU. Cmo se relaciona esto con los valores demostrados en la columna PRI? Piense en esta columna como si fuera un nmero 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 programacin. En la salida de arriba, los comandos cat, en constante ejecucin, estn 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 tambin tiene un valor esttico 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. Cmo influye un niceness de un proceso en su programacin? Al comienzo de la programacin puede pensar que el kernel resta un valor de niceness del proceso del nmero de contadores del proceso que se le ha asignado. Como resultado de procesos ms, "amables" (aquellos con un alto valor de niceness) obtienen menos contadores y por lo tanto menos tiempo en la CPU, mientras que procesos ms "ambiciosos" (aquellos con un valor de niceness menor que 0) obtienen ms contadores y ms tiempo en la CPU. Si un proceso "amable" es el nico ejecutndose en la mquina entonces obtendra acceso total a la CPU. Cambio del valor niceness de un proceso Suponga que maxwell fuera a ejecutar una simulacin fsica que le tomara varios das completar. Al incrementar el valor de niceness del proceso, el proceso pacientemente esperara si alguien ms estuviera ejecutando procesos en la mquina. Si nadie ms estuviera en la mquina, la simulacin fsica tendra acceso total a la CPU. Hay varias tcnicas por las cuales maxwell podra alterar su valor de niceness del proceso. Uso del comando nice para iniciar un comando con prioridad baja

25

Managing Processes El comando nice se utiliza para establecer un valor de niceness del proceso al iniciar el proceso. Cuando maxwell inicia su simulacin (la cual es un ejecutable en su directorio de inicio llamado ~/simulation) lo hace lo ms nice posible, con el valor de +19, (tambin coloca el proceso en segundo plano. No se preocupe por esto en este momento puesto que lo abarcaremos en una prxima leccin).
[maxwell@station maxwell]$ nice -19 ./simulation &

Observe que la sintaxis puede confundir. El smbolo -19 no debera considerarse negativo 19 sino en cambio la opcin numrica 19. El usuario maxwell de nuevo controla los procesos mediante el comando top. Los primeros pocos procesos listados se enumeran a continuacin.
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 estn utilizando la mquina, la simulacin de maxwell slo est usando cerca del 2.1 % de la CPU. Luego, maxwell se deshace de los comandos cat (mediante las tcnicas que veremos en la siguiente leccin).
[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 ms, su simulacin, ahora el (casi) nico proceso en la mquina, 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:00 47:01 0:21 0:04 0 0 top 0 X 0 rhn0 init

26

Managing Processes Como una sutileza adicional, el nmero especificado es el nmero que va a agregarse al valor de niceness de la shell actual. Esto rara vez se nota, dado que la mayora de las shells se ejecutan con un niceness de 0. No obstante, si una shell estuviera ejecutndose con un valor de niceness de 10, la siguiente opcin de lnea de comando resultara en la simulacin que est ejecutndose con un valor de niceness de 15.
[maxwell@station maxwell]$ nice -5 ./simulation &

Uso de renice para alterar un proceso en ejecucin El comando renice puede utilizarse para cambiar el niceness de un proceso en ejecucin. Los procesos pueden ser especificados por el ID del proceso, nombre de usuario, o nombre de grupo, dependiendo de cul de las siguientes opciones se utilicen. Table 1. Opciones para el comando renice Opcin Efecto -p interpreta los argumentos restantes como ID del proceso (por defecto) -u -g interpreta los argumentos restantes como nombres de usuarios. interpreta los argumentos restantes como ID de grupo.

Suponga que maxwell ya ha iniciado su simulacin 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 ms corts con otras personas que podran estar utilizando la mquina y utiliza el comando renice para elevar el valor de niceness del proceso. En la ausencia de cualquier opcin, 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 opcin, sino como un argumento. De hecho, renice -19 7347 sera interpretado como un valor de niceness de -19. Enlodando ms las aguas, la salida del comando renice se refiere al

27

Managing Processes valor como una prioridad en lugar de un niceness, (como tambin lo hace alguna de la documentacin 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 dilogo que aparece encima de la lista de procesos.
PID to renice: 7347 Renice PID 7347 to value: 19

Hacer procesos mucho ms ambiciosos Qu sucedera si maxwell fuera malintencionado y quisiera hacer su simulacin mucho ms ambiciosa en lugar de ms amable? Afortunadamente, para otros usuarios en la mquina, 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 simulacin 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

RSS WCHAN

STAT TTY

TIME

898 2676 2611

15 18 16

0 0 0

4232 1544 wait4 3284 3804 644 948 wait4

S R S

pts/0 pts/0 pts/1

0:00 0:00 0:00

28

Managing Processes
040 501 2741 /bin/bash 000 501 2742 ps -alx 000 501 2743 tail ... [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 / ... 2740 2741 2741 16 17 17 0 0 0 3808 1004 wait4 3144 1232 3144 S R pts/1 pts/1 pts/1 0:00 0:00 0:00

420 pipe_w S

maxwell]$ ps -alx PPID PRI NI VSZ

RSS WCHAN

STAT TTY

TIME

898 2611 2718 2719 2719 2676

16 15 16 17 17 17

0 0 0 0 0 0

4232 1544 wait4 3808 944 wait4

S S S R R R

pts/0 pts/1 pts/1 pts/1 pts/1 pts/0

0:00 0:00 0:00 0:00 0:00 0:00

3812 1000 wait4 3148 1232 3136 3248 384 576 -

La prioridad del proceso find flucta 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 2676 2611 3010 3011 3011 20 16 17 17 17 5 0 0 0 0 3248 3804 576 948 wait4 S S R RN

pts/0 pts/0 pts/1 pts/1 pts/1 pts/1

0:00 0:00 0:00 0:00 0:00 0:00

3808 1004 wait4 3140 1228 3140

416 pipe_w S

Debido a que el valor de niceness se ha incrementado, el proceso tiene valores ms altos de prioridad (implicando menos acceso a la CPU por una poca de programacin). 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

Managing Processes
renice: 2739: setpriority: Permission denied

Dado que a los usuarios estndar no se les permiten valores de niceness ms bajos, el comando falla. Cambio de prioridades con renice Al utilizar la opcin -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 pts/4 ? pts/4 pts/4 TIME 00:00:00 00:00:00 00:00:00 00:00:00

TTY pts/4 ? pts/4 pts/4

TIME 00:00:00 00:00:00 00:00:00 00:00:00

Ejercicios en lnea 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 (podra considerar el utilizar el comando pgrep junto con el comando xargs para este paso). 4. Despus de completar el ltimo paso, cambie el valor de niceness del proceso cat (iniciado en el paso 1) a 10.

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 an ejecutndose. Question 1

1. Un comando cat ejecutndose con el valor de niceness de 10. 2. Un comando cat ejecutndose 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. Captulo 4 Envo de seales Conceptos clave

Las seales son una forma de bajo nivel de la comunicacin entre procesos que surgen de una variedad de recursos, incluyendo el kernel, la terminal y otros procesos. Las seales se distinguen por los nmeros de seales que tienen nombres y usos simblicos. Los nombres simblicos para los nombres de seales pueden listarse con el comando kill -l. El comando kill enva seales a otros procesos. Tras recibir una seal, un proceso puede ya sea, ignorarla, reaccionar de un modo especificado por defecto de kernel o implementar un manejador de seal personalizado. Convencionalmente, el nmero de seal 15 (SIGTERM) se utiliza para solicitar la terminacin de un proceso. La seal nmero 9 (SIGKILL) termina un proceso y no puede anularse. Los comandos pkill y killall pueden utilizarse para enviar seales a procesos especificados por nombre de comando o el usuario a quienes pertenecen. Otras utilidades, tales como top y el Monitor de sistema GNOME, tambin pueden utilizarse para enviar seales.

Seales Linux (y Unix) utiliza seales para notificar procesos de eventos anormales, y como un mecanismo primitivo de comunicacin entre procesos. Algunas veces, las seales se conocen como interrupciones de software, porque pueden interrumpir el flujo normal de ejecucin de un proceso. El kernel utiliza seales para notificar procesos de conducta

31

Managing Processes anormal, como si el proceso tratase de dividir un nmero por cero o tratase de acceder memoria que no le perteneciera. Los procesos tambin pueden enviar seales a otros procesos. Por ejemplo, una shell bash podra enviar una seal a un proceso xclock. El proceso receptor sabe muy poco acerca de los orgenes de la seal. No sabe si la seal se origin del kernel o de algn otro proceso, todo lo que sabe es que recibi una seal. Figure 1. Xclock recibe un seal nmero 15 de Bash

Sin embargo, hay diferentes sabores de seales. Los diferentes sabores tienen nmeros simblicos pero tambin se identifican con nmeros enteros. Los varios nmeros enteros y el nombre simblico que les son asignados pueden listarse por medio del comando kill -l o los puede encontrar en la pgina 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 seales "normales". En Linux, las seales se numeran a partir de 32 hasta 63 (que no son estndar entre las varias versiones de Unix) y son seales en "tiempo real" y van ms alla del objetivo de este texto.

Por qu se envan las seales?

32

Managing Processes Hay una variedad de razones por las cuales las seales se pueden enviar a un proceso como se ilustra con los siguientes ejemplos. Excepciones de hardware El proceso le pidi al hardware realizar alguna operacin errnea. Por ejemplo, el kernel enviar un proceso SIGFPE (seal nmero 8) si realiza una divisin por 0. Condiciones del software Los procesos pueden necesitar ser notificados de alguna condicin anormal del software. Por ejemplo, cada vez que muere un proceso, el kernel enva un SIGCHLD (nmero de seal 17) al padre del proceso. Otro ejemplo, las aplicaciones grficas X reciben un SIGCHLD (nmero de seal 17) cada vez que su ventana cambia de tamao, para poder responder a la nueva geometra. Interrupciones de terminal Varias secuencias de control de teclas de la terminal envan seales al proceso de la shell bash. Por ejemplo, CONTROL-C enva un SIGINT (nmero de seal 2) mientras que CONTROL-Z enva un SIGTSTP (nmero de seal 20). Otros procesos Los procesos pueden elegir enviar seales a cualquier otro proceso perteneciente al mismo usuario. El comando kill est diseado para hacer justo esto. Envar seales: el comando kill El comando kill se utiliza para enviar seales a otros procesos. ste espera ser llamado con una opcin numrica o simblica que especifica la seal a enviar y un ID de proceso que especifica el proceso que debera recibirlo. A manera de ejemplo, las siguientes lneas de comando envan un SIGCHLD (nmero de seal 17) al proceso xclock, el ID del proceso nmero 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 simblico para especificar una seal, el prefijo SIG (compartido por todas las seales) puede ser includo u omitido. Recepcin de seales

33

Managing Processes Cuando un proceso recibe una seal puede realizar una de las siguientes tres acciones. Implementar un manejador de seal predeterminado del kernel Para cada tipo de seal hay una respuesta predeterminada implementada por el kernel. A cada seal se le asigna una de las siguientes conductas.

Terminar: El proceso de recepcin se cierra. Ignorar: El proceso de recepcin ignora la seal Ncleo: El proceso de recepcin 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 pgina de manual signal(7) documenta la conducta asignada para cada seal. Escoja ignorar la seal Los programadores pueden elegir que su aplicacin simplemente ignore seales especificadas. Escoger implementar un manejador de seal personalizado Los programadores pueden elegir implementar su propia conducta cuando se recibe una seal especfica. La respuesta del programa es completamente determinada por el programador. A no ser que la documentacin 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 seales para terminar procesos De las 32 seales utilizadas en Linux (y Unix) los usuarios normales en prctica (explcitamente) slo hacen uso de unas pocas. Table 1. Seales importantes para usuarios normales Nmero Symbol 2 9 15 SIGINT SIGKILL Accin Interrumpe (solicita terminar) el proceso. Esta es la seal generada por la secuencia de control CTRL-C. Fuerza el terminar el proceso (esta seal puede no ser anulada por el proceso)

SIGTERM Solicita la terminacin del proceso.

34

Managing Processes Nmero Symbol 20 SIGTSTP Accin Detiene (suspende) el proceso. Esta es una seal generada por la secuencia de control CTRL-Z.

Los usuarios estndar suelen utilizar seales para terminar un proceso (razn del nombre del comando kill). Por convencin, 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 seal personalizado de 15 para realizar la accin. El nmero de seal 9 se maneja especialmente por el kernel y no puede anularse por un manejador de seal personalizado o ser ignorado. Este se reserva como un ltimo recurso, la tcnica de nivel de kernel para matar un proceso. A manera de ejemplo, einstein iniciar un comando cat que en un principio se ejecutara 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 (nmero de seal 15) es la seal por defecto para el comando kill, por lo tanto einstein pudo haber utilizado kill 8375 para el mismo efecto. A continuacin, 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 seales para controlar procesos es una ocurrencia tan comn que las alternativas para usar el comando kill abundan. Las siguientes secciones mencionan unas cuantas.

El comando pkill

35

Managing Processes En cada uno de los ejemplos anteriores, einstein necesita determinar el ID de un proceso antes de enviar una seal a ste con el comandokill. El comando pkill se puede utilizar para enviar seales a procesos seleccionados por medios ms generales. El comando pkill espera la siguiente sintaxis.
pkill

[-signal] [OPCIONES] [PATRN]

El primer smbolo especifica opcionalmente el nmero de seal para enviar (por defecto, el nmero de seal 15). PATTERN es una expresin regular extendida que coincidir con nombres de comandos. El siguiente cuadro lista las opciones de comando ms utilizadas. Los procesos que cumplen con todos los criterios especificados enviarn la seal especificada. Table 1. Opciones para el comando pkill Opcin -n Efecto Selecciona nicamente los procesos coincidentes iniciados ms 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 enva seales a procesos especificados por el nombre de comando. El comando killall soporta las siguientes opciones. Table 1. Opciones para el comando killall

36

Managing Processes Opcin -i, -interactive -w, --wait Efecto De modo interactivo pregunta al usuario antes de enviar la seal a un proceso. Espera hasta que todos los procesos estn muertos antes de retornar.

El Monitor del sistema La aplicacin del Monitor de sistema GNOME, presentada en una leccin anterior, tambin puede utilizarse para enviar seales 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 opcin del men Matar proceso? Figure 1. Terminacin de procesos mediante el monitor del sistema.

El comando top El comando top puede tambin utilizarse para entregar seales a procesos. Al utilizar la tecla K, aparece el siguiente dilogo encima de la lista de procesos, permitindole al usuario especificar qu procesos ID deberan recibir la seal y qu seal entregar.
PID to kill: 4859 Kill PID 4859 with signal [15]: 9

Ejemplos Uso de seales para terminar procesos Las seales suelen ser la nica forma de terminar procesos que estn siendo manejados por una lnea de comando de shell. Por ejemplo, los clientes (aplicaciones) grficos 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 grfico 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

Managing Processes
[2]+ Terminated xclock [maxwell@station maxwell]$ pgrep -lu maxwell 2112 bash

Pero, espere! Hay una forma diferente para terminar aplicaciones grficas aparte del envo de seales. 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 seal SIGTERM a una aplicacin adjunta. Uso de seales para matar procesos Cada vez que sea posible la seal SIGTERM debera utilizarse para terminar procesos. Sin embargo, algunas veces, los procesos estn "encerrados" y completamente insensibles, incluso para las seales SIGTERM. En estos casos, la seal SIGKILL (nmero de seal 9) puede utilizarse como un ltimo recurso. La seal SIGKILL mata un proceso en el kernel sin ninguna interaccin con el proceso mismo. A continuacin, maxwell intenta terminar una simulacin fsica (el proceso sim) con la seal por defecto SIGTERM. Por alguna razn, el proceso es insensible por lo tanto maxwell lo mata con la seal 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

Hgalo que pare! La combinacin de la habilidad de pkill para seleccionar todos los procesos pertenecientes a un usuario particular, y la seal SIGKILL de bajo nivel letal, conforman una tcnica conveniente para que un usuario mate todos los procesos que puedan estar ejecutndose en la mquina local. A continuacin, maxwell observa primero cuntos procesos est ejecutando en la mquina 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 mquina (matando su propia sesin X o inicio de sesin de consola virtual) y debe iniciar sesin otra vez.

38

Managing Processes Ejercicios en lnea Lab Exercise Objetivo: Terminar la ejecucin 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 guin debera matar todos los procesos cat en ejecucin. 2. En una terminal, iniciar un proceso cat mediante la siguiente lnea de comandos. Deje el proceso en ejecucin mientras califica su ejercicio (pero no se sorprenda si no est en ejecucin 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 seal SIGTERM a todas las instancias actuales en ejecucin del comando cat. 2. Un proceso cat en ejecucin.

Captulo 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 mltiples 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

Managing Processes Los temas tratados en este cuaderno hasta el momento, es decir la informacin sobre listado de procesos, el cambio de un valor niceness de un proceso y el envo de seales a procesos son caractersticas compartidas por todos los procesos, ya sean iniciados desde una lnea 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 intrprete de comandos de una shell interactiva y se enfocar en la shell bash. Ejecucin de comandos en el primer plano Cuando se ejecuta un comando desde un intrprete 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 intrprete de comandos y cualquier cosa escrita con el teclado se lee generalmente como la stdin para este comando. Todo esto debera sonar familiar porque los comandos utilizados hasta el momento se han ejecutado en el primer plano. Ejecucin de comandos en segundo plano como trabajos En contraste, cualquier comando que usted especifique puede tambin ejecutarse en el segundo plano, adjuntndole el signo (&) a la lnea de comandos. Por lo general, slo los comandos de larga ejecucin que no requieren entradas desde el teclado y no generan grandes cantidades de salida son apropiados para un segundo plano. Cuando la shell bash enva a segundo plano un comando, el comando se conoce como un trabajo y se le asigna un nmero de trabajo. En el siguiente ejemplo, einstein est realizando una bsqueda de los archivos que mayores de 1 megabyte en tamao 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

Despus de iniciar el trabajo en el segundo plano, la shell bash reporta dos partes de informacin a einstein. La primera es el nmero de trabajo reportado entre parntesis cuadrados. La segunda es el ID del proceso del trabajo de segundo plano. En este caso, el trabajo es el nmero 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 enva 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

Managing Processes De nuevo, bash reporta el nmero de trabajo (2) y el ID del proceso del segundo comando find (7023). El segundo mensaje de shell bash est notificando a einstein el nmero de trabajo que se ha terminado. La shell bash reporta que sta ha salido con un cdigo de retorno de 1 (opuesto a ser matado por una seal) y revisualiza la lnea de comando para recordar a einstein lo que ha ejecutado. La shell bash no reporta inmeditamente la muerte de los trabajos, sino espera hasta la prxima vez que interprete una lnea de comandos. Cuando einstein ha digerido todo esto sospecha que su segundo trabajo tambin ha terminado. Simplemente, pulsa la tecla ENTER (para que bash "interpretar" la lnea de comandos vaca). Igualmente, la shell bash reporta su nuevo nmero de trabajo 2.
[einstein@station einstein]$ [2]+ Exit 1 >oldfiles.tx t 2>/dev/null find / -user einstein -and -mtime +14

Administracin de mltiples trabajos El usuario einstein, al igual que maxwell, suele realizar clculos fsicos que toman mucho tiempo para ejecutar. Inicia varias versiones de la simulacin envindolas 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 ejecucin.
[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 nmero de trabajo. El trabajo ms 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

Managing Processes Un trabajo de segundo plano puede traerse al primer plano con el comando incorporado fg. El comando fg espera un nmero 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 ejecutndose en el primer plano. Como consecuencia, la shell no generar ningn intrprete de comandos cuando el proceso est en ejecucin. Suspensin del trabajo de primer plano con CONTROLZ Previamente, se introdujo la secuencia CONTROL-Z como un mtodo 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 S T S R 16:20 16:20 16:20 16:34

TIME COMMAND 0:00 -bash 0:00 0:00 0:00 0:00 0:00 ps u

Cuando est suspendido (o para utilizar la terminologa de shell, detenido), el proceso recibe el nmero de trabajo (si es que an no lo tiene) y se enva 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 nmero de trabajo como un argumento o si no se provee ninguno entonces se utiliza el trabajo actual.

42

Managing Processes A continuacin, 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 nmero de trabajo 3 est otra vez en estado de ejecucin. Matar trabajos El comando kill, utilizado para entregar seales para procesos se implementa como un comando incorporado de shell, (confusamente, tambin se encuentra otra versin en el sistema de archivos /bin/kill. Probablemente usted est utilizando la versin de shell incorporada). Como resultado, est consciente de los trabajos que la shell est administrando. Cuando se especifica qu proceso debera recibir una seal, el nmero de trabajo del proceso (si lo hay) puede especificarse en vez de su ID de proceso. Para distinguir los dos, los nmeros de trabajo estn 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 errneamente utiliz la sintaxis para especificar un ID de proceso, en vez del nmero de trabajo. Puesto que l no posee su propio proceso con el ID de proceso nmero 2, el comando falla. Aqu, einstein utiliz la sintaxis correcta para especificar un nmero de trabajo y la seal fue enviada al proceso sim_b. Resumen El siguiente cuadro resume los comandos y tcnicas para administrar trabajos dentro de la shell bash.

43

Managing Processes Table 1. Administracin de trabajos en la shell bash Comando 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"). Inicia el trabajo de segundo plano detenido N (por defecto, el trabajo "actual"en segundo plano). Termina el trabajo de segundo plano N (enviando la seal SIGTERM). Accin

CTRL-Z Suspende y enva al segundo plano el actual comando de primer plano bg [N] kill %N Ejemplos Decidir enviar a segundo plano un comando ejecutndose en el primer plano La discusin mencion que los comandos se pueden iniciar en el segundo plano, agregando un signo & a la lnea de comandos. A continuacin, einstein inicia un comando en el primer plano y luego, dndose cuenta que le tomara 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 tcnica 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

Managing Processes
[einstein@station einstein]$ jobs [1]- Running ./sim_a & [3]+ Running ./sim_c &

Ejercicios en lnea Lab Exercise Objetivo: Uso del control de trabajo bash para administrar trabajos mltiples. 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 deberan estar ejecutndose, mientras que los trabajos find y ls deberan suspenderse.

Limpieza Despus de haber calificado su ejercicio, utilice el comando kill (o la combinacin fg/ CONTROL-C) para matar todos los cuatro trabajos.

Captulo 6 Programacin de tareas retrasadas: at Conceptos clave

El comando at puede someter comandos para que se ejecuten ms tarde.

45

Managing Processes

El comando batch puede emitir comandos para que se ejecuten cuando la carga de las mquinas sea baja. Los comandos pueden escribirse directamente o someterse como un script. la stdout de los trabajos at se enva 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 discusin de un concepto comn en Unix: los demonios. Con un nombre inspirado por Daemon del fsico 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 sesin (syslogd) y el demonio administrador de potencia (apmd). Esta y la siguiente leccin describirn dos demonios que permiten a los usuarios retrasar tareas (atd), o ejecutar comandos en intervalos fijos (crond). Hasta el momento, usted habr notado una convencin para nombres: los programas diseados 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 sabra que estn 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 grep atd 532 ? 640 pts/4 S S 09:57 16:17 0:00 crond 0:00 grep

S S

15:42 16:17

0:00 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 ejecutndose como el demonio de usuario.

El demonio atd El demonio atd le permite a los usuarios someter trabajos para ser realizados ms tarde, tal como a las "at 2:00am". Para utilizar el demonio atd, ste debe estar ejecutndose.

46

Managing Processes Los usuarios pueden confirmar que atd se est ejecutando simplemente al examinar la lista de procesos en ejecucin:
[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 16:43 0:00 0:00 grep

Observe que la sptima 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 grfica dentro de una sesin X. Observe que el demonio atd no tiene terminal asociada. Una de las caractersticas de un demonio es que quita su asociacin con la terminal que la inici. Envo de trabajos con at El comando at se utiliza para someter trabajos al demonio atd para que se ejecuten en una hora especfica. Los comandos que se van a ejecutar son sometidos ya sea como script (con la opcin -f) o escritos directamente via la stdin. La salida estndar del comando se enva por correo al usuario.

at

[[-f filename] | [-m]] TIME Efecto ejecuta el script especificado por el nombre de archivo Notifica al usuario por correo electrnico cuando se ejecuta, incluso si no hay salida.

Opcin -f filename -m

La hora del da se puede especificar utilizando HH:MM, con el sufijo "am" o "pm". Los trminos en ingls "midnight", "noon", y "teatime" tambin pueden utilizarse. Igualmente, mediante varios formatos incluyendo MM/DD/YY. (mes/da/ao/). Para mayor informacin refirase a la pgina del manual at(1). El luchador hogan deseara 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 tambin utiliza mucho la impresora. Como quiere evitar peleas, decide demorar su trabajo de impresin hasta las 2:00 de la maana.
[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

Managing Processes Dado que hogan no utiliz la opcin -f, el comando at le pidi teclear sus comandos mediante la stdin (el teclado). Afortunadamente, hogan saba 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 ningn 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 especfico, sino que espera hasta que el sistema se desocupe de otras tareas a cualquier hora. Si la mquina no est ocupada cuando se somete un trabajo, el trabajo podra 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 idntica al comando at, donde los trabajos pueden ser especificados con la stadin o sometidos como un lote con la opcin -f. Si la hora se especifica, el batch se demorar observando la mquina 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

Managing Processes command atd at batch atq atrm Ejemplos Someter un trabajo at como un archivo El usuario hogan ha desarrollado ahora el hbito de imprimir su correspondencia de sus admiradores a las 2:00 de la maana. Tambin ha descubierto el comando enscript, el cual reformatea archivos de texto imprimindolos "2up" (dos pginas de texto impresas por pginas) y representa la pgina impresa con encabezados informativos y pies de pgina. Despus de una corta experiencia desarrolla la siguiente opcin para formatear la pgina 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 guin corto con el (o los) comando(s) que deseara ejecutar en un archivo llamado fanmail.at:
[hogan@station hogan]$ cat fanmail.at enscript -r2 -G --header="Fan Mail" --borders fanmail.txt

uso El demonio que ejecuta trabajos sometidos. Los usuarios no utilizan el comando atd directamente. Somete trabajos al demonio atd para que se ejecuten en un tiempo especfico. Somete trabajos al demonio atd para que se ejecuten cuando el sistema no est ocupado. Lista trabajos en espera con el demonio atd. Cancela un trabajo en espera con el demonio atd antes de ejecutarse.

Ahora, cuando hogan quiere someter a impresin su correspondencia de la fanaticada puede simplemente especificar el script a at con la opcin -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 prctico decide someter un trabajo de su propiedad. Crea el archivo bogus_fanmail.txt, que falsifica correspondencia no muy elogiosa de sus fanticos. Somete un trabajo que imprimir el archivo a la 1:59 am confiando que hogan no notar la insercin cuando recoja los papeles de la impresora en la maana.

49

Managing Processes
[ventura@station ventura]$ echo "lpr bogus_fanmail.txt" | at 1:59 am warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh job 12 at 2003-06-18 01:59 [ventura@station ventura]$ atq 12 2003-06-18 01:59 a ventura

En cierto punto ms adelante, el administrador del sistema de la mquina actuando como root, observa los dos trabajos at en espera.
[root@station at]# atq 11 2003-06-18 02:00 a hogan 12 2003-06-18 01:59 a ventura

Curioso por lo que ventura piensa hacer, root fisgonea dentro del directorio spool de at. Examina el contenido de su nombre de archivo spool llamado de forma crptica a0000c010c8887, el cual pertenece al usuario ventura.
[root@station at]# ls -l total 12 -rwx-----1 hogan hogan 1480 Jun 17 12:37 a0000b010c8888 -rwx-----1 ventura ventura 1459 Jun 17 13:08 a0000c010c8887 drwx-----2 daemon daemon 4096 Jun 16 17:24 spool [root@station at]# cat /var/spool/at/a0000c010c8887 #!/bin/sh # atrun uid=511 gid=511 # mail ventura 0 umask 2 HOSTNAME=bowe-lt.rdu.redhat.com; export HOSTNAME HISTSIZE=1000; export HISTSIZE USER=ventura; export USER LOGNAME=ventura; export LOGNAME ... LESSOPEN=\|/usr/bin/lesspipe.sh\ %s; export LESSOPEN G_BROKEN_FILENAMES=1; export G_BROKEN_FILENAMES XAUTHORITY=/home/ventura/.xauthqEj97Q; export XAUTHORITY cd /home/ventura || { echo 'Execution directory inaccessible' >&2 exit 1 } lpr bogus_fanmail.txt

(En este listado largo, se han borrado varias lneas y se han remplazado por "...".) root observa los siguientes aspectos de la conducta del script: El archivo es un script de shell y debido a sus permisos pudo ejecutarse directamente. La primera accin del script es la de establecer la umask del proceso a la umask de shell que someti el trabajo. La segunda accin es inicializar una coleccin de variables de entorno para imitar

50

Managing Processes el entorno de shell que someti el trabajo. La tercera accin es cambiar el directorio actual del proceso al directorio actual de trabajo de la shell que someti el trabajo. Por ltimo, despus de toda esta inicializacin, el guin est listo para ejecutar el trabajo sometido, en este caso lpr bogus_fanmail.txt. Al almacenar toda esta informacin con el trabajo sometido, el demonio atd es capaz de reconstruir el entorno de ventura cuando se enva el trabajo. Si el trabajo enviado crea nuevos archivos, los archivos tendran los permisos esperados, porque el guin creara la umask apropiada. Si cualquiera de los comandos iniciados por el script dependiera de las variables de entorno, el entorno se establecera como se espera y as sucesivamente. Ejercicios en lnea Someter un trabajo para una ejecucin posterior Ejercicio Objetivo: Utilizar el servicio atd para retrasar la ejecucin de una tarea. Estimated Time: 10 mins. Especificaciones Usted ha tenido dificultades tratando de recordar qu da es y por lo tanto quisiera enviarse una copia del calendario actual para verlo como primera cosa en la maana. Enva un trabajo que simplemente ejecuta el comando cal para las 3:45 de la maana. Asegrese que es el nico trabajo programado con esa facultad. Deliverables Question 1

1. Un trabajo en espera que generar la salida del comando cal a las 3:45 de la maana.

Captulo 7 Programacin de tareas peridicas: cron Conceptos clave


La utilidad cron se utiliza para programar tareas recurrentes. El comando crontab provee un frontend para editar archivos crontab.

51

Managing Processes

El archivo crontab utiliza 5 campos para especificar la informacin de temporizacin. la stdout de trabajos cron se enva por correo al usuario.

Ejecucin de tareas peridicas A menudo, las personas encuentran que estn realizando tareas en forma sistemtica. En la administracin de sistemas dichas tareas podran incluir quitar archivos viejos o no utilizados del directorio /tmp o comprobar si un archivo que est recolectando mensajes de registro no ha crecido demasiado. Otros usuarios podran hallar que son tareas propias el chequear archivos grandes que ya no se estn utilizando o chequear un sitio web para ver si hay algn anuncio. El servicio cron permite a los usuarios configurar comandos para que se ejecuten con regularidad tal como cada 10 minutos, una vez cada jueves, o dos veces al mes. Los usuarios especifican qu comandos deberan ejecutarse y a qu horas mediante el comando crontab para configurar su "cuadro cron". Las tareas se administran por el demonio tradicional de Linux (y Unix), el demonio crond. El servicio cron El demonio crond es el demonio que realiza tareas peridicamente en nombre del sistema o de usuarios individuales. El demonio suele iniciarse cuando el sistema arranca, por lo tanto, la mayora de usuarios lo pueden ignorar. Al listar todos los procesos y buscar crond puede confirmar si el demonio crond est en ejecucin.
[hogan@station hogan]$ ps aux | grep crond root 891 0.0 0.0 1572 128 ? hogan 8118 0.0 0.2 3576 644 pts/2 crond S S Jun17 10:15 0:00 crond 0:00 grep

Si el demonio crond no est ejecutndose, su administrador de sistema necesitara iniciar el servicio crond como root. Sintaxis crontab Los usuarios especifican los trabajos que se van a ejecutar y cundo se van a ejecutar, al configurar un archivo conocido como el "cuadro cron" a menudo abreviado en ingls "crontab". Un ejemplo de archivo crontab aparece a continuacin.
# set the default language to be english LOCALE=en_US 05 * * 15 04 * 25 04 1 * * * * * * procinfo find $HOME -size +100k echo "Pay your bills"

52

Managing Processes
35 04 14 3 julius 45 04 * * * 1 echo "Beware the Ides of March" | mail -s "a warning" find $HOME -atime +30 | lpr

Un archivo crontab es un archivo de configuracin basado en lnea, cada lnea realiza una de tres funciones: Comentarios Todas las lneas cuyo primer caracter (no espacio) es # se consideran comentarios y se ignoran. Variables de entorno Todas las lneas que tienen la forma nombre = valor se utilizan para definir variables de entorno. Comandos cron Cualquier otra lnea (no en blanco) se considera un comando cron, el cual consta de seis campos descritos a continuacin. Las lneas del comando cron constan de seis campos separados de espacios en blanco. Los primeros 5 campos se utilizan para especificar cundo ejecutar el comando y el sexto campo se utiliza para especificar el comando a ejecutar (compuesto de todo despus del quinto campo). Los primeros cinco campos especifican la siguiente informacin:
,----------------> | ,-------------> | | ,----------> | | | ,-------> | | | | ,----> | | | | | ,-> | | | | | | 25 04 1 * * echo minute hour day of month month (1=January, 2=February, ...) day of week (0=Sunday, 1=Monday, ...) command to run "Pay your bills"

Cada uno de los primeros cinco campos debe llenarse con un smbolo mediante la siguiente sintaxis: smbolo * n n, n, ... significado cada vez a la hora especificada a cualquiera de las horas especificadas ejemplo * 10 22,52 interpretacin (si se utiliza en el primer campo) cada minuto cada hora y 10 minutos a cada hora pasados los 22 y 52 minutos

53

Managing Processes smbolo */n significado cada n hora ejemplo */15 interpretacin (si se utiliza en el primer campo) cada 15 minutos (a los 0, 15, 30 y 45 minutos despus de la hora)

Uso del comando crontab Los usuarios rara vez administran su archivo crontab directamente (o incluso saben dnde se almacena), en cambio, utilizan el comando crontab para editar la lista o quitarla.

crontab crontab

{[-e] | [-l] | [-r]} ARCHIVO

Edita o quita el archivo crontab actual o remplaza el archivo actual crontab con FILE. Efecto Opcin -e modifica el archivo actual -l -r lista el archivo actual quita el archivo actual

En la siguiente secuencia de comandos, hogan utilizar el comando crontab para administrar su configuracin crontab. Primero lista su configuracin actual crontab en la pantalla, luego lista el archivo actual otra vez almacenando la salida dentro del archivo mycopy.
[hogan@station hogan]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.9212 installed on Wed Jun 18 11:46:36 2003) # (Cron version -- $Id: 040_crontab.dbk,v 1.1 2005/03/21 05:24:29 brads Exp $) # set the default language to be english. LOCALE=en_US 05 * * * * 15 04 * * * 25 04 1 * * 35 04 14 3 * julius 45 04 * * 1 [hogan@station procinfo find $HOME -size +100k echo "Pay your bills" echo "Beware the Ides of March" | mail -s "a warning" find $HOME -atime +30 | lpr hogan]$ crontab -l > mycopy

Luego, hogan quita su configuracin de crontab actual. Cuando trata de nuevo de listar la configuracin, se le informa que no existe ninguna configuracin actual.
[hogan@station hogan]$ crontab -r

54

Managing Processes
[hogan@station hogan]$ crontab -l no crontab for hogan

Con el fin de restaurar su configuracin cron, hogan utiliza el comando crontab una vez ms, esta vez especificando el archivo mycopy como un argumento. Tras listar su configuracin una vez ms, halla que su actual configuracin fue leda desde el archivo mycopy. Un poco molesto, el banner se ha duplicado en el proceso, sabe por qu?
[hogan@station hogan]$ crontab mycopy [hogan@station hogan]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (mycopy installed on Wed Jun 18 11:47:00 2003) # (Cron version -- $Id: 040_crontab.dbk,v 1.1 2005/03/21 05:24:29 brads Exp $) # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.9212 installed on Wed Jun 18 11:46:36 2003) # (Cron version -- $Id: 040_crontab.dbk,v 1.1 2005/03/21 05:24:29 brads Exp $) # set the default language to be english. LOCALE=en_US 05 * * * * 15 04 * * * 25 04 1 * * 35 04 14 3 * julius 45 04 * * 1 [hogan@station procinfo find $HOME -size +100k echo "Pay your bills" echo "Beware the Ides of March" | mail -s "a warning" find $HOME -atime +30 | lpr hogan]$ rm mycopy

Modificar archivos crontab ya establecidos Los usuarios suelen modificar sus archivos crontab mediante crontab -e. El comando crontab abrir la configuracin crontab dentro del editor predeterminado del usuario. Cuando el usuario termina de modificar el archivo y sale del editor, el contenido modificado del archivo se instala como la nueva configuracin crontab. El editor por defecto es /bin/vi, sin embargo,crontab, al igual que otros comandos, examina la variable de entorno EDITOR. Si la variable se ha establecido, se utilizar para especificar el editor que se va a abrir. Por ejemplo, si hogan prefiere utilizar el editor nano, primero puede configurar la variable de entorno EDITOR como /usr/bin/nano (o simplemente nano) y luego ejecutar crontab -e. Si hogan quisiera utilizar nano como su editor podra utilizar uno de los siguientes mtodos:
[hogan@station hogan]$ export EDITOR=nano [hogan@station hogan]$ crontab -e

55

Managing Processes
[hogan@station hogan]$ EDITOR=nano crontab -e

o an mejor, hogan pudo agregar la lnea "export EDITOR=nano" a su archivo .bash_profile y la variable de entorno se establecera automticamente cada vez que inicie sesin. En resumen, hay dos formas de crear o modificar la configuracin crontab. 1. Crear un archivo de texto que contenga su configuracin deseada y luego instalarlo con crontab FILENAME. 2. Editar su configuracin establecida con crontab -e. A dnde va la salida? Cmo recibe el usuario la salida de los comandos que cron ejecuta? El demonio enviar por correo la stdout y el stderr de todos los comandos ejecutados al usuario local. Suponga que ventura configur el siguiente trabajo cron:
05 * * * * cal

Una vez por hora, a la hora y cinco minutos espera recibir un nuevo correo como el siguiente:
Date: Wed, 18 Jun 2003 14:24:00 -0400 From: root@station.redhat.com (Cron Daemon) To: ventura@station.redhat.com Subject: Cron <ventura@station> cal X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/home/ventura> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=ventura> June 2003 Tu We Th Fr 3 4 5 6 10 11 12 13 17 18 19 20 24 25 26 27

Su 1 8 15 22 29

Mo 2 9 16 23 30

Sa 7 14 21 28

El mensaje del correo contiene la salida del comando en el cuerpo y todas las variables de entorno en los encabezados. Opcionalmente, ventura podra haber definido la variable de entorno especial MAILTO a una direccin de correo electrnico y el correo sera enviado a esa direccin en su lugar:
MAILTO=ventura@redhat.com 05 * * * * cal

56

Managing Processes Variables de entorno y cron Al configurar trabajos cron, los usuarios deberan tener en cuenta un detalle. Cuando el demonio crond inicia el comando del usuario, ste no ejecuta el comando desde la shell sino que bifurca y exec el comando directamente. Esto tiene una implicacin importante: cualquier variable de entorno o alias configurados por la shell en el arranque tal como cualquiera que est definida en /etc/profile o ~/.bash_profile, no estarn disponibles cuando cron ejecute el comando. Si un usuario quiere que una variable de entorno est definida necesita explcitamente definir la variable en su configuracin crontab. Ejemplos Control de un sitio web ventura quiere asegurarse que no se va a perder de ninguna nueva oportunidad de formacin de su compaa favorita, Red Hat Inc. Con el fin de estar pendiente de estas oportunidades configura un trabajo cron que descargar la pgina web de formacin de Red Hat y se la enviar como un correo electrnico una vez por la maana. Con el fin de modificar su configuracin en el lugar utiliza el comando crontab -e.
[ventura@station ventura]$ crontab -e no crontab for ventura - using an empty one

(... while in the text editor, ventura adds the following line...) 00 05 * * * links -dump http://www.redhat.com/training (... and quits the text editor...)

crontab: installing new crontab

Luego confirma que su trabajo cron est en su lugar.


[ventura@station ventura]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.10296 installed on Wed Jun 18 14:17:43 2003) # (Cron version -- $Id: 010_text.dbk,v 1.1 2005/03/21 05:24:29 brads Exp $) 00 05 * * * links -dump http://www.redhat.com/training

ventura ahora puede esperar recibir correo electonico, conteniendo una versin formateada de texto de la pgina web de formacin de Red Hat cada maana a las 5:00. Control de archivos grandes

57

Managing Processes Luego, ventura se da cuenta que ha tenido la mala costumbre de crear archivos muy grandes y luego los olvida. Con el fin de ayudarse a recordar los archivos grandes que est dejando atrs, configura un trabajo cron el cual le enviar cada domingo un correo con una lista de todos los archivos mayores de 100k.
[ventura@station ventura]$ crontab -e no crontab for ventura - using an empty one (... within the text editor, ventura adds the following line...) 05 05 * * 0 find $HOME -size +100k (... and exits the text editor ...)

crontab: installing new crontab [ventura@station ventura]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.10678 installed on Wed Jun 18 14:50:39 2003) # (Cron version -- $Id: 010_text.dbk,v 1.1 2005/03/21 05:24:29 brads Exp $) 00 05 * * * links -dump http://www.redhat.com/training 10 05 * * 0 find $HOME -size +100k

Ahora, los domingos a las 5:10 de la maana, ventura puede esperar recibir un correo electrnico listando todos los archivos mayores de 100 K bajo su directorio de inicio. Ejecucin de scripts desde cron Continuando con sus esfuerzos de no desperdiciar espacio duro, ventura deseara crear regularmente una lista separada de archivos a los que no haya tenido acceso recintemente y recibir esta lista al mismo tiempo que recibe su lista de archivos grandes. En lugar de complicar su archivo cron, crea un guin llamado cron.weekly, lo coloca en el subdirectorio bin y lo hace ejecutable.
[ventura@station ventura]$ cat cron.weekly #!/bin/bash echo "===== files larger than 100k =====" find $HOME -size +100k echo echo "==== files not used in the past month =====" find $HOME -atime +30 [ventura@station ventura]$ mkdir bin [ventura@station ventura]$ mv cron.weekly bin/ [ventura@station ventura]$ chmod 755 bin/cron.weekly

Luego, modifica su configuracin crontab para que su guin se ejecute como un trabajo cron una vez por semana:

58

Managing Processes
[ventura@station ventura]$ crontab -e (... within the text editor, ventura edits the following line ...) 05 05 * * 0 find $HOME -size +100k (... so that it reads ...) 05 05 * * 0 bin/cron.weekly (... and exits ...) crontab: installing new crontab [ventura@station ventura]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.11252 installed on Wed Jun 18 15:45:53 2003) # (Cron version -- $Id: 010_text.dbk,v 1.1 2005/03/21 05:24:29 brads Exp $) 00 05 * * * links -dump http://www.redhat.com/training 05 05 * * 0 bin/cron.weekly

Ahora en lugar de mantener su configuracin crontab, ventura puede apenas modifica el script cron.weekly. Impresin de fanmail El usuario hogan ha llegado al punto donde imprime el archivo que recoge la nueva correspondencia de los admiradores, fanmail.txt, cada lunes, mircoles y viernes. Decide utilizar el servicio cron para automatizar el proceso. Debido a que esta es la primera vez que utiliza cron, l no tiene que preocuparse por la posibilidad de remplazar trabajos ya existentes. Entonces configura un archivo cron localmente. Mediante un editor de texto, crea el archivo crontab.hogan en su directorio de inicio. Luego instala el archivo con el comando crontab.
[hogan@station hogan]$ cat crontab.hogan 45 13 * * 1,3,5 lpr fanmail.txt [hogan@station hogan]$ crontab crontab.hogan

Ahora espera que su archivo de correspondencia de sus admiradores sea impreso los lunes, mircoles y viernes en las tardes a la 1:45. Cuando se imprimen las primeras copias se envan a la impresora que no es, hogan nota que su .bash_profile configura su variable de entorno PRINTER para cola de espera local, hp-color, automticamente cuando inicia sesin. Sin embargo, como cron no utiliza una shell para ejecutar trabajos cron, la variable de entorno de inicio sesin no se est configurando. Edita crontab.hogan para definir explcitamente y vuelve a someter el archivo con crontab.
[hogan@station hogan]$ cat crontab.hogan PRINTER=hp-color 45 13 * * 1,3,5 lpr fanmail.txt

59

Managing Processes
[hogan@station hogan]$ crontab crontab.hogan

Ahora su trabajo imprime en la impresora correcta. Ejercicios en lnea Control de quin est en el sistema. Ejercicio en lnea Objetivo: Configurar un trabajo cron Estimated Time: 10 mins. Especificaciones Est un poco paranico y quiere controlar quin est usando su computador en la noche. Configura un trabajo cron que le enviar por correo la salida del comando who diariamente a las 4:35 de la maana. Deliverables Question 1

1. Una configuracin cron que enva por correo la salida del comando who diariamente a las 4:30 am.