9 managing processes

1

Managing Processes
Capítulo 1 Introducción a Procesos
Conceptos clave
•
•
•
•
•
•
•
•

Un proceso es una instancia de un ejecutable en ejecución identificado por un id
de proceso (pid).
Debido a que Linux implementa memoria virtual cada proceso posee su propio
contexto distintivo de memoria.
Un proceso tiene un uid y una colección de gid como credenciales.
Un proceso tiene un contexto de sistema de archivos incluyendo un cwd, una
umask, un directorio raíz y una colección de archivos abiertos.
Un proceso tiene un contexto de programación que incluye un valor de niceness.
Un proceso tiene una colección de variables de entorno.
El comando ps puede utilizarse para examinar todos los procesos actuales en
ejecución.
El comando top puede utilizarse para controlar todos los procesos en ejecución.

Los procesos tienen que ver con el cómo se hacen las cosas
Casi cualquier cosa que suceda en un sistema Linux tiene lugar como un proceso. Si
usted está viendo este texto en un navegador, ese navegador se está ejecutando como un
proceso. Si está tecleando en una línea de comandos de la shell bash, esa shell está
ejecutando como un proceso. Si está utilizando el comando chmod para cambiar un
permiso de un archivo, el comando chmod funciona como un proceso por separado. Los
procesos tienen que ver con el cómo se consigue hacer las cosas y la responsabilidad
principal del kernel de Linux es proporcionar un lugar para que los procesos ejerzan su
labor sin necesidad de tocar el campo del otro.
Los procesos son una instancia de un programa en funcionamiento. En otros sistemas
operativos los programas suelen ser grandes y elaboradas aplicaciones gráficas que se
toman una gran cantidad de tiempo para iniciar. En el mundo de Linux (y Unix), estos
tipos de programas también existen, al igual que toda una clase de programas que
usualmente no tienen una contraparte en los sistemas operativos. Estos programas están
diseñados para iniciar rápidamente, especializados en funciones y trabajan bien con
otros programas. En un sistema de Linux, los procesos que ejecutan estos programas
están constantemente apareciendo y desapareciendo. Por ejemplo, considere que el
usuario maxwell escribe la siguiente línea de comandos.
[maxwell@station maxwell]$ ps aux | grep httpd > daemons.$(date
+%d%b%y)

En una fracción de segundo que la línea de comandos utilizó para ejecutar, no menos de
cuatro procesos (ps, grep, bash y date) se iniciaron, hicieron lo que tenían que hacer y
salieron.
¿Qué es un proceso?

2

Managing Processes
En este momento ya estará cansado de escuchar la misma pregunta: un proceso en una
instancia de un programa en ejecución. No obstante, aquí ofrecemos una lista detallada
de componentes que constituyen un proceso.
Contexto de ejecución
Cada proceso existe (al menos hasta cierto punto) dentro de una memoria física
de la máquina. Puesto que Linux (y Unix) están diseñados para ser un entorno
multiusuario, la memoria asignada a un proceso está protegida y ningún otro
proceso puede acceder a ésta. Un proceso carga en su memoria una copia de las
instrucciones ejecutables y almacena cualquier otra información dinámica que
esté manejando. Un proceso también lleva parámetros asociados con la
frecuencia de acceso que se tiene a la CPU, tales como su estado de ejecución y
su valor de niceness (pronto hablaremos más en detalle sobre esto).
Contexto de E/S
Cada proceso interactúa hasta cierto punto con el sistema de archivos para leer y
escribir información que existe o existirá después del ciclo de vida del proceso.
Los elementos de entrada y salida (E/S) de un proceso incluyen lo siguiente:
Descriptores de archivo abierto
Casi todos los procesos suelen leer información de o escribir información a
fuentes externas. En Linux, los descriptores de archivos abiertos actúan como
fuentes o receptores de información. Los procesos leen información de o
escriben información a los descriptores de archivos abiertos que pueden estar
conectados a archivos regulares, nodos de dispositivos, conexiones de red o
incluso entre sí como tuberías (permitiendo la comunicación entre procesos).
Archivos de trazado de memoria
Los archivos de trazado de memoria son los archivos cuyo contenido se ha
trazado directamente en la memoria del proceso. En lugar de leer o escribir en
un descriptor de archivo, el proceso sólo accede a la dirección de memoria
apropiada. Los mapas de memoria suelen utilizarse para cargar el código
ejecutable, pero también sirven para otros tipos de acceso no secuencial a los
datos.
Contexto del sistema de archivos
Hemos encontrado varias partes de información relacionadas con el sistema de
archivos que mantiene los procesos, tales como el directorio de trabajo actual del
proceso (para traducir referencias de archivos) y la umask del proceso (para
establecer permisos en archivos recién creados). [1]
Variables de entorno

3

Managing Processes
Cada proceso mantiene su propia lista de pares nombre-valor, conocida como
variables de entorno o en general como el entorno del proceso. Los procesos por
lo general heredan su entorno en el inicio y pueden referirse a éste para obtener
datos tales como el lenguaje preferido o el editor favorito del usuario.
Información de herencia
Cada proceso se identifica con un PID o id del proceso asignado en el momento
de su creación. En una próxima lección, veremos que cada proceso tiene
claramente definido un padre y posiblemente unos hijos también. La identidad
del propio proceso, la identidad de sus hijos y hasta cierto punto la identidad de
sus hermanos son mantenidos por el proceso.
Credenciales
Cada proceso se ejecuta bajo el contexto de un determinado usuario (o más
exactamente de un id de usuario determinado) y bajo el contexto de una
colección de id de grupo (generalmente, todos los grupos a los que pertenezca el
usuario). Estas credenciales limitan los recursos a los que el proceso puede
acceder tales como qué archivos pueden abrir o con qué otros procesos se les
permite comunicarse.
Estadísticas de recursos y límites
Cada proceso también registra estadísticas para trazar la cantidad de recursos del
sistema utilizados, el número de archivos abiertos, la cantidad de tiempo de
CPU, etc. La cantidad de recursos que se le permite utilizar a un proceso
también puede limitarse con un concepto llamado límite de recursos.
Ver procesos con el comando ps
Ya hemos visto varias veces el comando ps. Ahora, trataremos de familiarizarnos con
una selección más amplia de opciones asociadas a éste. Una ejecución rápida de ps -help mostrará un resumen de más de 50 opciones diferentes para personalizar la
conducta del comando ps. las cosas se complican un poco porque diferentes versiones
de Linux han desarrollado sus propias versiones del comando ps, las cuales no utilizan
las mismas convenciones para las opciones. La versión de Linux del comando ps trata
de acomodarse a diferentes versiones anteriores de Unix y suele haber opciones
múltiples para cualquier opción determinada, algunas de las cuales comienzan con un
guión inicial (“-”).
Selección de procesos
De forma predeterminada, el comando ps lista todos los procesos iniciados desde una
terminal de usuario. Aunque esta conducta es razonable, cuando los usuarios están
conectados a cajas de UNIX con terminales seriales de línea, parece un poco simplista
cuando cada ventana de una terminal dentro de un entorno gráfico X se trata como una

4

Managing Processes
terminal independiente. Los siguientes modificadores de línea de comandos pueden
utilizarse para expandir (o reducir) los procesos listados por el comando ps .
Table 1. Opciones comunes del comando ps para la selección de procesos
Opción
-A, -e, ax

Procesos listados
Todos los procesos.

-C command

Todas las instancias de command

-U, --user, --User user Todos los procesos que pertenecen a user
-t, --tty terminal

Todos los procesos iniciados desde terminal

-p, p, --pid N

Procesos con pid N

Selección de salida
Como se deduce de los párrafos iniciales de esta lección hay muchos parámetros
asociados con procesos, demasiados para mostrar en una anchura estándar de terminal
de 80 columnas. El siguiente cuadro lista las opciones de línea de comando comunes
que se utilizan para seleccionar qué aspectos de un proceso se listan.
Table 1. Opciones comunes del comando ps para la selección de salida
Opción

Formato de la salida

-f

listado "completo"

-l, l

formato largo

-j, j

formato de trabajos

formato definido del usuario utilizando campos especificados por str
-o, o, -(campos disponibles para str se pueden listar con ps L o consultando la
formato str
página de manual ps(1)).
Además, las siguientes opciones pueden utilizarse para modificar la forma de presentar
la información.
Table 2. Opciones comunes del comando ps para dar formato a la salida
Opción
Formato de la salida
-H
Muestra la jerarquía del proceso
f, --forest Muestra la jerarquía de proceso incluyendo las representaciones ASCII
h

No imprime las líneas del encabezado

-w

salida "ancha" (incluye nombres de los comandos más largos)

5

Managing Processes
Rarezas del comando ps
El comando ps, posiblemente más que cualquier otro comando en Linux, tiene sus
rarezas asociadas con sus opciones. En la práctica, los usuarios tienden a experimentar
hasta encontrar combinaciones que les funcionen y luego se habitúan a ellas. Por
ejemplo, el autor prefiere el comando ps aux para propósitos generales de todos los
procesos, mientras que otros preferirían el comando ps -ef. El cuadro anterior ofrece
una "ayuda de trabajo" bastante buena para el principiante.
Las opciones de línea de comandos tienden a clasificarse en dos categorías, aquellas con
el tradicional guión inicial (opciones de estilo "Unix98") y otras sin (opciones de estilo
"BSD"). A menudo, una funcionalidad determinada se representa por una de cada una
de ellas. Al agrupar opciones de una sola letra, sólo pueden agruparse opciones del
mismo estilo. Por ejemplo, ps axf es lo mismo que ps a x f, pero diferente de ps a x -f.
Control de procesos con el comando top
El comando ps muestra estadísticas para procesos especificados en el momento que se
ejecuta el comando, proporcionando una instantánea de una instancia en tiempo. En
contraste, el comando top sirve para controlar el estado general de los asuntos de
procesos en la máquina.
Se espera que el comando top se ejecute desde dentro de una terminal. Éste remplazará
la línea de comandos por una tabla de los actuales procesos en ejecución, el cual se
actualiza a cada instante. A continuación se muestra la pantalla de un usuario después
de ejecutar el comando top.
17:46:38 up 4:28, 7 users, load average: 0.07, 0.02, 0.00
101 processes: 100 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:
3.4% user
1.0% system
0.0% nice
0.0% iowait
idle
Mem:
255232k av, 232796k used,
22436k free,
0k shrd,
32404k buff
146208k actv,
33884k in_d,
4716k in_c
Swap: 522104k av,
88368k used, 433736k free
104280k cached
PID USER
PRI
COMMAND
1150 einstein 15
metacity
1186 einstein 15
battstat-appl
3057 einstein 15
galeon-bin
3622 maxwell
22
1 root
15
2 root
15
keventd
3 root
15
kapmd

NI

SIZE

RSS SHARE STAT %CPU %MEM

95.4%

TIME CPU

0

4468 4108

2252 S

2.9

1.6

0:51

0

0

3132 2112

1436 S

0.9

0.8

0:04

0

18M 12356 S

0.9

7.5

0:06

0

856 R
52 S
0 SW

0.9
0.0
0.0

0.4
0.0
0.0

0:00
0:04
0:00

0 top
0 init
0

0 SW

0.0

0.0

0:00

0

0 19596
0
0
0
0

1088 1088
108
76
0
0
0

0

6

Managing Processes
4 root
ksoftirqd_CPU
9 root
bdflush
5 root
kswapd
6 root
kscand/DMA
7 root
kscand/Normal
8 root
kscand/HighMe
10 root
kupdated
11 root
mdrecoveryd
15 root
kjournald

34

19

0

0

0 SWN

0.0

0.0

0:00

0

25

0

0

0

0 SW

0.0

0.0

0:00

0

15

0

0

0

0 SW

0.0

0.0

0:00

0

15

0

0

0

0 SW

0.0

0.0

0:00

0

15

0

0

0

0 SW

0.0

0.0

0:06

0

15

0

0

0

0 SW

0.0

0.0

0:00

0

15

0

0

0

0 SW

0.0

0.0

0:00

0

25

0

0

0

0 SW

0.0

0.0

0:00

0

15

0

0

0

0 SW

0.0

0.0

0:01

0

Mientras el comando está ejecutándose, el teclado está "vivo". En otras palabras, el
comando top responderá a pulsaciones sin esperar a la tecla enter. El siguiente cuadro
lista algunas de las teclas más utilizadas.
Table 1. Comandos top más utilizados
Comando

Presionar tecla
q

quit

ho?

ayuda

s

establecer el retraso entre las actualizaciones (en segundos)

space

mostrar actualización

M

Clasificar procesos por tamaño de memoria

P

Clasificar procesos por actividad de la CPU (procesador)

u

Reducir procesos visualizados pertenecientes a un usuario específico

k

Matar un proceso (enviar una señal a un proceso)

r

renice un proceso

Los últimos dos comandos, los cuales pueden matar o renice un proceso utilizan
conceptos que cubriremos con más detalle en una próxima lección.
Aunque por lo general top funciona sin la configuración de línea de comandos es
compatible con las siguientes opciones:
Table 2. Opciones para el comando top
Opción
-d

Efecto
Demora segundos segundos entre actualizaciones (por defecto = 5

7

Managing Processes
Opción

Efecto

segundos

segundos).

-q

Actualiza tan pronto como sea posible.

-n N

Se ejecuta para iteraciones N, luego sale.

-b

Se ejecuta en "modo por lote" simplemente como si escribiera a una
terminal tonta.

Procesos de control con la aplicación gnome-system-monitor
Si se ejecuta un servidor X, el entorno de escritorio de GNOME proporciona una
aplicación similar en función a top con los beneficios (y problemas) de una aplicación
gráfica. La aplicación se puede iniciar desde una línea de comandos como gnomesystem-monitor o desde el menú de aplicaciones predeterminado, seleccionando
Herramientas: monitor del sistema.
Figure 1. Monitor del sistema GNOME
Al igual que el comando top, la aplicación Monitor del sistema presenta una lista de
procesos ejecutándose en la máquina local, actualizando la lista cada pocos segundos.
En su configuración por defecto, la aplicación Monitor del sistema provee una interfaz
mucho más simple: lista sólo los procesos pertenecientes al usuario que inició la
aplicación y reduce el número de columnas a la memoria del comando del proceso, el
propietario, ID de proceso, las medidas simples de la memoria del proceso y la
utilización de la CPU. Los procesos pueden clasificarse por cualquiera de estos campos
con un sólo clic en el título de la columna.
En la esquina superior derecha de la ventana, un menú emergente permite al usuario
escoger entre desplegar todos los procesos pertenecientes al usuario (por defecto) o sólo
los procesos en el estado de "ejecución".
Cuando se hace click derecho en un proceso, un menú emergente permite al usuario
realizar muchas de las acciones que top le permitió, tales como reniciar o matar un
proceso a través de una interfaz más sencilla (y no tan flexible).
Figure 2. Haciendo click derecho en un proceso en el Monitor del sistema GNOME
El Monitor del Sistema puede configurarse abriendo el menú de
selecciónEditor:Preferencias. Dentro del diálogo de Preferencias, el usuario puede
establecer el intervalo de actualización (en segundos) y configurar muchos más campos
para ser visualizados.
Figure 3. Campos de configuración en el monitor de sistema GNOME

8

Managing Processes
Por último, el Monitor de Sistema provee un segundo panel, el cual muestra gráficas de
todo el uso de la CPU y de la memoria versus tiempo y un cuadro de uso del disco
(esencialmente la salida del comando df).
Figure 4. Panel del monitor de sistema GNOME

Localización de procesos con el comando pgrep.
A menudo, los usuarios tratan de localizar información acerca de procesos identificados
por el comando que están ejecutando o el usuario que está ejecutándolos. Una técnica es
listar todos los procesos y utilizar el comando grep para reducir la información. A
continuación, maxwell primero busca todas las instancias del demonio sshd y luego
busca los procesos pertenecientes al usuario maxwell.
[maxwell@station maxwell]$ ps aux | grep sshd
root
829 0.0 0.0 3436
4 ?
S
/usr/sbin/sshd
maxwell
2200 0.0 0.2 3572 640 pts/8
S
sshd
[maxwell@station maxwell]$ ps aux | grep maxwell
root
2109 0.0 0.3 4108 876 pts/8
S
maxwell
maxwell
2112 0.0 0.4 4312 1268 pts/8
S
maxwell
2146 1.4 8.3 89256 21232 pts/8
S
/usr/lib/mozillamaxwell
2201 0.0 0.2 2676 724 pts/8
R
maxwell
2202 0.0 0.2 3576 644 pts/8
S
maxwell

09:13

0:00

10:10

0:00 grep

10:05

0:00 su -

10:05
10:05

0:00 -bash
0:04

10:10
10:10

0:00 ps aux
0:00 grep

Aunque maxwell puede encontrar la información que necesita hay algunos aspectos no
muy agradables.
1. El método no es exacto. Observe que, en la segunda búsqueda, apareció un
proceso su no porque le perteneciera a maxwell, sino porque la palabra maxwell
era uno se sus argumentos.
2. Igualmente, el comando grep suele aparecerse en la salida.
3. El comando compuesto puede ser complicado de teclear.
El comando pgrep fue creado para tratar estos problemas. pgrep permite a los usuarios
listar rápidamente procesos por nombre de comando, usuario, terminal o grupo.
pgrep

[OPCIONES] [PATRÓN]

Su argumento opcional, si se suministra, se interpreta como un patrón de expresión
regular extendido coincidente con nombres de comando. Las siguientes opciones
también pueden utilizarse para clasificar la búsqueda.

9

Managing Processes
Table 1. Opciones comunes para especificar el criterio de selección del proceso
pgrep.
Opción
Efecto
-n
Selecciona únicamente los procesos coincidentes iniciados más recientemente.
-u USER Selecciona procesos pertenecientes al usuario USER.
-t TERM Selecciona procesos controlados por terminal TERM.
Además, la siguiente opción puede utilizarse para modificar el formato de la salida del
comando.
Table 2. Opciones comunes para especificar el formato de salida pgrep
Opción

Efecto

delimitador

Usa delimitador para delimitar cada ID de proceso (por defecto se
utiliza una nueva línea).

-l

Lista el nombre del proceso y el ID del proceso.

-d

Para una lista completa de opciones consulte la página de manual pgrep(1).
A manera de ejemplo, maxwell repetirá dos listados del proceso anterior mediante el
comando pgrep. [1]
[maxwell@station maxwell]$ pgrep -l sshd
829 sshd
[maxwell@station maxwell]$ pgrep -lu maxwell
2112 bash
2146 mozilla-bin
2155 mozilla-bin
2156 mozilla-bin
2157 mozilla-bin

Ejemplos
Ver todos los procesos con el formato de "usuario orientado"
En la siguiente transcripción, maxwell utiliza el comando ps -e u para listar todos los
procesos (-e) con el formato de "usuario orientado" (u).
[maxwell@station maxwell]$ ps -e u
USER
PID %CPU %MEM
VSZ RSS
root
1 0.0 0.0 1380
76
root
2 0.0 0.0
0
0
[keventd]
root
3 0.0 0.0
0
0
...

TTY
?
?

STAT START
S
Oct12
SW
Oct12

TIME COMMAND
0:04 init [
0:00

?

SW

0:00 [kapmd]

Oct12

10

Managing Processes
root
174 0.0
[kjournald]
root
250 0.0
/sbin/mingetty tt
root
496 0.0
/sbin/dhclient -1
root
566 0.0
-m 0
root
570 0.0
x
rpc
588 0.0
...
maxwell
4202 0.0
nautilus --no-def
maxwell
4204 0.0
magicdev --sm-cli
maxwell
4207 0.0
--sm-clie
maxwell
4210 0.0
panel-icon -maxwell
4212 0.1
/usr/bin/python /
root
4213 0.0
/sbin/pam_timesta
maxwell
4220 0.0
/usr/libexec/noti
maxwell
4293 2.4
system-moni
apache
5048 0.0
/usr/sbin/httpd
...
maxwell 13166 0.7
maxwell 13200 0.0

0.0

0

0 ?

SW

Oct12

0:00

0.0

1356

4 tty2

S

Oct12

0:00

0.1

2104

448 ?

S

Oct12

0:00

0.0

1448

160 ?

S

Oct12

0:00 syslogd

0.0

1376

164 ?

S

Oct12

0:00 klogd -

0.0

1548

104 ?

S

Oct12

0:00 portmap

1.3 57948 3400 ?

S

Oct12

0:02

0.1 16392

436 ?

S

Oct12

0:00

0.5 16784 1500 ?

S

Oct12

0:00 eggcups

0.3 11596

988 ?

S

Oct12

0:00 pam-

0.8 24464 2152 ?

S

Oct12

0:41

0.0

136 ?

S

Oct12

0:00

0.3 17024 1012 ?

S

Oct12

0:00

1.4 18356 3760 ?

S

Oct12

0.6 18424 1776 ?

S

Oct12

0:00

0.5
0.2

S
R

07:35
07:35

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

1416

4304 1392 pts/5
2696 744 pts/5

15:28 gnome-

El "usuario orientado"muestra el usuario que está ejecutando el proceso, el id de
proceso y una estimación aproximada de la cantidad de CPU y memoria que el proceso
está consumiendo como también el estado del proceso. (los estados de procesos se
tratarán en una próxima lección).
Ver los procesos de un usuario con el formato "largo"
En la siguiente transcripción, maxwell utiliza el comando ps -U maxwell l para listar
todos sus procesos (-U maxwell) con el formato "largo " (l).
[maxwell@station maxwell]$ ps -U maxwell l
F
UID
PID PPID PRI NI
VSZ RSS WCHAN
COMMAND
4
515 4132 1062 15
0 18632
4 schedu
/usr/bin/gnom
1
515 4175 4132 15
0 3068
72 schedu
/usr/bin/ssh0
515 4180
1 15
0 11384 776 schedu
/usr/libexec/
0
515 4182
1 15
0 6364
4 schedu
/usr/libexec/

STAT TTY

TIME

S

?

0:02

S

?

0:00

S

?

0:00

S

?

0:00

11

Managing Processes
0
515 4184
1
gnome-setting
0
515 4193
1
xscreensaver
0
515 4196
1
/usr/bin/meta
0
515 4200
1
gnome-panel 0
515 4202
1
nautilus --no
0
515 4204
1
magicdev --sm
0
515 4207
1
eggcups --sm0
515 4210
1
pam-panel-ico
0
515 4212
1
/usr/bin/pyth
0
0 4213 4210
/sbin/pam_tim
0
515 4220
1
/usr/libexec/
0
515 4293
1
gnome-system4
515 13166 13163
bash
0
515 13201 4193
pulsar -root
0
515 13265 13166
-U maxwell

15

0 17336

4 schedu S

?

0:00

15

0

620 schedu S

?

0:00

15

0 12816 1884 schedu S

?

0:08

15

0 21160 3340 schedu S

?

0:05

15

0 57948 3192 schedu S

?

0:02

15

0 16392

424 schedu S

?

0:00

15

0 16784 1348 schedu S

?

0:00

15

0 11596

908 schedu S

?

0:00

15

0 24464 2152 schedu S

?

0:43

15

0

1416

136 schedu S

?

0:00

15

0 17024

756 schedu S

?

0:00

15

0 18356 3760 schedu S

?

15:43

15

0

pts/5

0:00 -

25

10

6676 2592 schedu SN

?

0:00

20

0

3140 1188 -

pts/5

0:00 ps

3728

4304 1388 wait4

S

R

El formato largo se enfoca en parámetros de programación, tales como la prioridad y el
niceness del proceso, los cuales se tratarán más adelante.
Ver un comando determinado con el formato "trabajo orientado"
En la siguiente transcripción, maxwell utiliza el comando ps -C bash j para listar todas
las instancias del comando bash (-C bash) con el formato de "trabajo orientado" (j).
[maxwell@station maxwell]$ ps -C bash j
PPID
PID PGID
SID TTY
TPGID STAT
1184 2311 2311 2311 pts/4
2311 S
1184 2565 2565 2565 pts/0
2565 S
1184 2757 2757 2757 pts/2
2757 S
1184 3024 3024 3024 pts/3
3052 S
1184 3348 3348 3348 pts/6
3348 S
1184 6033 6033 6033 pts/5
13414 S
1184 6534 6534 6534 pts/8
6534 S
13163 13166 13166 6033 pts/5
13414 S

UID
2291
2291
2291
2291
2291
2291
2291
515

TIME
0:01
0:04
0:00
0:00
0:00
0:00
0:00
0:00

COMMAND
bash
bash
bash
bash
bash
bash
bash
-bash

El formato de trabajo orientado se enfoca en los procesos padre, grupos de proceso,
grupos de sesión y terminales de control. Muchos de estos conceptos se discutirán más
tarde en otros cuadernos.

12

Managing Processes
Intrigado porque el proceso padre de muchas de estas shells parece ser el proceso ID
1184, maxwell continúa examinando ese proceso individual.
[maxwell@station maxwell]$ ps u 1184
USER
PID %CPU %MEM
VSZ RSS TTY
einstein 1184 0.2 3.3 26900 8660 ?
/usr/bin/gnome-te

STAT START
S
Oct12

TIME COMMAND
2:51

Aparentemente, todas las shells bash se iniciaron desde dentro de una gnome-terminal.
Ver procesos con el formato personalizado
Intrigado por ver los aspectos que un proceso puede visualizar con el comando ps,
maxwell utiliza ps L para listar los posibles encabezados.
[maxwell@station maxwell]$ ps L
%cpu
%CPU
%mem
%MEM
alarm
ALARM
args
COMMAND
blocked
BLOCKED
bsdstart
START
bsdtime
TIME
c
C
...
vsize
VSZ
vsz
VSZ
wchan
WCHAN

Intrigado por el campo alarm, maxwell desea ver los procesos que tienen alarmas
pendientes. Utiliza la opción -o para listar todas las alarmas pendientes y comandos.
[maxwell@station maxwell]$ ps -e -o alarm,cmd
ALARM CMD
- init [
- [keventd]
- [kapmd]
...
30.00 syslogd -m 0
...

Observando que todas las entradas "interesantes" comienzan con números, maxwell
utiliza el comando grep para reducir su salida a líneas que comienzan con cualquier
número o espacio pero cuyo primer caracter de no espacio sea un dígito.
[maxwell@station maxwell]$ ps -e -o alarm,cmd | grep "^ *[0-9]"
30.00 syslogd -m 0
15.00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc
3600 /usr/sbin/sshd
3600 sendmail: accepting connections
3600 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
300 /usr/bin/gdm-binary -nodaemon
10.00 /usr/bin/ssh-agent /etc/X11/xinit/Xclients

13

Managing Processes
10.00 /usr/bin/ssh-agent /etc/X11/xinit/Xclients

Estas son las utilidades que piden ser notificadas cada 15 minutos, cada hora, etc.,
presumiblemente para sondear alguna actividad.
Ejercicios en línea
Lab Exercise
Objetivo: Ver la información sobre los procesos
Tiempo estimado: 20 minutos.
Especificaciones
Con el fin de tener un conjunto fijo de procesos para examinar, usted debe tomar una
instantánea de todos los procesos actuales en su máquina. Utilice la siguiente secuencia
de comandos para capturar primero los encabezados de las columnas del comando ps
aux dentro de un archivo llamado snapshot. Luego vuelva a ejecutar el comando ps
aux, eliminando el encabezado y clasificando el resto de la salida de acuerdo al tamaño
de la memoria virtual de cada proceso. La lista clasificada de procesos se agregará luego
al encabezado previamente capturado en el archivo snapshot.
Es más fácil de lo que parece.
[student@station student]$ ps aux | head -1 > snapshot
[student@station student]$ ps aux | tail +2 | sort -rn -k4 >> snapshot
[student@station student]$ head -5 snapshot
USER
PID %CPU %MEM
VSZ RSS TTY
STAT START
TIME COMMAND
einstein 3057 0.2 7.4 97088 18932 ?
S
Oct12
2:01
/usr/bin/galeonroot
1063 14.3 6.2 36528 15936 ?
S
Oct12 163:48
/usr/X11R6/bin/X
einstein 1184 0.2 3.8 27160 9868 ?
S
Oct12
3:00
/usr/bin/gnome-t
einstein 1164 0.0 3.0 27856 7792 ?
S
Oct12
0:11
/usr/bin/python

Utilice su archivo de snapshot para contestar las siguientes preguntas.
1. En el archivo ~/biggest.pid almacene el ID de proceso del proceso con el
mayor tamaño de memoria virtual (la columna VSZ).
2. Experimente con el comando cut, hasta que pueda extraer la letra inicial de la
columna del campo STAT. Esta estará llena casi exclusivamente de letras “R” y
“S”, lo que implica que está en estado de ejecución o dormido. Grabe esta
columna extraída (a excepción del encabezado) dentro de un archivo llamado
~/pstates.txt.
3. Utilice el comando grep, quizás con el comando wc para determinar el número
de instancias en ejecución del programa /sbin/mingetty. Almacene la
pregunta como un sólo número en el archivo ~/nmingetty.txt.

14

Managing Processes
4. Utilice el comando grep, quizás con el comando wc, para determinar la cantidad
de procesos en ejecución como usuario root. Almacene la respuesta como un
sólo número en el archivo ~/nroot.txt.
5. Inicie el comando top en una terminal y déjelo ejecutando mientras califica su
ejercicio.
No modifique ni suprima su archivo snapshot hasta no haber terminado de calificar su
ejercicio.
Deliverables
Question 1

1. El archivo ~/biggest.pid que contiene el ID de proceso del proceso con la
memoria virtual más grande.
2. El archivo ~/pstates.txt que contiene la columna extraída de los estados de
proceso, a excepción de la línea de encabezado.
3. El archivo ~/nmingetty.txt que contiene el número de instancias del
programa /sbin/mingetty ejecutándose en su máquina.
4. El archivo ~/nroot.txt que contiene el número de procesos ejecutándose como
el usuario root de la máquina.
5. Una instancia en ejecución del comando top.

Capítulo 2 Estados del proceso
Conceptos clave
•

•
•

•
•
•
•

En Linux, el primer proceso, /sbin/init, lo inicia el kernel en el arranque. Todos
los demás procesos son el resultado de un proceso padre que se duplica o
bifurca.
Un proceso comienza a ejecutar un nuevo comando a través de un proceso
llamado execing.
Los nuevos comandos suelen ejecutarse mediante un proceso (a menudo una
shell) primero mediante una bifurcación y luego ejecutando un nuevo comando.
Este mecanismo se conoce como el mecanismo fork y exec.
Los procesos siempre pueden encontrarse en uno de los cinco estados:
ejecutable, dormido voluntario, dormido involuntario, detenido o zombi.
La ascendencia del proceso puede verse con el comando pstree.
Cuando un proceso muere, el padre del proceso debe recolectar su información
del código de retorno y del uso de recursos.
Cuando un padre muere antes que sus hijos, el primer proceso hereda los
huérfanos (usualmente /sbin/init).

15

Managing Processes

Ciclo de vida de un proceso
Cómo se inician los procesos
En Linux (y Unix), a diferencia de muchos otros sistemas operativos, la creación de
proceso y la ejecución de comandos son conceptos separados. Aunque un nuevo
proceso es creado para que pueda ejecutarse en un comando especificado (tal como la
shell bash creando un proceso para ejecutar el comando chmod), los procesos pueden
crearse sin ejecutar un nuevo comando y los nuevos comandos pueden ejecutarse sin
crear un nuevo proceso.
Creación de un nuevo proceso (forking)
Los nuevos procesos se crean mediante una técnica llamada forking. Cuando un
proceso se bifurca, crea un duplicado de sí mismo. Inmediatamente después de
una bifurcación, el proceso recién creado (el hijo) es un duplicado exacto del
proceso original (el padre). El hijo hereda una copia idéntica de la memoria del
proceso original, los archivos abiertos de padre, copias idénticas de los
parámetros del padre, tales como el directorio de trabajo actual o umask. La
única diferencia entre el padre y el hijo es la información heredada del hijo (el
hijo tiene un ID de proceso diferente y un proceso de padre diferente, para los
principiantes), y (para los programadores en la audiencia) el valor de retorno de
la llamada al sistema fork().
Como un aparte rápido para los programadores en la audiencia, un fork suele
implementarse mediante una estructura similar a la siguiente:
int rc, child_pid;
rc = fork();
if (rc == -1) { perror("bad fork"); }
else if (rc == 0) { do_child(); }
else {
child_pid = rc;
do_parent(child_pid);
}

Cuando un proceso desea crear un nuevo proceso, acude al sistema de llamado
fork() (sin argumentos). Aunque sólo un proceso entra en el llamado fork(), dos
procesos retornan. Para el proceso recién creado (el hijo), el valor de retorno es
0. Para el proceso original (el padre), el valor de retorno es el ID del proceso de
hijo. Al bifurcar este valor, el hijo puede ahora salir a hacer cualquier cosa que
hubiera empezado a hacer (que suele involucrar exec(), ver lo siguiente) y el
padre puede continuar haciendo sus cosas.
Ejecución de un nuevo comando (Execing)

16

Managing Processes
Los nuevos comandos se ejecutan a través de un técnica llamada execing
(acortamiento en inglés para executing). Cuando se ejecuta un nuevo comando,
el proceso actual borra y libera la mayoría de sus recursos y carga una nueva
colección de instrucciones desde el comando especificado en el sistema de
archivos. La ejecución inicia con el punto de entrada del nuevo programa.
Después de utilizar ejecutar un nuevo comando, el nuevo comando todavía es el
mismo proceso. Tiene el mismo ID de proceso y muchos de los mismos
parámetros (tales como su utilización de recursos, la umask y el directorio actual
de trabajo). Apenas olvida su comando anterior y adopta uno nuevo.
De nuevo para algunos programadores, la ejecución de un nuevo comando se
realiza mediante una o varias variantes de la llamada al sistema execve() tal
como la llamada de la biblioteca execl().
rc = execl("chmod", "chmod 755 /etc/passwd");
perror("bad exec");

El proceso escribe la llamada execl(...), especificando el nuevo comando que se
va a ejecutar. Si todo sale bien, la llamada execl(...) nunca retorna. En su lugar,
la ejecución se realiza en el punto de entrada (por ejemplo, main()) del nuevo
programa. Si por la misma razón execl(...) retorna, debe ser un error (tal como
no poder localizar el ejecutable del comando en el sistema de archivos).
Combinación de dos: Fork y Exec
Algunos de los programas pueden utilizar fork sin ejecutar un nuevo comando.
Ejemplos incluyen demonios de red, que bifurcan un nuevo hijo para manejar
una conexión de un cliente específico, mientras el padre retorna para escuchar
nuevos clientes. Otros programas podrían utilizar exec sin bifurcación. Ejemplos
incluyen al comando login, el cual se convierte en la shell de inicio de sesión del
usuario después de confirmar la contraseña del usuario. Sin embargo, para las
shells en particular, fork y exec suelen ir de la mano. Cuando se ejecuta un
comando, la shell bash primero bifurca una nueva shell bash. Luego, el hijo
ejecuta el nuevo comando apropiado, mientras que el padre espera que el hijo
muera para generar un nuevo intérprete de comandos.
El linaje de los procesos (y el comando pstree)
Tras el arranque del sistema, una de las responsabilidades del sistema del Kernel de
Linux es iniciar el proceso por primera vez (usualmente/sbin/init). Todos los otros
procesos son iniciados porque se bifurcó un proceso ya existente.[1]
Debido a que cada proceso a excepción del primero se crea por bifurcación, dentro de
los procesos existe un linaje bien definido de relaciones padre e hijo. El primer proceso
iniciado por el kernel inicia fuera del árbol de familia, el cual puede examinarse con el
comando pstree.

17

Managing Processes
[maxwell@station maxwell]$ pstree
init-+-apmd
|-atd
|-automount
|-battstat-applet
...
|-evolution-execu
|-evolution-mail
|-fetchmail
|-galeon-bin
|-gconfd-1
|-2*[gconfd-2]
|-gdm-binary-+-gdm-binary-+-X
|
|
`-gnome-session---ssh-agent
|
`-gdm-binary---gnome-session---ssh-agent
|-2*[gnome-panel]
|-2*[gnome-settings-]
|-gnome-system-mo
|-gnome-terminal-+-3*[bash]
|
|-bash---man---sh---sh---less
|
|-bash---mutt
|
|-bash---su---bash---pstree
|
`-gnome-pty-helpe
|-gpm
|-gvim
|-httpd---11*[httpd]
|-kapmd
|-keventd
|-khubd
...

Cómo muere un proceso
Cuando un proceso muere ya sea que muera normalmente seleccionando exit o
anormalmente como el resultado de recibir una señal. Aquí tratamos la salida normal del
proceso, dejando para más adelante la discusión acerca sobre la señales.
Hemos mencionado anteriormente que los procesos dejan atrás un código de estatus
cuando mueren (también llamado valor de retorno) en la forma de un número entero,
(recuerde la shell bash que utiliza la variable $? para almacenar el valor de retorno del
comando ejecutado previamente). Cuando un proceso sale, todos sus recursos se
liberan, a excepción del código de retorno (y alguna información de utilización de
recursos contables). Es responsabilidad del padre del proceso coleccionar esta
información y liberar los últimos recursos del hijo muerto. Por ejemplo, cuando la shell
se bifurca y exec el comando chmod, es responsabilidad de la shell bash padre recoger
el valor de retorno del comando cerrado chmod.
Huérfanos
Si es responsabilidad de los padres limpiar después de sus hijos, ¿qué sucede si el padre
muere antes que el hijo? El hijo queda huérfano. Una de las responsabilidades
especiales del primer proceso iniciado por el kernel es "adoptar" huérfanos, (observe
que en la salida del comando pstree, el primer proceso tiene un número

18

Managing Processes
desproporcionado de hijos. La mayoría de estos fueron adoptados como huérfanos de
otros procesos).
Zombis
Entre el momento en que un proceso sale, liberando la mayoría de sus recursos, y el
momento en que su padre recoge su valor de retorno, liberando el resto de sus recursos,
el proceso hijo se encuentra en un estado especial conocido como Zombi. Cada proceso
pasa a través de un estado transitorio zombi. Los usuarios tienen que estar mirando justo
en el momento preciso (con el comando ps, por ejemplo) para ver un zombi. Ellos se
aparecen en la lista de procesos, pero no ocupan memoria, ni tiempo de CPU, ni ningún
otro sistema de recursos. Ellos son sólo la sombra de un proceso anterior esperando que
su padre llegue y los termine.
Padres negligentes y zombis de larga vida
Ocasionalmente, los procesos padres pueden ser descuidados. Comienzan procesos hijos
pero nunca regresan a limpiar lo que dejan. Cuando esto ocurre (usualmente debido a un
error de programador), el hijo puede salir, entrar en estado zombi y quedarse ahí. Esto
suele suceder cuando los usuarios son testigos de procesos zombis mediante el comando
ps, por ejemplo.
Deshacerse de zombis es quizás el concepto básico más incomprendido de Linux (y
Unix). Mucha gente dirá que no hay forma de deshacerse de ellos, excepto volviendo a
arrancar la máquina. ¿Sabe cómo deshacerse de zombis de larga vida utilizando las
claves tratadas en esta sección?
Los 5 estados del proceso
La sección anterior trató la manera como se inician y mueren los procesos. Mientras los
procesos están vivos, siempre están en uno de los cinco estados del proceso, los cuales
efectúan el cómo y cuándo tienen acceso a la CPU. El siguiente listado muestra los
cinco estados, junto con la letra convencional utilizada por ps, top y otros comandos
para identificar el estado actual de un proceso.
Ejecutable (R)
Los procesos en un estado ejecutable son procesos que si tienen la oportunidad
de acceder la CPU, la aprovecharían. Los procesos múltiples suelen estar en un
estado de ejecución, pero como sólo puede ejecutarse un proceso en la CPU en
determinado tiempo, sólo uno de estos procesos en realidad estará ejecutándose
en un momento dado. Puesto que los procesos de ejecución entran y salen de la
CPU tan rápidamente en el sistema de Linux, parece como si todos los procesos
se estuvieran ejecutando de manera simultánea. [1]
Dormido voluntario (interrumpible) (S)

19

Managing Processes
Como el nombre lo implica, un proceso que está dormido voluntario ha elegido
estar así. Por lo general, este es un proceso que no tiene nada que hacer hasta
que suceda algo interesante. Un ejemplo clásico es el demonio de red httpd, el
cual es un proceso que implementa un servidor de red. En medio de solicitudes
de un cliente (navegador de red), el servidor no tiene nada que hacer, y elige irse
a dormir. Otro ejemplo sería el comando top, que lista procesos cada cinco
segundos. Mientras espera que pasen los cinco segundos, se duerme
voluntariamente. Cuando el proceso esté interesado en que algo suceda (tal
como cuando el cliente de red hace una solicitud o los cinco segundos expiran),
el proceso dormido vuelve al estado ejecutable.
Dormido involuntario (no interrumpible) (D)
En ocasiones, dos procesos tratan de acceder el mismo recurso de sistema al
mismo tiempo. Por ejemplo, un proceso trata de leer de un bloque o un disco
mientras que el bloque está siendo escrito debido a otro proceso. En estas
situaciones, el kernel fuerza al proceso a dormir. El proceso no eligió dormir,
éste hubiera preferido ser ejecutable para poder hacer las cosas. Cuando el
recurso es liberado, el kernel pondrá el proceso de nuevo en su estado
ejecutable.
Aunque los procesos están constantemente durmiendo involuntariamente, no
suelen estarlo por mucho tiempo. Como resultado, los usuarios no suelen ver los
procesos en dormido involuntario, excepto en sistemas ocupados.
Procesos detenidos (suspendidos) (T)
Ocasionalmente, los usuarios deciden suspender procesos. Los procesos
suspendidos no realizarán ninguna acción hasta no ser reiniciados por el usuario.
En la shell bash, la secuencia de teclas CONTROL-Z puede utilizarse para
suspender un proceso. En programación, los depuradores suelen suspender los
programas que están depurándose cuando ciertos eventos suceden (como cuando
se producen puntos de interrupción).
Procesos zombi (Z)
Como lo mencionamos antes, cada proceso muriendo pasa a través de un estado
zombi transitorio. No obstante, en ocasiones, algunos se quedan en ese estado.
Los procesos zombis han terminado de ejecutar, han liberado toda su memoria y
casi todos sus recursos. Dado que no están consumiendo recursos, son poco más
que una molestia que puede aparecer en listados de procesos.
Ver estados de procesos
Cuando se ve la salida de comandos tales como ps y top, los estados de procesos suelen
enumerase bajo el encabezado STAT. El proceso es identificado por una de las
siguientes letras:

20

Managing Processes
•
•
•
•
•

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

Ejemplos
Identificación de estados de procesos
[maxwell@station
F
UID
PID
COMMAND
100
0
1
init
100
500 4248
bash
100
500 4292
bash
004
0 1829
updatedb
004
0 1827
updatedb
000
500 4333
vim proj1_s
000
500 4334
top
004
501 5486
[netstat
000
501 5793
vim c
000
501 5798
/bin/bash 040
501 5799
/bin/bash 000
501 5800
ps -alx
000
501 5801
tail

maxwell]$ ps -alx
PPID PRI NI
VSZ

RSS WCHAN

STAT TTY

0

15

0

1344

775

15

0

4136 1412 wait4

S

tty3

0:00 -

776

15

0

4144 1420 schedu S

tty4

0:00 -

1774

17

0

1472

528 down

D

1774

16

0

1464

520 -

R

4292

15

0

7612 2616 do_sig T

4248

15

0

3612 1052 schedu S

1220

16

0

2600

15

0

7708 2816 wait4

S

pts/0

0:00

5793

16

0

3804

944 wait4

S

pts/0

0:00

5798

17

0

3808 1000 wait4

S

pts/0

0:00

5799

17

0

3148 1240 -

R

5799

17

0

3144

0

436 schedu S

TIME

0 do_exi Z

420 pipe_w S

?

pts/3
pts/3
tty4
tty3
?

pts/0
pts/0

0:06

0:00
0:00
0:00
2:57
0:00

0:00
0:00

Un proceso dormido (voluntario). El proceso init está esperando que algo
"interesante" suceda tal como un huérfano recién creado a heredar.
Un proceso dormido(involuntario) o "bloqueado". El comando updatedb está
compitiendo por algún recurso en el sistema probablemente con la otra instancia
del proceso updatedb justo debajo de éste.
Un proceso detenido. Este editor vim probablemente ha sido suspendido
manualmente con la secuencia de teclas CONTROL-Z.
Un proceso zombi probablemente abandonado por un navegador de red galeon
negligente.
Un proceso ejecutable en este caso el comando ejecutable ps.

21

Managing Processes
Lab Exercise
Objetivo: Explorar diferentes estados de procesos
Estimated Time: 10 mins.
Especificaciones
1. Con el fin de explorar los estados de procesos debemos crear procesos que estén
compitiendo por los mismos recursos. Utilice un editor de texto sencillo para
crear el siguiente guión, almacénelo como ~/clobber_it.sh y hágalo
ejecutable.
2.
3.
4.
5.
6.
7.

[maxwell@station maxwell]$ cat clobber_it.sh
#!/bin/bash
for i in $(seq 1000); do
echo "hello world" > poor_overworked_file
done

8. Aunque este guión escribirá al pobre archivo sobrecargado 1000 veces, lo hará
de forma secuencial y así nunca estará compitiendo por acceder al archivo. Dado
que necesitamos procesos múltiples compitiendo por el mismo recurso, cree
también el mismo script. Nómbrelo ~/clobber_it_lots.sh y hágalo
ejecutable.
9.
10.
11.
12.
13.
14.

[maxwell@station maxwell]$ cat clobber_it_lots.sh
#!/bin/bash
for i in $(seq 1000); do
./clobber_it.sh &
done

Esto debería funcionar.
15. In one terminal, run the command top -d1. This should run the top command,
updating continuously. While top is running, use the U command to limit the
display to your own processes (i.e., type in your own username).
16. When we say go, in a separate terminal (either another terminal window in an X
graphical environment, or a separate virtual console), run the script
clobber_it_lots.sh. This will start about 1000 processes on your machine,
which will obviously stress the system, but it should be able to handle it. [1] The
system may seem sluggish, but with patience, it should still be responsive. If
things get unbearable, the script can be canceled with a CTRL-C. We haven't
said go yet.
17. Mientras el guión esté ejecutándose, observe la terminal con el comando top.
Usted debería ver muchos procesos iniciándose y deteniéndose como también
muchos procesos en el estado “D”. Si tiene suerte, podría capturar incluso un
zombi. Aún no hemos dicho que empiece.
18. También mientras se esté ejecutando el script, en otro terminal, ejecute el
comando ps aux y redirija la salida al archivo ~/lotsa_processes.txt.

22

Managing Processes
Observe el contenido del script y asegúrese que al menos cinco procesos en el
estado “D” hayan sido registrados. Aún no hemos dicho que empiece.
19. ¡Empiece!
20. Después de crear su archivo ~/lotsa_processes.txt y de sentir que ha
entendido, puede cancelar el script clobber_it_lots.sh con la secuencia
CONTROL-C y abandone el comando top.
Deliverables
Question 1

1. El archivo ~/lotsa_processes.txt que contiene la salida del comando ps aux
con al menos 5 instancias del proceso en el estado “D” (ininterrumpible).

Capítulo 3 Programación de procesos: nice y renice
Conceptos clave
•
•
•

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

Nomenclatura de programación de procesos
Una de las tareas fundamentales del kernel de Linux es asegurar que los procesos
compartan recursos del sistema de manera efectiva. Uno de los recursos más
importantes que tiene que compartirse es la CPU. La forma en que el kernel decide qué
proceso tiene que ejecutarse en la CPU y la hora se conoce como programación.
Cada proceso tiene dos valores que influyen en su programación. El primero es un valor
dinámico que el kernel cambia constantemente. El segundo, es un valor fijo que sólo de
vez en cuando el usuario lo cambia. En la comunidad de código abierto, la nomenclatura
utilizada para describir estos dos valores ha sido inconsistente lo que lleva a la
confusión. En lo posible, este texto tratará de ser consistente con los comandos ps y top
y se referirá al primer valor (dinámico) como la prioridad del proceso y al segundo
valor (fijo) como el niceness del proceso.
Programación de procesos en esencia
Recientemente, se ha prestado mucha atención a los métodos utilizados por el kernel de
Linux para implementar programación y la técnica ha variado con cada lanzamiento del
kernel. Aunque la siguiente discusión no es correcta en detalle comunica en esencia la
forma como el kernel de Linux programa procesos.

23

Managing Processes
Para ilustrar la programación de un modo más fácil, maxwell iniciará cuatro versiones
del comando cat, ejecutándose en el segundo plano, (los procesos se pueden ejecutar en
segundo plano agregando el signo “&”), como se discutirá en una lección más adelante.
Los comandos cat leen desde /dev/zero (un seudo dispositivo que actúa como una
fuente infinita de ceros binarios) y escriben en /dev/null (un seudo dispositivo que
bota todo lo que se escribe en él).
[maxwell@station
[1] 6698
[maxwell@station
[2] 6699
[maxwell@station
[3] 6700
[maxwell@station
[4] 6701

maxwell]$ cat /dev/zero > /dev/null &

¿Por cuánto tiempo se ejecutarán estos comandos cat? Para siempre. El usuario
maxwell controla los procesos en su máquina mediante el comando top.
00:25:43 up 11:07, 10 users, load average: 6.02, 5.08, 3.01
128 processes: 121 sleeping, 7 running, 0 zombie, 0 stopped
CPU states:
8.5% user
3.2% system
4.6% nice
0.0% iowait
idle
Mem:
255232k av, 251560k used,
3672k free,
0k shrd,
36592k buff
162724k actv,
33644k in_d,
3952k in_c
Swap: 522104k av, 145148k used, 376956k free
74780k cached
PID USER
PRI
COMMAND
6698 maxwell
25
6699 maxwell
22
6700 maxwell
24
6757 einstein 21
6701 maxwell
25
6686 maxwell
35
xlyap
6758 maxwell
19
1063 root
15
1 root
15
2 root
15
keventd
...

NI

SIZE

RSS SHARE STAT %CPU %MEM

0
404 400
0
400 400
0
400 372
0 25992 24M
0
400 400
10 6608 4836

352
352
352
3596
352
1108

0 1120 1120
0 33304 16M
0
108
76
0
0
0

852
692
52
0

R
R
R
R
R
R N
R
S
S
SW

83.5%

TIME CPU

19.3
19.3
19.3
17.4
16.4
4.8

0.1
0.1
0.1
9.7
0.1
1.8

0:24
0:24
0:24
0:04
0:24
0:44

2.9
1.9
0.0
0.0

0.4
6.5
0.0
0.0

0:00
33:56
0:04
0:00

0
0
0
0
0
0

cat
cat
cat
jade
cat

0 top
0 X
0 init
0

Mientras observa el comando top, maxwell observa que los valores en la tercera
columna (con la etiqueta PRI) están en constante cambio. Estos son los valores de
"prioridad" dinámicos del proceso mencionados anteriormente. La cuarta columna (con
la etiqueta NI) es el valor fijo de "niceness" del proceso.
Prioridades del proceso

24

Managing Processes
Cuando se programan los procesos, el kernel da a cada proceso un puñado de
contadores. Cada vez que un proceso se programa en la CPU, entrega uno de sus
contadores. Cuando decide qué proceso programar en la próxima CPU, el kernel escoge
un proceso ejecutable con la mayoría de contadores. Eventualmente, el kernel alcanzará
un estado donde todos los procesos ejecutables han utilizado sus contadores. Esto se
conoce como el final de una programación epoch y en este punto el kernel inicia todos
los procesos otra vez con un puñado de contadores.
Observe que los procesos que no están en estado ejecutable nunca entregan sus
contadores. Sin embargo, si un proceso dormido se despertara de repente (porque algo
interesante ha sucedido) y fuera enviado al estado ejecutable, muy probablemente
tendría más contadores que procesos ejecutándose por un tiempo y le gustaría que
fueran programados rápidamente en la CPU.
¿Cómo se relaciona esto con los valores demostrados en la columna PRI? Piense en esta
columna como si fuera un número de procesos de contadores, restados de 40. Por lo
tanto, los procesos con una prioridad inferior (como es listado por el comando top)
tienen una ventaja en la programación. En la salida de arriba, los comandos cat, en
constante ejecución, están consumiendo sus contadores. Sin embargo, el proceso init
que está durmiendo en el segundo plano, no lo está.
Proceso niceness
Como se mencionó anteriormente, cada proceso también tiene un valor estático
conocido como su valor de niceness. Este valor tiene un rango que va de -20 a 19 para
cualquier proceso, iniciando en 0 por defecto. ¿Cómo influye un niceness de un proceso
en su programación? Al comienzo de la programación puede pensar que el kernel resta
un valor de niceness del proceso del número de contadores del proceso que se le ha
asignado. Como resultado de procesos más, "amables" (aquellos con un alto valor de
niceness) obtienen menos contadores y por lo tanto menos tiempo en la CPU, mientras
que procesos más "ambiciosos" (aquellos con un valor de niceness menor que 0)
obtienen más contadores y más tiempo en la CPU. Si un proceso "amable" es el único
ejecutándose en la máquina entonces obtendría acceso total a la CPU.
Cambio del valor niceness de un proceso
Suponga que maxwell fuera a ejecutar una simulación física que le tomaría varios días
completar. Al incrementar el valor de niceness del proceso, el proceso pacientemente
esperaría si alguien más estuviera ejecutando procesos en la máquina. Si nadie más
estuviera en la máquina, la simulación física tendría acceso total a la CPU.
Hay varias técnicas por las cuales maxwell podría alterar su valor de niceness del
proceso.
Uso del comando nice para iniciar un comando con prioridad baja

25

Managing Processes
El comando nice se utiliza para establecer un valor de niceness del proceso al iniciar el
proceso. Cuando maxwell inicia su simulación (la cual es un ejecutable en su directorio
de inicio llamado ~/simulation) lo hace lo más nice posible, con el valor de +19,
(también coloca el proceso en segundo plano. No se preocupe por esto en este momento
puesto que lo abarcaremos en una próxima lección).
[maxwell@station maxwell]$ nice -19 ./simulation &

Observe que la sintaxis puede confundir. El símbolo -19 no debería considerarse
negativo 19 sino en cambio la opción numérica 19. El usuario maxwell de nuevo
controla los procesos mediante el comando top. Los primeros pocos procesos listados se
enumeran a continuación.
PID USER
PRI NI SIZE RSS SHARE STAT %CPU %MEM
TIME CPU
COMMAND
7192 maxwell
25
0
400 400
352 R
22.7 0.1
0:35
0 cat
7193 maxwell
25
0
400 400
352 R
22.7 0.1
0:35
0 cat
7191 maxwell
25
0
400 400
352 R
21.9 0.1
0:36
0 cat
7194 maxwell
25
0
404 404
352 R
21.9 0.1
0:35
0 cat
1184 einstein 15
0 11140 8708 3144 R
4.7 3.4
1:28
0
gnome-termina
7198 maxwell
39 19
404 404
352 R N
2.1
0.1
0:02
0
simulation
4293 maxwell
15
0 5164 5016 2384 S
1.7 1.9
6:07
0
gnome-system-

Como algo conveniente, el comando ps representa el estado de proceso con una
“N” para indicar que el proceso ha aumentado su valor de niceness.
Dado que otros comandos cat están utilizando la máquina, la simulación de
maxwell sólo está usando cerca del 2.1 % de la CPU.
Luego, maxwell se deshace de los comandos cat (mediante las técnicas que veremos en
la siguiente lección).
[maxwell@station maxwell]$ killall cat
[maxwell@station maxwell]$
[3]
Terminated
cat /dev/zero >/dev/null
[4]
Terminated
[5]
Terminated
[6]
Terminated

Cuando observa el comando top una vez más, su simulación, ahora el (casi) único
proceso en la máquina, está recibiendo todo el tiempo de la CPU.
PID USER
PRI NI SIZE RSS SHARE STAT %CPU %MEM
COMMAND
7198 maxwell
39 19
404 404
352 R N 94.4 0.1
simulation
7210 maxwell
20
0 1120 1120
852 R
2.8 0.4
1063 root
15
0 33516 17M
832 S
1.9 7.0
4212 maxwell
15
0 5828 3012 1072 S
0.9 1.1
applet-gu
1 root
15
0
108
76
52 S
0.0 0.0

TIME CPU
0:51

0

0:00
47:01
0:21

0 top
0 X
0 rhn-

0:04

0 init

26

Managing Processes
Como una sutileza adicional, el número especificado es el número que va a agregarse al
valor de niceness de la shell actual. Esto rara vez se nota, dado que la mayoría de las
shells se ejecutan con un niceness de 0. No obstante, si una shell estuviera ejecutándose
con un valor de niceness de 10, la siguiente opción de línea de comando resultaría en la
simulación que está ejecutándose con un valor de niceness de 15.
[maxwell@station maxwell]$ nice -5 ./simulation &

Uso de renice para alterar un proceso en ejecución
El comando renice puede utilizarse para cambiar el niceness de un proceso en
ejecución. Los procesos pueden ser especificados por el ID del proceso, nombre de
usuario, o nombre de grupo, dependiendo de cuál de las siguientes opciones se utilicen.
Table 1. Opciones para el comando renice
Opción
Efecto
-p
interpreta los argumentos restantes como ID del proceso (por defecto)
-u

interpreta los argumentos restantes como nombres de usuarios.

-g

interpreta los argumentos restantes como ID de grupo.

Suponga que maxwell ya ha iniciado su simulación sin alterar su valor de niceness.
[maxwell@station maxwell]$ ps -C simulation u
USER
PID %CPU %MEM
VSZ RSS TTY
STAT START
maxwell
7348 58.9
0.1 3408 400 pts/5
R
01:29
simulation
[maxwell@station maxwell]$ ps -C simulation l
F
UID
PID PPID PRI NI
VSZ RSS WCHAN STAT TTY
COMMAND
0
515 7348 6064 25
0 3408 400 R
pts/5
simulation

TIME COMMAND
0:50

TIME
0:51

El proceso está recibiendo una gran cantidad de tiempo de la CPU.
El proceso tiene por defecto un valor de niceness de 0.
Decide ser más cortés con otras personas que podrían estar utilizando la máquina y
utiliza el comando renice para elevar el valor de niceness del proceso. En la ausencia de
cualquier opción, el comando renice espera un valor de niceness y un ID de proceso
como sus dos argumentos.
[maxwell@station maxwell]$ renice 19 7347
7348: old priority 0, new priority 19

Observe la inconsistencia en la sintaxis. El comando renice a diferencia del comando
nice, no espera que el valor de niceness sea especificado como una opción, sino como
un argumento. De hecho, renice -19 7347 sería interpretado como un valor de
niceness de -19. Enlodando más las aguas, la salida del comando renice se refiere al

27

Managing Processes
valor como una prioridad en lugar de un niceness, (como también lo hace alguna de la
documentación relacionada).
Uso del comando top para otorgar otro valor de nice a un proceso
Como se mencionó antes, el comando top utiliza la tecla r para cambiar el valor nice de
un proceso. Mientras controla procesos con top, al presionar r abrirá el siguiente
diálogo que aparece encima de la lista de procesos.
PID to renice: 7347
Renice PID 7347 to value: 19

Hacer procesos mucho más ambiciosos
¿Qué sucedería si maxwell fuera malintencionado y quisiera hacer su simulación mucho
más ambiciosa en lugar de más amable? Afortunadamente, para otros usuarios en la
máquina, los usuarios normales no pueden bajar el niceness de un proceso. Esto trae
dos implicaciones.
1. Debido a que los procesos inician con un niceness de 0 por defecto, los usuarios
normales no pueden hacer procesos "ambiciosos" con valores de niceness
negativos.
2. Una vez un proceso ha sido hecho nice, los usuarios normales no pueden
volverlo "normal" otra vez .
Suponga que el administrador observó que la simulación de maxwell estaba tomando
mucho tiempo de la CPU. Ella pudo utilizar el comando renice como root para elevar el
niceness de maxwell y maxwell no pudo restaurarlo.
Ejemplos
Ver prioridades
Abajo hay varias tomas de pantalla ps -alx a medida que se ejecuta el proceso. Observe
los campos "PRI" y "nice" a lo largo del tiempo. Son los campos 5 y 6 de izquierda a
derecha.
[maxwell@station
[1] 2739
[maxwell@station
F
UID
PID
COMMAND
...
000
501 2676
bash
000
501 2739
find /
000
501 2740
/bin/bash -

maxwell]$ find / 2>/dev/null >/dev/null &
maxwell]$ ps -alx
PPID PRI NI
VSZ

898

15

2676

18

2611

16

0
0
0

RSS WCHAN

4232 1544 wait4
3284
3804

STAT TTY

TIME

S

0:00

644 948 wait4

pts/0
R

S

pts/0
pts/1

0:00
0:00

28

Managing Processes
040
501 2741
/bin/bash 000
501 2742
ps -alx
000
501 2743
tail
...

2740

16

0

3808 1004 wait4

S

pts/1

0:00

2741

17

0

3144 1232 -

R

pts/1

0:00

2741

17

0

3144

420 pipe_w S

pts/1

0:00

[maxwell@station
F
UID
PID
COMMAND
...
000
501 2676
bash
000
501 2718
/bin/bash 040
501 2719
/bin/bash 000
501 2720
ps -alx
000
501 2721
tail
000
501 2739
find /
...

maxwell]$ ps -alx
PPID PRI NI
VSZ

RSS WCHAN

STAT TTY

TIME

898

16

0

4232 1544 wait4

S

pts/0

0:00

2611

15

0

3808

944 wait4

S

pts/1

0:00

2718

16

0

3812 1000 wait4

S

pts/1

0:00

2719

17

0

3148 1232 -

R

pts/1

0:00

2719

17

0

3136

R

pts/1

0:00

2676

17

0

3248

384 576 -

R

pts/0

0:00

La prioridad del proceso find fluctúa con el tiempo.
El niceness, por el contrario, permanece fijo en 0.
Luego, maxwell utiliza el comando renice para alterar el valor de niceness del proceso.
[maxwell@station
[maxwell@station
000
501 2982
bash
000
501 2739
find /
000
501 3010
/bin/bash 040
501 3011
/bin/bash 000
501 3012
ps -alx
000
501 3013
tail

maxwell]$ renice 5 2739
maxwell]$ ps -alx
898 15
0 4228 1544 schedu S
5

3248

576 -

pts/0
RN

pts/0

0:00

2676

20

0:00

2611

16

0

3804

948 wait4

S

pts/1

0:00

3010

17

0

3808 1004 wait4

S

pts/1

0:00

3011

17

0

3140 1228 -

R

pts/1

0:00

3011

17

0

3140

416 pipe_w S

pts/1

0:00

Debido a que el valor de niceness se ha incrementado, el proceso tiene valores más
altos de prioridad (implicando menos acceso a la CPU por una época de
programación).
El nuevo valor de niceness.
Cambiando de parecer, maxwell decide restaurar el niceness a su valor predeterminado
de 0.
[maxwell@station maxwell]$ renice 0 2739

29

Managing Processes
renice: 2739: setpriority: Permission denied

Dado que a los usuarios estándar no se les permiten valores de niceness más bajos, el
comando falla.
Cambio de prioridades con renice
Al utilizar la opción -u, el usuario maxwell puede cambiar los valores de niceness para
todos los procesos al mismo tiempo.
[maxwell@station maxwell]$ ps -lu maxwell
F S
UID
PID PPID C PRI NI ADDR
SZ WCHAN
CMD
4 S
515 3031 3028 0 75
0
- 1078 wait4
bash
1 S
515 8954
1 0 79
0
- 3313 schedu
gvim
0 S
515 8958 3031 1 80
0
- 1078 wait4
bash
0 R
515 8984 8958 0 83
0
779 ps
[maxwell@station maxwell]$ renice 5 -u maxwell
515: old priority 0, new priority 5
[maxwell@station maxwell]$ ps -lu maxwell
F S
UID
PID PPID C PRI NI ADDR
SZ WCHAN
CMD
4 S
515 3031 3028 0 85
5
- 1078 wait4
bash
1 S
515 8954
1 0 85
5
- 3313 schedu
gvim
0 S
515 8958 3031 0 80
5
- 1078 wait4
bash
0 R
515 8986 8958 0 86
5
779 ps

TTY

TIME

pts/4

00:00:00

?

00:00:00

pts/4

00:00:00

pts/4

00:00:00

TTY

TIME

pts/4

00:00:00

?

00:00:00

pts/4

00:00:00

pts/4

00:00:00

Lab Exercise
Objetivo: Cambiar las prioridades de los procesos.
Especificaciones
1. Ejecutar el siguiente comando en una terminal.
2.

[student@station student]$ cat /dev/zero > /dev/null

3. En otra terminal, utilice el comando renice para cambiar el valor de niceness de
todos los procesos que le pertenezcan hasta 5 (podría considerar el utilizar el
comando pgrep junto con el comando xargs para este paso).
4. Después de completar el último paso, cambie el valor de niceness del proceso
cat (iniciado en el paso 1) a 10.

30

Managing Processes
5. Utilice el comando nice para iniciar otro comando cat (de nuevo leyendo
/dev/zero redirigido a /dev/null) con el valor de niceness de 15.
Califique su ejercicio con ambas instancias del comando cat aún ejecutándose.
Question 1

1. Un comando cat ejecutándose con el valor de niceness de 10.
2. Un comando cat ejecutándose con el valor de niceness de 15.
3. Todos los otros procesos ejecutados por usted tienen un valor de niceness de 5.

Limpieza
Cuando haya terminado de calificar su ejercicio puede detener todos sus procesos cat
con la secuencia de control CTRL-C.
Capítulo 4 Envío de señales
Conceptos clave
•

•

•
•

•
•
•
•

Las señales son una forma de bajo nivel de la comunicación entre procesos que
surgen de una variedad de recursos, incluyendo el kernel, la terminal y otros
procesos.
Las señales se distinguen por los números de señales que tienen nombres y usos
simbólicos. Los nombres simbólicos para los nombres de señales pueden listarse
con el comando kill -l.
El comando kill envía señales a otros procesos.
Tras recibir una señal, un proceso puede ya sea, ignorarla, reaccionar de un
modo especificado por defecto de kernel o implementar un manejador de señal
personalizado.
Convencionalmente, el número de señal 15 (SIGTERM) se utiliza para solicitar la
terminación de un proceso.
La señal número 9 (SIGKILL) termina un proceso y no puede anularse.
Los comandos pkill y killall pueden utilizarse para enviar señales a procesos
especificados por nombre de comando o el usuario a quienes pertenecen.
Otras utilidades, tales como top y el Monitor de sistema GNOME, también
pueden utilizarse para enviar señales.

Señales
Linux (y Unix) utiliza señales para notificar procesos de eventos anormales, y como un
mecanismo primitivo de comunicación entre procesos. Algunas veces, las señales se
conocen como interrupciones de software, porque pueden interrumpir el flujo normal de
ejecución de un proceso. El kernel utiliza señales para notificar procesos de conducta

31

Managing Processes
anormal, como si el proceso tratase de dividir un número por cero o tratase de acceder
memoria que no le perteneciera.
Los procesos también pueden enviar señales a otros procesos. Por ejemplo, una shell
bash podría enviar una señal a un proceso xclock. El proceso receptor sabe muy poco
acerca de los orígenes de la señal. No sabe si la señal se originó del kernel o de algún
otro proceso, todo lo que sabe es que recibió una señal.
Figure 1. Xclock recibe un señal número 15 de Bash

Sin embargo, hay diferentes sabores de señales. Los diferentes sabores tienen números
simbólicos pero también se identifican con números enteros. Los varios números
enteros y el nombre simbólico que les son asignados pueden listarse por medio del
comando kill -l o los puede encontrar en la página del manual signal(7).
[einstein@station einstein]$ kill -l
1) SIGHUP
2) SIGINT
3) SIGQUIT
5) SIGTRAP
6) SIGABRT
7) SIGBUS
9) SIGKILL
10) SIGUSR1
11) SIGSEGV
13) SIGPIPE
14) SIGALRM
15) SIGTERM
18) SIGCONT
19) SIGSTOP
20) SIGTSTP
22) SIGTTOU
23) SIGURG
24) SIGXCPU
26) SIGVTALRM
27) SIGPROF
28) SIGWINCH
30) SIGPWR
31) SIGSYS
33) SIGRTMIN
35) SIGRTMIN+2 36) SIGRTMIN+3 37) SIGRTMIN+4
47) SIGRTMIN+14 48) SIGRTMIN+15 49) SIGRTMAX-15
51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11
63) SIGRTMAX-1

4)
8)
12)
17)
21)
25)
29)
34)
38)
42)
46)
50)
54)
58)
62)

SIGILL
SIGFPE
SIGUSR2
SIGCHLD
SIGTTIN
SIGXFSZ
SIGIO
SIGRTMIN+1
SIGRTMIN+5
SIGRTMIN+9
SIGRTMIN+13
SIGRTMAX-14
SIGRTMAX-10
SIGRTMAX-6
SIGRTMAX-2

Linux, al igual que varias versiones de Unix, implementa 32 señales "normales". En
Linux, las señales se numeran a partir de 32 hasta 63 (que no son estándar entre las
varias versiones de Unix) y son señales en "tiempo real" y van más alla del objetivo de
este texto.

¿Por qué se envían las señales?

32

Managing Processes
Hay una variedad de razones por las cuales las señales se pueden enviar a un proceso
como se ilustra con los siguientes ejemplos.
Excepciones de hardware
El proceso le pidió al hardware realizar alguna operación errónea. Por ejemplo,
el kernel enviará un proceso SIGFPE (señal número 8) si realiza una división
por 0.
Condiciones del software
Los procesos pueden necesitar ser notificados de alguna condición anormal del
software. Por ejemplo, cada vez que muere un proceso, el kernel envía un
SIGCHLD (número de señal 17) al padre del proceso. Otro ejemplo, las
aplicaciones gráficas X reciben un SIGCHLD (número de señal 17) cada vez
que su ventana cambia de tamaño, para poder responder a la nueva geometría.
Interrupciones de terminal
Varias secuencias de control de teclas de la terminal envían señales al proceso
de la shell bash. Por ejemplo, CONTROL-C envía un SIGINT (número de
señal 2) mientras que CONTROL-Z envía un SIGTSTP (número de señal 20).
Otros procesos
Los procesos pueden elegir enviar señales a cualquier otro proceso perteneciente
al mismo usuario. El comando kill está diseñado para hacer justo esto.
Envíar señales: el comando kill
El comando kill se utiliza para enviar señales a otros procesos. Éste espera ser llamado
con una opción numérica o simbólica que especifica la señal a enviar y un ID de
proceso que especifica el proceso que debería recibirlo. A manera de ejemplo, las
siguientes líneas de comando envían un SIGCHLD (número de señal 17) al proceso
xclock, el ID del proceso número 8060.
[einstein@station einstein]$ ps
PID TTY
TIME CMD
7985 pts/5
00:00:00 bash
8060 pts/5
00:00:01 xclock
8061 pts/5
00:00:00 ps
[einstein@station einstein]$ kill -17 8060
[einstein@station einstein]$ kill -CHLD 8060
[einstein@station einstein]$ kill -SIGCHLD 8060

Cuando se utiliza el nombre simbólico para especificar una señal, el prefijo “SIG”
(compartido por todas las señales) puede ser incluído u omitido.
Recepción de señales

33

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

•

Terminar: El proceso de recepción se cierra.
Ignorar: El proceso de recepción ignora la señal
Núcleo: El proceso de recepción termina, pero bota una imagen de su
memoria en un archivo llamado core en el actual directorio de trabajo
del proceso. El archivo core puede ser utilizado por desarrolladores para
ayudar a depurar el programa. [1]
Pare: detenga o (suspenda) el proceso.

La página de manual signal(7) documenta la conducta asignada para cada señal.
Escoja ignorar la señal
Los programadores pueden elegir que su aplicación simplemente ignore señales
especificadas.
Escoger implementar un manejador de señal personalizado
Los programadores pueden elegir implementar su propia conducta cuando se
recibe una señal específica. La respuesta del programa es completamente
determinada por el programador.
A no ser que la documentación del programa diga lo contrario, usted puede asumir que
un proceso responderá con la conducta implementada de kernel. Cualquier otra
respuesta debe estar documentada.
Uso de señales para terminar procesos
De las 32 señales utilizadas en Linux (y Unix) los usuarios normales en práctica
(explícitamente) sólo hacen uso de unas pocas.
Table 1. Señales importantes para usuarios normales
Número Symbol

Acción

2

SIGINT

Interrumpe (solicita terminar) el proceso. Esta es la señal generada
por la secuencia de control CTRL-C.

9

SIGKILL

Fuerza el terminar el proceso (esta señal puede no ser anulada por
el proceso)

15

SIGTERM Solicita la terminación del proceso.

34

Managing Processes
Número Symbol
20

SIGTSTP

Acción
Detiene (suspende) el proceso. Esta es una señal generada por la
secuencia de control CTRL-Z.

Los usuarios estándar suelen utilizar señales para terminar un proceso (razón del
nombre del comando kill). Por convención, si los programadores quieren implementar
la conducta personalizada cuando se apaga (como por ejemplo botando memoria
importante al disco, etc), ellos implementan un manejador de señal personalizado de 15
para realizar la acción. El número de señal 9 se maneja especialmente por el kernel y no
puede anularse por un manejador de señal personalizado o ser ignorado. Este se reserva
como un último recurso, la técnica de nivel de kernel para matar un proceso.
A manera de ejemplo, einstein iniciará un comando cat que en un principio se ejecutaría
para siempre. Luego traza el ID del proceso del comando y termina con un SIGTERM.
[einstein@station einstein]$ cat /dev/zero > /dev/null &
[1] 8375
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]$
[1]+ Terminated

SIGTERM (número de señal 15) es la señal por defecto para el comando kill, por lo
tanto einstein pudo haber utilizado kill 8375 para el mismo efecto. A continuación,
einstein repite la secuencia, esta vez enviando un SIGKILL.
[einstein@station einstein]$ cat /dev/zero > /dev/null &
[1] 8387
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
[1]+ Killed

Alternativas para el comando kill
El uso de señales para controlar procesos es una ocurrencia tan común que las
alternativas para usar el comando kill abundan. Las siguientes secciones mencionan
unas cuantas.

El comando pkill

35

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

[-signal] [OPCIONES] [PATRÓN]

El primer símbolo especifica opcionalmente el número de señal para enviar (por
defecto, el número de señal 15). PATTERN es una expresión regular extendida que
coincidirá con nombres de comandos. El siguiente cuadro lista las opciones de comando
más utilizadas. Los procesos que cumplen con todos los criterios especificados enviarán
la señal especificada.
Table 1. Opciones para el comando pkill
Opción
-n

Efecto
Selecciona únicamente los procesos coincidentes iniciados más recientemente.

-u USER Selecciona procesos pertenecientes al usuario USER.
-t TERM Selecciona procesos controlados por terminal TERM.
De manera conveniente, el comando pkill se omite a si mismo y la shell que lo inició
cuando mataba todos los proceso pertenecientes a un usurario particular o a una
terminal. Considere el siguiente ejemplo.
[maxwell@station maxwell]$ ps
PID TTY
TIME CMD
10353 pts/4
00:00:00 bash
10396 pts/4
00:00:00 xclock
10397 pts/4
00:00:03 mozilla-bin
10422 pts/4
00:00:00 ps
[maxwell@station maxwell]$ pkill -u maxwell
[1]- Terminated
xclock
[maxwell@station maxwell]$ ps
PID TTY
TIME CMD
10353 pts/4
00:00:00 bash
10424 pts/4
00:00:00 ps
[2]+ Exit 15
mozilla

Observe que aunque la shell bash se clasifica como un proceso perteneciente al usuario
maxwell, ésta sobrevivió.
El comando killall
Igual que pkill, el comando killall envía señales a procesos especificados por el nombre
de comando. El comando killall soporta las siguientes opciones.
Table 1. Opciones para el comando killall

36

Managing Processes
Opción

Efecto

-i, -interactive

De modo interactivo pregunta al usuario antes de enviar la señal a un
proceso.

-w, --wait

Espera hasta que todos los procesos estén muertos antes de retornar.

El Monitor del sistema
La aplicación del Monitor de sistema GNOME, presentada en una lección anterior,
también puede utilizarse para enviar señales a los procesos. Al hacer click derecho en
un proceso, un menú emergente le permite al usuario seleccionar End Process, el cual
tiene el efecto de entregar un SIGTERM al proceso. ¿Qué hace la opción del menú
Matar proceso?
Figure 1. Terminación de procesos mediante el monitor del sistema.

El comando top
El comando top puede también utilizarse para entregar señales a procesos. Al utilizar la
tecla K, aparece el siguiente diálogo encima de la lista de procesos, permitiéndole al
usuario especificar qué procesos ID deberían recibir la señal y qué señal entregar.
PID to kill: 4859
Kill PID 4859 with signal [15]: 9

Ejemplos
Uso de señales para terminar procesos
Las señales suelen ser la única forma de terminar procesos que están siendo manejados
por una línea de comando de shell. Por ejemplo, los clientes (aplicaciones) gráficos X
pueden matarse al entregar un SIGTERM al proceso apropiado. En el siguiente ejemplo,
el usuario maxwell está ejecutando el navegador de red Mozilla y el reloj gráfico
xclock. Utiliza el comando pgrep para localizar sus ID de procesos, mata el primero
mediante el comando kill y el segundo mediante el comando pkill.
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
2112 bash

Pero, ¡espere! Hay una forma diferente para terminar aplicaciones gráficas aparte del
envío de señales. Solamente haga click en la casilla "cerrar" en la esquina superior
derecha o seleccione Cerrar en menú desplegable en la esquina superior izquierda. Entre
bastidores, esta es precisamente la labor de estas acciones: entregar una señal
SIGTERM a una aplicación adjunta.
Uso de señales para matar procesos
Cada vez que sea posible la señal SIGTERM debería utilizarse para terminar procesos.
Sin embargo, algunas veces, los procesos están "encerrados" y completamente
insensibles, incluso para las señales SIGTERM. En estos casos, la señal SIGKILL
(número de señal 9) puede utilizarse como un último recurso. La señal SIGKILL mata
un proceso en el kernel sin ninguna interacción con el proceso mismo.
A continuación, maxwell intenta terminar una simulación física (el proceso sim) con la
señal por defecto SIGTERM. Por alguna razón, el proceso es insensible por lo tanto
maxwell lo mata con la señal SIGKILL.
[maxwell@station
2112 bash
4489 sim
[maxwell@station
[maxwell@station
2112 bash
4489 sim
[maxwell@station
[1]+ Killed
[maxwell@station
2112 bash

maxwell]$ pgrep -lu maxwell

maxwell]$ pkill sim

maxwell]$ pkill -KILL sim
sim

¡Hágalo que pare!
La combinación de la habilidad de pkill para seleccionar todos los procesos
pertenecientes a un usuario particular, y la señal SIGKILL de bajo nivel letal,
conforman una técnica conveniente para que un usuario mate todos los procesos que
puedan estar ejecutándose en la máquina local.
A continuación, maxwell observa primero cuántos procesos está ejecutando en la
máquina local. Luego mata todos los procesos.
[maxwell@station maxwell]$ pgrep -u maxwell | wc -l
22
[maxwell@station maxwell]$ pkill -KILL -u maxwell

Como resultado, maxwell se saca de la máquina (matando su propia sesión X o inicio de
sesión de consola virtual) y debe iniciar sesión otra vez.

38

Managing Processes
Lab Exercise
Objetivo: Terminar la ejecución de procesos de manera efectiva.
Especificaciones
1. Crear un script corto de shell llamado ~/bin/kill_all_cats y hacerlo
ejecutable. Cuando se ejecute, el guión debería matar todos los procesos cat en
ejecución.
2. En una terminal, iniciar un proceso cat mediante la siguiente línea de comandos.
Deje el proceso en ejecución mientras califica su ejercicio (pero no se sorprenda
si no está en ejecución cuando termine).
3.

[student@station student]$ cat /dev/zero > /dev/null

Deliverables
Question 1

1. Un script de shell llamado ~/bin/kill_all_cats que al ejecutarse, entregue
una señal SIGTERM a todas las instancias actuales en ejecución del comando
cat.
2. Un proceso cat en ejecución.

Capítulo 5 Control de trabajo
Conceptos clave
•
•
•
•
•
•

La shell bash permite a los comandos ejecutarse en segundo plano como
"trabajos".
La shell bash permite a un trabajo ejecutarse en segundo plano y puede tener
múltiples trabajos en segundo plano.
El comando jobs listará todos los trabajos en segundo plano.
La secuencia de teclas CONTROL-Z suspenderá y enviará a segundo plano el
actual trabajo que se encuentra en primer plano.
El comando bg reanuda un trabajo de segundo plano.
El comando fg trae un trabajo de segundo plano a primer plano.

39

Managing Processes
Los temas tratados en este cuaderno hasta el momento, es decir la información sobre
listado de procesos, el cambio de un valor niceness de un proceso y el envío de señales a
procesos son características compartidas por todos los procesos, ya sean iniciados desde
una línea de comandos de shell o de otro modo. A diferencia de estos temas anteriores,
el tema que nos resta, control de trabajo tiene que ver el manejo de procesos iniciados
desde un intérprete de comandos de una shell interactiva y se enfocará en la shell bash.
Ejecución de comandos en el primer plano
Cuando se ejecuta un comando desde un intérprete de comandos shell bash, a no ser
que usted especifique lo contrario, el comando se ejecuta en el primer plano. La shell
bash espera que el comando de primer plano termine antes de expedir otro intérprete de
comandos y cualquier cosa escrita con el teclado se lee generalmente como la stdin para
este comando. Todo esto debería sonar familiar porque los comandos utilizados hasta el
momento se han ejecutado en el primer plano.
Ejecución de comandos en segundo plano como trabajos
En contraste, cualquier comando que usted especifique puede también ejecutarse en el
segundo plano, adjuntándole el signo (“&”) a la línea de comandos. Por lo general, sólo
los comandos de larga ejecución que no requieren entradas desde el teclado y no
generan grandes cantidades de salida son apropiados para un segundo plano. Cuando la
shell bash envía a segundo plano un comando, el comando se conoce como un trabajo
y se le asigna un número de trabajo.
En el siguiente ejemplo, einstein está realizando una búsqueda de los archivos que
mayores de 1 megabyte en tamaño en su sistema de archivos. Dado que espera este
comando para ejecutar por un tiempo, dirige la stdout a un archivo, bota la stderr y la
ejecuta como un trabajo de segundo plano.
[einstein@station einstein]$ find / -size +1024k > bigfiles.txt 2>
/dev/null &
[1] 7022

Después de iniciar el trabajo en el segundo plano, la shell bash reporta dos partes de
información a einstein. La primera es el número de trabajo reportado entre paréntesis
cuadrados. La segunda es el ID del proceso del trabajo de segundo plano. En este caso,
el trabajo es el número de trabajo 1 y el ID del proceso del comando find es 7022.
Mientras que este comando se ejecuta en el segundo plano, einstein decide buscar los
archivos que le pertenecen y que no ha modificado en dos semanas. Escribe el comando
apropiado find y de nuevo envía a segundo plano el trabajo.
[einstein@station einstein]$ find / -user einstein -and -mtime +14
oldfiles.txt
2> /dev/null &
[2] 7023
[1]
Exit 1
find / -size +1M >bigfiles.txt
2>/dev/null

>

40

Managing Processes
De nuevo, bash reporta el número de trabajo (2) y el ID del proceso del segundo
comando find (7023).
El segundo mensaje de shell bash está notificando a einstein el número de trabajo que
se ha terminado. La shell bash reporta que ésta ha salido con un código de retorno de 1
(opuesto a ser matado por una señal) y revisualiza la línea de comando para recordar a
einstein lo que ha ejecutado. La shell bash no reporta inmediátamente la muerte de los
trabajos, sino espera hasta la próxima vez que interprete una línea de comandos.
Cuando einstein ha digerido todo esto sospecha que su segundo trabajo también ha
terminado. Simplemente, pulsa la tecla ENTER (para que bash "interpretará" la línea
de comandos vacía). Igualmente, la shell bash reporta su nuevo número de trabajo 2.
[2]+ Exit 1
>oldfiles.tx
t 2>/dev/null

find / -user einstein -and -mtime +14

Administración de múltiples trabajos
El usuario einstein, al igual que maxwell, suele realizar cálculos físicos que toman
mucho tiempo para ejecutar. Inicia varias versiones de la simulación enviándolas al
segundo plano.
[einstein@station
bin sim_a sim_b
[einstein@station
[1] 7309
[einstein@station
[2] 7311
[einstein@station
[3] 7313
[einstein@station
[4] 7315

einstein]$ ls
sim_c sim_d
einstein]$ ./sim_a &
einstein]$ ./sim_b &
einstein]$ ./sim_c &
einstein]$ ./sim_d &

Listado de trabajos actuales con jobs
El usuario einstein puede utilizar el comando incorporado jobs para reportar todos sus
trabajos en ejecución.
[einstein@station einstein]$ jobs
[1]
Running
./sim_a
[2]
Running
./sim_b
[3]- Running
./sim_c
[4]+ Running
./sim_d

&
&
&
&

Cada uno de sus trabajos de segundo plano son listados junto con el número de trabajo.
El trabajo más reciente se conoce como el trabajo actual y es representado por el
comando jobs con un “+”.
Traer un trabajo al primer plano con fg

41

Managing Processes
Un trabajo de segundo plano puede traerse al primer plano con el comando incorporado
fg. El comando fg espera un número de trabajo como un argumento o si ninguno es
provisto pondrá el trabajo actual en primer plano.
[einstein@station einstein]$ fg 3
./sim_c

Ahora, el trabajo sim_c está ejecutándose en el primer plano. Como consecuencia, la
shell no generará ningún intérprete de comandos cuando el proceso esté en ejecución.
Suspensión del trabajo de primer plano con CONTROLZ
Previamente, se introdujo la secuencia CONTROL-Z como un método para suspender
procesos. Ahora, al observar de cerca la salida de la shell bash cuando einstein
suspende el comando de primer plano, vemos que la shell bash trata como un trabajo a
cualquier proceso de primer plano suspendido.
./sim_c
CTRL-Z

[3]+ Stopped
./sim_c
[1]
Running
./sim_a &
[2]
Running
./sim_b &
[3]+ Stopped
./sim_c
[4]- Running
./sim_d &
[einstein@station einstein]$ ps u
USER
PID %CPU %MEM
VSZ RSS TTY
einstein 6987 0.0 0.3 4316 976 pts/8
einstein 7309 0.0 0.3 4112 1004 pts/8
/bin/bash ./sim_a
einstein 7311 0.0 0.3 4112 1004 pts/8
/bin/bash ./sim_b
einstein 7313 0.0 0.3 4112 1004 pts/8
/bin/bash ./sim_c
einstein 7315 0.0 0.3 4112 1000 pts/8
/bin/bash ./sim_d
einstein 7446 0.0 0.2 2616 660 pts/8

STAT START
S
15:56
S
16:20

TIME COMMAND
0:00 -bash
0:00

S

16:20

0:00

T

16:20

0:00

S

16:20

0:00

R

16:34

0:00 ps u

Cuando está suspendido (o para utilizar la terminología de shell, detenido), el proceso
recibe el número de trabajo (si es que aún no lo tiene) y se envía al segundo plano. El
comando jobs reporta el trabajo como un trabajo "detenido" y el comando ps confirma
que está detenido.
Reiniciar un trabajo detenido en el segundo plano
Un trabajo detenido puede reiniciarse en el segundo plano con el comando incorporado
bg. Al igual que el comando fg, el comando bg espera un número de trabajo como un
argumento o si no se provee ninguno entonces se utiliza el trabajo actual.

42

Managing Processes
A continuación, einstein reinicia su trabajo detenido en el segundo plano.
[einstein@station einstein]$ bg 3
[3]+ ./sim_c &
[1]
Running
./sim_a
[2]
Running
./sim_b
[3]- Running
./sim_c
[4]+ Running
./sim_d

&
&
&
&

Ahora el número de trabajo 3 está otra vez en estado de ejecución.
Matar trabajos
El comando kill, utilizado para entregar señales para procesos se implementa como un
comando incorporado de shell, (confusamente, también se encuentra otra versión en el
sistema de archivos /bin/kill. Probablemente usted está utilizando la versión de shell
incorporada). Como resultado, está consciente de los trabajos que la shell está
administrando.
Cuando se especifica qué proceso debería recibir una señal, el número de trabajo del
proceso (si lo hay) puede especificarse en vez de su ID de proceso. Para distinguir los
dos, los números de trabajo están precedidos por un caracter de porcentaje (“%”) como
se ilustra en el siguiente ejemplo.
[1]
Running
[2]
Running
[3]- Running
[4]+ Running
-bash: kill: (2) - Operation
[2]
Terminated
[1]
Running
[3]- Running
[4]+ Running

jobs
./sim_a &
./sim_b &
./sim_c &
./sim_d &
kill 2
not permitted
kill %2
./sim_b
jobs
./sim_a &
./sim_c &
./sim_d &

Aquí einstein erróneamente utilizó la sintaxis para especificar un ID de proceso, en
vez del número de trabajo. Puesto que él no posee su propio proceso con el ID de
proceso número 2, el comando falla.
Aquí, einstein utilizó la sintaxis correcta para especificar un número de trabajo y la
señal fue enviada al proceso sim_b.
Resumen
El siguiente cuadro resume los comandos y técnicas para administrar trabajos dentro de
la shell bash.

43

Managing Processes
Table 1. Administración de trabajos en la shell bash
Comando

Acción

trabajos Lista todos los trabajos
fg [N]

Trae el trabajo N de segundo plano al primer plano (por defecto, el trabajo de
segundo plano "actual").

CTRL-Z Suspende y envía al segundo plano el actual comando de primer plano
bg [N]

Inicia el trabajo de segundo plano detenido N (por defecto, el trabajo
"actual"en segundo plano).

kill %N

Termina el trabajo de segundo plano N (enviando la señal SIGTERM).

Ejemplos
Decidir enviar a segundo plano un comando ejecutándose en el primer plano
La discusión mencionó que los comandos se pueden iniciar en el segundo plano,
agregando un signo “&” a la línea de comandos. A continuación, einstein inicia un
comando en el primer plano y luego, dándose cuenta que le tomaría mucho tiempo
completar, deseá haberlo iniciado en el segundo plano.
[einstein@station einstein]$ ./sim_a

Con el fin de enviar al segundo plano el comando, primero lo suspende con la secuencia
de control CONTROL-Z, la cual lo abandona como un trabajo de segundo plano
detenido. Luego reinicia el trabajo en el segundo plano mediante bg.
[einstein@station einstein]$ ./sim_a
CTRL-Z
[1]+ Stopped
./sim_a
[einstein@station einstein]$ bg
[1]+ ./sim_a &

Uso de CONTROLC para matar un trabajo en segundo plano.
Como una alternativa para el comando kill, la siguiente técnica se utiliza para cancelar
trabajos enviados al segundo plano. Primero, se trae el trabajo al primer plano con el
comando y luego se mata con la secuencia CONTROL-C.
[1]
Running
./sim_a &
[2]- Running
./sim_b &
[3]+ Running
./sim_c &
./sim_b
CTRL-C

44

Managing Processes
[1]- Running
./sim_a &
[3]+ Running
./sim_c &

Lab Exercise
Objetivo: Uso del control de trabajo bash para administrar trabajos múltiples.
Especificaciones
1. Inicie los siguientes cuatro comandos, colocando a cada uno en el segundo
plano.
2.
3.
4.
5.

ls -R / | grep "*.conf" > lsconf 2>/dev/null
cat /dev/zero > /dev/null
find / -name "[Aa]*[Cc]*[Ff]*"
sleep 100000

6. Mediante los comandos de control de trabajos y las secuencias comunes de
control, parar (suspender) los trabajos ls y find.
Deliverables
Question 1

1. Cuatro trabajos enviados al segundo plano administrados por la shell bash. Los
trabajos cat y sleep deberían estar ejecutándose, mientras que los trabajos find y
ls deberían suspenderse.

Limpieza
Después de haber calificado su ejercicio, utilice el comando kill (o la combinación fg/
CONTROL-C) para matar todos los cuatro trabajos.

Capítulo 6 Programación de tareas retrasadas: at
Conceptos clave
•

El comando at puede someter comandos para que se ejecuten más tarde.

45

Managing Processes
•
•
•
•

El comando batch puede emitir comandos para que se ejecuten cuando la carga
de las máquinas sea baja.
Los comandos pueden escribirse directamente o someterse como un script.
la stdout de los trabajos at se envía por correo al usuario.
Los comandos atq y atrm se utilizan para examinar y quitar trabajos
actualmente programados.

Demonios
Antes de abordar el comando at directamente comenzamos con una corta discusión de
un concepto común en Unix: los demonios.
Con un nombre inspirado por Daemon del físico Maxwell, los demonios Unix son
procesos que se ejecutan en el segundo plano, separados de una terminal, realizan tareas
que no suelen estar relacionadas con el teclado de un usuario. Los demonios suelen
asociarse con servicios de red tales como el servidor de red (httpd) o el servidor FTP
(vsftpd). Otros demonios administran tareas del sistema tal como el demonio de inicio
de sesión (syslogd) y el demonio administrador de potencia (apmd). Esta y la siguiente
lección describirán dos demonios que permiten a los usuarios retrasar tareas (atd), o
ejecutar comandos en intervalos fijos (crond). Hasta el momento, usted habrá notado
una convención para nombres: los programas diseñados para ejecutarse como demonios
suelen terminar con la letra d.
Los demonios son procesos como cualquier otro proceso. Suelen iniciar como parte de
la secuencia de un sistema de arranque o por el usuario root, por lo tanto, usted nunca
sabría que están ahí a menos que los busque.
[elvis@station elvis]$ ps aux |
root
890 0.0 0.0 1572
elvis
5035 0.0 0.2 3572
crond
[elvis@station elvis]$ ps aux |
daemon
4730 0.0 0.2 1420
/usr/sbin/atd
elvis
5037 0.0 0.2 3572
atd

grep crond
132 ?
640 pts/4

S
S

09:57
16:17

0:00 crond
0:00 grep

grep atd
532 ?

S

15:42

0:00

640 pts/4

S

16:17

0:00 grep

Algunos demonios se ejecutan como el usuario root, mientras otros adquieren la
identidad de otro usuario de sistema por asuntos de seguridad. Arriba, el demonio crond
se está ejecutando como root pero el demonio atd está ejecutándose como el demonio
de usuario.

El demonio atd
El demonio atd le permite a los usuarios someter trabajos para ser realizados más tarde,
tal como a las "at 2:00am". Para utilizar el demonio atd, éste debe estar ejecutándose.

46

Managing Processes
Los usuarios pueden confirmar que atd se está ejecutando simplemente al examinar la
lista de procesos en ejecución:
[madonna@station madonna]$ ps aux | grep atd
daemon
4730 0.0 0.2 1420 532 ?
S
/usr/sbin/atd
madonna
5570 0.0 0.2 3572 640 pts/2
S
atd

15:42

0:00

16:43

0:00 grep

Observe que la séptima columna especifica con qué terminal se asocia un proceso. Para
el comando grep de blondie, la terminal es pts/2, la cual probablemente se refiere a
una shell de red o a una terminal gráfica dentro de una sesión X. Observe que el
demonio atd no tiene terminal asociada. Una de las características de un demonio es
que quita su asociación con la terminal que la inició.
Envío de trabajos con at
El comando at se utiliza para someter trabajos al demonio atd para que se ejecuten en
una hora específica. Los comandos que se van a ejecutar son sometidos ya sea como
script (con la opción -f) o escritos directamente via la stdin. La salida estándar del
comando se envía por correo al usuario.

at

[[-f filename] | [-m]] TIME

Opción

Efecto

-f
filename

ejecuta el script especificado por el nombre de archivo

-m

Notifica al usuario por correo electrónico cuando se ejecuta, incluso si no
hay salida.

La hora del día se puede especificar utilizando HH:MM, con el sufijo "am" o "pm". Los
términos en inglés "midnight", "noon", y "teatime" también pueden utilizarse.
Igualmente, mediante varios formatos incluyendo MM/DD/YY. (mes/día/año/). Para
mayor información refiérase a la página del manual at(1).
El luchador hogan desearía imprimir un archivo con todo el correo que ha recibido de
sus admiradores, fanmail.txt. Está un poco preocupado porque comparte la impresora
con ventura, quien también utiliza mucho la impresora. Como quiere evitar peleas,
decide demorar su trabajo de impresión hasta las 2:00 de la mañana.
[hogan@station hogan]$ at 2:00 am
warning: commands will be executed using (in order) a) $SHELL b) login
shell c)
/bin/sh
at> lpr fanmail.txt
at> CTRL-D
job 7 at 2003-06-17 02:00

47

Managing Processes
Dado que hogan no utilizó la opción -f, el comando at le pidió teclear sus comandos
mediante la stdin (el teclado). Afortunadamente, hogan sabía que cuando la secuencia
CONTROL-D, se escribe directamente desde una terminal indica un "fin de archivo".
Como alternativa pudo haber entubado el comando dentro de la stadin directamente:
[hogan@station hogan]$ echo "lpr fanmail" | at 2:00 am
shell c)
/bin/sh
job 7 at 2003-06-17 02:00

Luego, hogan confirma que su trabajo se ha registrado con atq.
[hogan@station hogan]$ atq
7
2003-06-17 02:00 a hogan

Por último, hogan recuerda que ventura está en vacaciones por lo tanto puede imprimir
la correspondencia de sus admiradores sin ningún problema. Decide cancelar su trabajo
at e imprimir el archivo directamente.
[hogan@station hogan]$ atrm 7
[hogan@station hogan]$ lpr fanmail.txt

Retraso de tareas con batch
El comando batch, al igual que el comando at, se utiliza para retrasar tareas. A
diferencia del comando at, batch no ejecuta el comando at en un tiempo específico,
sino que espera hasta que el sistema se desocupe de otras tareas a cualquier hora. Si la
máquina no está ocupada cuando se somete un trabajo, el trabajo podría ejecutarse
inmediatamente. El demonio atd controla el loadavg (promedio de carga) del sistema y
espera que baje por debajo de 0.8 antes de ejecutar el trabajo.
El comando batch tiene una sintaxis idéntica al comando at, donde los trabajos pueden
ser especificados con la stadin o sometidos como un lote con la opción -f. Si la hora se
especifica, el batch se demorará observando la máquina hasta el tiempo especificado.
En ese momento batch comenzará a controlar el loadavg del sistema, y ejecutará el
trabajo cuando el sistema no esté de otra manera ocupado.
Resumen de los comandos at
El siguiente cuadro resume el comando utilizado al registrar trabajos con el demonio
atd.

Table 1. Comandos relacionados con el servicio at

48

Managing Processes
command

uso

atd

El demonio que ejecuta trabajos sometidos. Los usuarios no utilizan el
comando atd directamente.

at

Somete trabajos al demonio atd para que se ejecuten en un tiempo
específico.

batch

Somete trabajos al demonio atd para que se ejecuten cuando el sistema no
esté ocupado.

atq

Lista trabajos en espera con el demonio atd.

atrm

Cancela un trabajo en espera con el demonio atd antes de ejecutarse.

Ejemplos
Someter un trabajo at como un archivo
El usuario hogan ha desarrollado ahora el hábito de imprimir su correspondencia de sus
admiradores a las 2:00 de la mañana. También ha descubierto el comando enscript, el
cual reformatea archivos de texto imprimiéndolos "2up" (dos páginas de texto impresas
por páginas) y representa la página impresa con encabezados informativos y pies de
página. Después de una corta experiencia desarrolla la siguiente opción para formatear
la página a su gusto: enscript -r2 -G --header="Fan Mail" --borders fanmail.txt.
Dado que hogan no quiere teclear este comando y todas las opciones a cada rato, crea
un guión corto con el (o los) comando(s) que desearía ejecutar en un archivo llamado
fanmail.at:
[hogan@station hogan]$ cat fanmail.at
enscript -r2 -G --header="Fan Mail" --borders fanmail.txt

Ahora, cuando hogan quiere someter a impresión su correspondencia de la fanaticada
puede simplemente especificar el script a at con la opción -f.
[hogan@station hogan]$ at -f fanmail.at 2:00 am
shell c)
/bin/sh
job 11 at 2003-06-18 02:00
11
2003-06-18 02:00 a hogan

Examen de la sintaxis Spool
El usuario ventura ha notado que hogan tiene la costumbre de imprimir la
correspondencia de sus admiradores a las 2:00 am y como un chiste práctico decide
someter un trabajo de su propiedad. Crea el archivo bogus_fanmail.txt, que falsifica
correspondencia no muy elogiosa de sus fanáticos. Somete un trabajo que imprimirá el
archivo a la 1:59 am confiando que hogan no notará la inserción cuando recoja los
papeles de la impresora en la mañana.

9 managing processes

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (20)

Similar a 9 managing processes

Similar a 9 managing processes (20)

Más de Juan Camilo

Más de Juan Camilo (11)

Último

Último (20)

9 managing processes