SlideShare una empresa de Scribd logo
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
Ejercicios en línea
Lab Exercise
Objetivo: Explorar diferentes estados de procesos
Estimated Time: 10 mins.
Especificaciones
1. Con el fin de explorar los estados de procesos debemos crear procesos que estén
compitiendo por los mismos recursos. Utilice un editor de texto sencillo para
crear el siguiente guión, almacénelo como ~/clobber_it.sh y hágalo
ejecutable.
2.
3.
4.
5.
6.
7.

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

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

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

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

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 &
maxwell]$ cat /dev/zero > /dev/null &
maxwell]$ cat /dev/zero > /dev/null &
maxwell]$ cat /dev/zero > /dev/null &

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

NI

SIZE

RSS SHARE STAT %CPU %MEM

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

352
352
352
3596
352
1108

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

852
692
52
0

R
R
R
R
R
R N
R
S
S
SW

83.5%

TIME CPU

19.3
19.3
19.3
17.4
16.4
4.8

0.1
0.1
0.1
9.7
0.1
1.8

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

2.9
1.9
0.0
0.0

0.4
6.5
0.0
0.0

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

0
0
0
0
0
0

cat
cat
cat
jade
cat

0 top
0 X
0 init
0

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

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
cat /dev/zero >/dev/null
[5]
Terminated
cat /dev/zero >/dev/null
[6]
Terminated
cat /dev/zero >/dev/null

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

TIME CPU
0:51

0

0:00
47:01
0:21

0 top
0 X
0 rhn-

0:04

0 init
26

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

Ejercicios en línea
Lab Exercise
Objetivo: Cambiar las prioridades de los procesos.
Estimated Time: 10 mins.
Especificaciones
1. Ejecutar el siguiente comando en una terminal.
2.

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

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

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
39) SIGRTMIN+6 40) SIGRTMIN+7 41) SIGRTMIN+8
43) SIGRTMIN+10 44) SIGRTMIN+11 45) SIGRTMIN+12
47) SIGRTMIN+14 48) SIGRTMIN+15 49) SIGRTMAX-15
51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11
55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3
63) SIGRTMAX-1

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

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

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

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

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
[einstein@station einstein]$ ps
PID TTY
TIME CMD
7985 pts/5
00:00:00 bash
8375 pts/5
00:00:01 cat
8376 pts/5
00:00:00 ps
[einstein@station einstein]$ kill -15 8375
[einstein@station einstein]$
[1]+ Terminated
cat /dev/zero >/dev/null

SIGTERM (número de señal 15) es la señal por defecto para el comando kill, por lo
tanto einstein pudo haber utilizado kill 8375 para el mismo efecto. A continuación,
einstein repite la secuencia, esta vez enviando un SIGKILL.
[einstein@station einstein]$ cat /dev/zero > /dev/null &
[1] 8387
[einstein@station einstein]$ ps
PID TTY
TIME CMD
7985 pts/5
00:00:00 bash
8387 pts/5
00:00:01 cat
8388 pts/5
00:00:00 ps
[einstein@station einstein]$ kill -9 8387
[einstein@station einstein]$
[1]+ Killed
cat /dev/zero >/dev/null

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

El comando pkill
35

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.
[maxwell@station maxwell]$ pgrep -lu maxwell
2112 bash
2146 mozilla-bin
2155 mozilla-bin
2156 mozilla-bin
2157 mozilla-bin
2329 mozilla-bin
2597 xclock
[maxwell@station maxwell]$ kill 2146
[maxwell@station maxwell]$ pkill xclock
[1]- Exit 15
mozilla
37

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

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

maxwell]$ pgrep -lu maxwell

maxwell]$ pkill sim
maxwell]$ pgrep -lu maxwell

maxwell]$ pkill -KILL sim
sim
maxwell]$ pgrep -lu maxwell

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

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

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

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

Deliverables
Question 1

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

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

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

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.
[einstein@station einstein]$
[2]+ Exit 1
>oldfiles.tx
t 2>/dev/null

find / -user einstein -and -mtime +14

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

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

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

&
&
&
&

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

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

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

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

STAT START
S
15:56
S
16:20

TIME COMMAND
0:00 -bash
0:00

S

16:20

0:00

T

16:20

0:00

S

16:20

0:00

R

16:34

0:00 ps u

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

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

&
&
&
&

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

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

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

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

Acción

trabajos Lista todos los trabajos
fg [N]

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

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

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

kill %N

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

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

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

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

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

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

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

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

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

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

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

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

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
warning: commands will be executed using (in order) a) $SHELL b) login
shell c)
/bin/sh
job 7 at 2003-06-17 02:00

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

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

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

Table 1. Comandos relacionados con el servicio at
48

Managing Processes
command

uso

atd

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

at

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

batch

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

atq

Lista trabajos en espera con el demonio atd.

atrm

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

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

Ahora, cuando hogan quiere someter a impresión su correspondencia de la fanaticada
puede simplemente especificar el script a at con la opción -f.
[hogan@station hogan]$ at -f fanmail.at 2:00 am
warning: commands will be executed using (in order) a) $SHELL b) login
shell c)
/bin/sh
job 11 at 2003-06-18 02:00
[hogan@station hogan]$ atq
11
2003-06-18 02:00 a hogan

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

Más contenido relacionado

La actualidad más candente

Tutorial 18pag
Tutorial 18pagTutorial 18pag
Tutorial 18pag
eckoby
 
Actividad v administración y comandos básicos if04 emerson
Actividad v administración y comandos básicos if04 emersonActividad v administración y comandos básicos if04 emerson
Actividad v administración y comandos básicos if04 emerson
Emerson Gonzalez IF04 T I
 
Ayuda para Redes
Ayuda para RedesAyuda para Redes
Ayuda para Redes
Lindbergh Bonilla Durán
 
Maria jose hernandez c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...
Maria jose hernandez   c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...Maria jose hernandez   c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...
Maria jose hernandez c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...
MariaJoseHernndez2
 
Servicios de impresión de gnu linux
Servicios de impresión de gnu linuxServicios de impresión de gnu linux
Servicios de impresión de gnu linux
XavierBeltran7
 
Linux
LinuxLinux
Tutorial Comandos
Tutorial ComandosTutorial Comandos
Tutorial Comandos
eguzman
 
Mis comandos favoritos en linux parte 2
Mis comandos favoritos en linux parte 2Mis comandos favoritos en linux parte 2
Mis comandos favoritos en linux parte 2
Carlos Antonio Leal Saballos
 
876t
876t876t
Linux comandos 1
Linux comandos 1Linux comandos 1
Linux comandos 1
Manuel Antonio Arroyo Arceo
 
Administración y comandos básicos del sistema - diapositiva - IF04
Administración y comandos básicos del sistema - diapositiva - IF04Administración y comandos básicos del sistema - diapositiva - IF04
Administración y comandos básicos del sistema - diapositiva - IF04
KiKn3
 
Comandos linux
Comandos linuxComandos linux
Comandos linux
Galo Apolo L.
 
Semana 9 entradas salidas estandar y pipes
Semana 9 entradas salidas estandar y pipesSemana 9 entradas salidas estandar y pipes
Semana 9 entradas salidas estandar y pipes
victdiazm
 
Comandos GNU/Linux-Unix y programación shell.
Comandos GNU/Linux-Unix y programación shell.Comandos GNU/Linux-Unix y programación shell.
Comandos GNU/Linux-Unix y programación shell.
Alan Resendiz
 
Script Y Comandos De Linux
Script Y Comandos De LinuxScript Y Comandos De Linux
Script Y Comandos De Linux
silvanetorres
 
Comandos consola-windows-xp
Comandos consola-windows-xpComandos consola-windows-xp
Comandos consola-windows-xp
Rafael Tobar Jame
 
Mis comandos favoritos en linux parte 1
Mis comandos favoritos en linux parte 1Mis comandos favoritos en linux parte 1
Mis comandos favoritos en linux parte 1
Carlos Antonio Leal Saballos
 
Mis comandos favoritos en linux parte 3
Mis comandos favoritos en linux parte 3Mis comandos favoritos en linux parte 3
Mis comandos favoritos en linux parte 3
Carlos Antonio Leal Saballos
 

La actualidad más candente (18)

Tutorial 18pag
Tutorial 18pagTutorial 18pag
Tutorial 18pag
 
Actividad v administración y comandos básicos if04 emerson
Actividad v administración y comandos básicos if04 emersonActividad v administración y comandos básicos if04 emerson
Actividad v administración y comandos básicos if04 emerson
 
Ayuda para Redes
Ayuda para RedesAyuda para Redes
Ayuda para Redes
 
Maria jose hernandez c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...
Maria jose hernandez   c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...Maria jose hernandez   c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...
Maria jose hernandez c.i. 27.878.738 - seccion pnf if-02 t1 f2 - administra...
 
Servicios de impresión de gnu linux
Servicios de impresión de gnu linuxServicios de impresión de gnu linux
Servicios de impresión de gnu linux
 
Linux
LinuxLinux
Linux
 
Tutorial Comandos
Tutorial ComandosTutorial Comandos
Tutorial Comandos
 
Mis comandos favoritos en linux parte 2
Mis comandos favoritos en linux parte 2Mis comandos favoritos en linux parte 2
Mis comandos favoritos en linux parte 2
 
876t
876t876t
876t
 
Linux comandos 1
Linux comandos 1Linux comandos 1
Linux comandos 1
 
Administración y comandos básicos del sistema - diapositiva - IF04
Administración y comandos básicos del sistema - diapositiva - IF04Administración y comandos básicos del sistema - diapositiva - IF04
Administración y comandos básicos del sistema - diapositiva - IF04
 
Comandos linux
Comandos linuxComandos linux
Comandos linux
 
Semana 9 entradas salidas estandar y pipes
Semana 9 entradas salidas estandar y pipesSemana 9 entradas salidas estandar y pipes
Semana 9 entradas salidas estandar y pipes
 
Comandos GNU/Linux-Unix y programación shell.
Comandos GNU/Linux-Unix y programación shell.Comandos GNU/Linux-Unix y programación shell.
Comandos GNU/Linux-Unix y programación shell.
 
Script Y Comandos De Linux
Script Y Comandos De LinuxScript Y Comandos De Linux
Script Y Comandos De Linux
 
Comandos consola-windows-xp
Comandos consola-windows-xpComandos consola-windows-xp
Comandos consola-windows-xp
 
Mis comandos favoritos en linux parte 1
Mis comandos favoritos en linux parte 1Mis comandos favoritos en linux parte 1
Mis comandos favoritos en linux parte 1
 
Mis comandos favoritos en linux parte 3
Mis comandos favoritos en linux parte 3Mis comandos favoritos en linux parte 3
Mis comandos favoritos en linux parte 3
 

Destacado

Bimestral Primer Periodo
Bimestral Primer PeriodoBimestral Primer Periodo
Bimestral Primer Periodo
IsabellaOM
 
Presentación1
Presentación1Presentación1
Presentación1
panoramicobyn
 
Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...
Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...
Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...
E-Plus Gruppe
 
Filmakademie baden württemberg
Filmakademie baden württembergFilmakademie baden württemberg
Filmakademie baden württemberg
araeshawen
 
Los medios de comunicacion
Los medios de comunicacionLos medios de comunicacion
Los medios de comunicacion
An_Spark
 
Prinzipien Behavioral Change
Prinzipien Behavioral Change Prinzipien Behavioral Change
Prinzipien Behavioral Change
ZBEN - Zurich Behavioral Economics Network
 
NETECH BULLS: CCNA Course in Gurgaon
NETECH BULLS: CCNA Course in GurgaonNETECH BULLS: CCNA Course in Gurgaon
NETECH BULLS: CCNA Course in Gurgaon
Netech Bulls
 
Gigantografia
GigantografiaGigantografia
Gigantografia
Tess Carbajal
 
The BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel's
The BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel'sThe BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel's
The BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel's
Young & Rubicam Germany
 
Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos.
Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos. Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos.
Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos.
Ecommaster
 
Elcuerpohumano11
Elcuerpohumano11Elcuerpohumano11
Elcuerpohumano11
Euge Coria
 
Consulta y operaciones
Consulta y operacionesConsulta y operaciones
Consulta y operaciones
4942re
 
Raices
RaicesRaices
Auto evaluacion
Auto evaluacionAuto evaluacion
Auto evaluacion
Yuranis Cuesta Salas
 
Instituto tecnologico superio1
Instituto tecnologico superio1Instituto tecnologico superio1
Instituto tecnologico superio1
Erika Carrillo
 
Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]
Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]
Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]
Marcel Schöne
 
Proyecto De Vida
Proyecto De VidaProyecto De Vida
Proyecto De Vida
Majo1994
 
0.5 enlaces químicos
0.5 enlaces químicos0.5 enlaces químicos
0.5 enlaces químicos
Daniel Lopez Hormazabal
 
Trabajo de definiciones revisado
Trabajo de definiciones revisadoTrabajo de definiciones revisado
Trabajo de definiciones revisado
ruley
 

Destacado (20)

Bimestral Primer Periodo
Bimestral Primer PeriodoBimestral Primer Periodo
Bimestral Primer Periodo
 
Presentación1
Presentación1Presentación1
Presentación1
 
Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...
Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...
Aktuelle Studie von Ortel Mobile und forsa: Jeder zweite Zuwanderer träumt au...
 
Filmakademie baden württemberg
Filmakademie baden württembergFilmakademie baden württemberg
Filmakademie baden württemberg
 
Los medios de comunicacion
Los medios de comunicacionLos medios de comunicacion
Los medios de comunicacion
 
Prinzipien Behavioral Change
Prinzipien Behavioral Change Prinzipien Behavioral Change
Prinzipien Behavioral Change
 
NETECH BULLS: CCNA Course in Gurgaon
NETECH BULLS: CCNA Course in GurgaonNETECH BULLS: CCNA Course in Gurgaon
NETECH BULLS: CCNA Course in Gurgaon
 
Gigantografia
GigantografiaGigantografia
Gigantografia
 
The BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel's
The BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel'sThe BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel's
The BAV BRAND WORLD CUP 2014 Jägermeister vs. Jack Daniel's
 
Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos.
Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos. Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos.
Ricardo Carmona en Jornadas Ecommerce Universidad Rey Juan Carlos.
 
Elcuerpohumano11
Elcuerpohumano11Elcuerpohumano11
Elcuerpohumano11
 
Consulta y operaciones
Consulta y operacionesConsulta y operaciones
Consulta y operaciones
 
Raices
RaicesRaices
Raices
 
Auto evaluacion
Auto evaluacionAuto evaluacion
Auto evaluacion
 
Instituto tecnologico superio1
Instituto tecnologico superio1Instituto tecnologico superio1
Instituto tecnologico superio1
 
Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]
Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]
Medienkonvergenz von Zeitschrift und mobilem Internet [Abschlussarbeit IHK]
 
Proyecto De Vida
Proyecto De VidaProyecto De Vida
Proyecto De Vida
 
0.5 enlaces químicos
0.5 enlaces químicos0.5 enlaces químicos
0.5 enlaces químicos
 
Tipos de explotación de superficie
Tipos de explotación de superficieTipos de explotación de superficie
Tipos de explotación de superficie
 
Trabajo de definiciones revisado
Trabajo de definiciones revisadoTrabajo de definiciones revisado
Trabajo de definiciones revisado
 

Similar a 9 managing processes

Curso de software03
Curso de software03Curso de software03
Curso de software03
enriqueaco
 
arquitectura-de-linux
arquitectura-de-linuxarquitectura-de-linux
arquitectura-de-linux
William Pathernina
 
Semana 9 -_standard_io_and_pipes
Semana 9 -_standard_io_and_pipesSemana 9 -_standard_io_and_pipes
Semana 9 -_standard_io_and_pipes
victdiazm
 
Unidad 6 Yb 7 Sistemas Operativos
Unidad 6 Yb 7 Sistemas OperativosUnidad 6 Yb 7 Sistemas Operativos
Unidad 6 Yb 7 Sistemas Operativos
Chulinneitor
 
Bii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unixBii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unix
nuria garcia
 
Tipos de archivo y extensiones
Tipos de archivo y extensionesTipos de archivo y extensiones
Tipos de archivo y extensiones
José León Toro Mejias
 
Sistema Operativo Linux
Sistema Operativo LinuxSistema Operativo Linux
Sistema Operativo Linux
Diana
 
Comandos
ComandosComandos
Comandos
Ivan Zamora
 
Introducción al sistema operativo linux
Introducción al sistema operativo linuxIntroducción al sistema operativo linux
Introducción al sistema operativo linux
Anny Mora
 
Que es gnu
Que es gnuQue es gnu
Que es gnu
Jesus Chaux
 
Que es gnu
Que es gnuQue es gnu
Que es gnu
Hernan Serrato
 
Trabajo colaborativo 3
Trabajo colaborativo 3Trabajo colaborativo 3
Trabajo colaborativo 3
fabian gomez
 
Tarea 3_individual_Nelis Rivero
Tarea 3_individual_Nelis RiveroTarea 3_individual_Nelis Rivero
Tarea 3_individual_Nelis Rivero
NelisRivero
 
Sistemas operativos-linux-y-windows
Sistemas operativos-linux-y-windowsSistemas operativos-linux-y-windows
Sistemas operativos-linux-y-windows
Diego Mauricio Valencia
 
Sysinternals Suite
Sysinternals SuiteSysinternals Suite
Sysinternals Suite
Rosariio92
 
Linux
LinuxLinux
¿Qué es un sistema operativo?
¿Qué es un sistema operativo?¿Qué es un sistema operativo?
¿Qué es un sistema operativo?
Peioarteta
 
Administracion archivos
Administracion archivosAdministracion archivos
Administracion archivos
giovatovar
 
Unix JCRB
Unix JCRBUnix JCRB
Unix JCRB
JohannaCamila
 
Como instalar Unix(Johanna)
Como instalar Unix(Johanna)Como instalar Unix(Johanna)
Como instalar Unix(Johanna)
JohannaCamila
 

Similar a 9 managing processes (20)

Curso de software03
Curso de software03Curso de software03
Curso de software03
 
arquitectura-de-linux
arquitectura-de-linuxarquitectura-de-linux
arquitectura-de-linux
 
Semana 9 -_standard_io_and_pipes
Semana 9 -_standard_io_and_pipesSemana 9 -_standard_io_and_pipes
Semana 9 -_standard_io_and_pipes
 
Unidad 6 Yb 7 Sistemas Operativos
Unidad 6 Yb 7 Sistemas OperativosUnidad 6 Yb 7 Sistemas Operativos
Unidad 6 Yb 7 Sistemas Operativos
 
Bii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unixBii t03 - sistemas operarivos. windows, linux y unix
Bii t03 - sistemas operarivos. windows, linux y unix
 
Tipos de archivo y extensiones
Tipos de archivo y extensionesTipos de archivo y extensiones
Tipos de archivo y extensiones
 
Sistema Operativo Linux
Sistema Operativo LinuxSistema Operativo Linux
Sistema Operativo Linux
 
Comandos
ComandosComandos
Comandos
 
Introducción al sistema operativo linux
Introducción al sistema operativo linuxIntroducción al sistema operativo linux
Introducción al sistema operativo linux
 
Que es gnu
Que es gnuQue es gnu
Que es gnu
 
Que es gnu
Que es gnuQue es gnu
Que es gnu
 
Trabajo colaborativo 3
Trabajo colaborativo 3Trabajo colaborativo 3
Trabajo colaborativo 3
 
Tarea 3_individual_Nelis Rivero
Tarea 3_individual_Nelis RiveroTarea 3_individual_Nelis Rivero
Tarea 3_individual_Nelis Rivero
 
Sistemas operativos-linux-y-windows
Sistemas operativos-linux-y-windowsSistemas operativos-linux-y-windows
Sistemas operativos-linux-y-windows
 
Sysinternals Suite
Sysinternals SuiteSysinternals Suite
Sysinternals Suite
 
Linux
LinuxLinux
Linux
 
¿Qué es un sistema operativo?
¿Qué es un sistema operativo?¿Qué es un sistema operativo?
¿Qué es un sistema operativo?
 
Administracion archivos
Administracion archivosAdministracion archivos
Administracion archivos
 
Unix JCRB
Unix JCRBUnix JCRB
Unix JCRB
 
Como instalar Unix(Johanna)
Como instalar Unix(Johanna)Como instalar Unix(Johanna)
Como instalar Unix(Johanna)
 

Más de Juan Camilo

Instalación de un sistema Voip corporativo basado en asterisk
Instalación de un sistema Voip corporativo basado en asteriskInstalación de un sistema Voip corporativo basado en asterisk
Instalación de un sistema Voip corporativo basado en asterisk
Juan Camilo
 
10 network applications
10 network applications10 network applications
10 network applications
Juan Camilo
 
8 herramientas de procesos de string
8  herramientas de procesos de string8  herramientas de procesos de string
8 herramientas de procesos de string
Juan Camilo
 
7 standard io and pipes
7 standard io and pipes7 standard io and pipes
7 standard io and pipes
Juan Camilo
 
6 la shell bash
6 la shell bash6 la shell bash
6 la shell bash
Juan Camilo
 
5 the linux filesystem
5 the linux filesystem5 the linux filesystem
5 the linux filesystem
Juan Camilo
 
4 file ownerships and permissions
4 file ownerships and permissions4 file ownerships and permissions
4 file ownerships and permissions
Juan Camilo
 
3 users and groups
3   users and groups3   users and groups
3 users and groups
Juan Camilo
 
2 filesystem basics
2 filesystem basics2 filesystem basics
2 filesystem basics
Juan Camilo
 
11 suplemments
11 suplemments11 suplemments
11 suplemments
Juan Camilo
 
1 quick tours
1 quick tours1 quick tours
1 quick tours
Juan Camilo
 

Más de Juan Camilo (11)

Instalación de un sistema Voip corporativo basado en asterisk
Instalación de un sistema Voip corporativo basado en asteriskInstalación de un sistema Voip corporativo basado en asterisk
Instalación de un sistema Voip corporativo basado en asterisk
 
10 network applications
10 network applications10 network applications
10 network applications
 
8 herramientas de procesos de string
8  herramientas de procesos de string8  herramientas de procesos de string
8 herramientas de procesos de string
 
7 standard io and pipes
7 standard io and pipes7 standard io and pipes
7 standard io and pipes
 
6 la shell bash
6 la shell bash6 la shell bash
6 la shell bash
 
5 the linux filesystem
5 the linux filesystem5 the linux filesystem
5 the linux filesystem
 
4 file ownerships and permissions
4 file ownerships and permissions4 file ownerships and permissions
4 file ownerships and permissions
 
3 users and groups
3   users and groups3   users and groups
3 users and groups
 
2 filesystem basics
2 filesystem basics2 filesystem basics
2 filesystem basics
 
11 suplemments
11 suplemments11 suplemments
11 suplemments
 
1 quick tours
1 quick tours1 quick tours
1 quick tours
 

Último

FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
Jose Luis Jimenez Rodriguez
 
Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)
Cátedra Banco Santander
 
Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...
Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...
Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...
Juan Martín Martín
 
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docxEXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
d33673240a
 
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Cátedra Banco Santander
 
Power Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.pptPower Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.ppt
https://gramadal.wordpress.com/
 
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLAACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
JAVIER SOLIS NOYOLA
 
Imagenes-en-la-Comunicacion-Didactica.pdf
Imagenes-en-la-Comunicacion-Didactica.pdfImagenes-en-la-Comunicacion-Didactica.pdf
Imagenes-en-la-Comunicacion-Didactica.pdf
ShimmyKoKoBop
 
Escuelas Creativas Ken Robinson Ccesa007.pdf
Escuelas Creativas Ken Robinson   Ccesa007.pdfEscuelas Creativas Ken Robinson   Ccesa007.pdf
Escuelas Creativas Ken Robinson Ccesa007.pdf
Demetrio Ccesa Rayme
 
POTENCIA, EJE RADICAL Y CENTRO RADICAL.pptx
POTENCIA, EJE RADICAL Y CENTRO RADICAL.pptxPOTENCIA, EJE RADICAL Y CENTRO RADICAL.pptx
POTENCIA, EJE RADICAL Y CENTRO RADICAL.pptx
vicvictoo
 
fichas descriptivas para primaria 2023-2024
fichas descriptivas para primaria 2023-2024fichas descriptivas para primaria 2023-2024
fichas descriptivas para primaria 2023-2024
Verito51
 
Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)
Cátedra Banco Santander
 
Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)
Cátedra Banco Santander
 
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
Como hacer que te pasen cosas buenas  MRE3  Ccesa007.pdfComo hacer que te pasen cosas buenas  MRE3  Ccesa007.pdf
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
Demetrio Ccesa Rayme
 
04. ESTADÍSTICA (comunicación) (J.C) 3.pptx
04. ESTADÍSTICA (comunicación) (J.C) 3.pptx04. ESTADÍSTICA (comunicación) (J.C) 3.pptx
04. ESTADÍSTICA (comunicación) (J.C) 3.pptx
jvcar1815
 
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
nelsontobontrujillo
 
Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)
Cátedra Banco Santander
 
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptxPonencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
yaduli
 
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
MariaAngelicaMachica
 
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLADIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
JAVIER SOLIS NOYOLA
 

Último (20)

FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
 
Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)
 
Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...
Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...
Soluciones Examen de Selectividad. Geografía julio 2024 (Convocatoria Extraor...
 
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docxEXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
 
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)
 
Power Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.pptPower Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.ppt
 
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLAACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
 
Imagenes-en-la-Comunicacion-Didactica.pdf
Imagenes-en-la-Comunicacion-Didactica.pdfImagenes-en-la-Comunicacion-Didactica.pdf
Imagenes-en-la-Comunicacion-Didactica.pdf
 
Escuelas Creativas Ken Robinson Ccesa007.pdf
Escuelas Creativas Ken Robinson   Ccesa007.pdfEscuelas Creativas Ken Robinson   Ccesa007.pdf
Escuelas Creativas Ken Robinson Ccesa007.pdf
 
POTENCIA, EJE RADICAL Y CENTRO RADICAL.pptx
POTENCIA, EJE RADICAL Y CENTRO RADICAL.pptxPOTENCIA, EJE RADICAL Y CENTRO RADICAL.pptx
POTENCIA, EJE RADICAL Y CENTRO RADICAL.pptx
 
fichas descriptivas para primaria 2023-2024
fichas descriptivas para primaria 2023-2024fichas descriptivas para primaria 2023-2024
fichas descriptivas para primaria 2023-2024
 
Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)Plataformas de vídeo online (2 de julio de 2024)
Plataformas de vídeo online (2 de julio de 2024)
 
Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)
 
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
Como hacer que te pasen cosas buenas  MRE3  Ccesa007.pdfComo hacer que te pasen cosas buenas  MRE3  Ccesa007.pdf
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
 
04. ESTADÍSTICA (comunicación) (J.C) 3.pptx
04. ESTADÍSTICA (comunicación) (J.C) 3.pptx04. ESTADÍSTICA (comunicación) (J.C) 3.pptx
04. ESTADÍSTICA (comunicación) (J.C) 3.pptx
 
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
2. LA ENERGIA Y TIPOSGRADO SEXTO.SANTA TERESApptx
 
Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)Curación de contenidos (1 de julio de 2024)
Curación de contenidos (1 de julio de 2024)
 
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptxPonencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
 
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
 
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLADIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
DIBUJANDO CON MATEMÁTICA LA GIMNASIA OLÍMPICA. Por JAVIER SOLIS NOYOLA
 

9 managing processes

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