Вы находитесь на странице: 1из 43

GESTIN

DE PROCESOS
Y ARRANQUE

Ernesto Prez (autor textos 2005-2008)


Ricardo Ortega (redaccin
diseo grfico 2010)

de

textos

http://aula.virtualepn.edu.ec
infovirtual@cec-epn.edu.ec

Capacitacin en Modalidad Virtual


Administracin Linux I, Gestin de Procesos y Arranque
Ricardo Ortega

Levantamiento de texto 2008: Ernesto Prez


Redaccin de textos 2010: Ricardo Ortega

Registro de derecho autoral: en trmite


ISBN de este volumen: en trmite
Depsito Legal: en trmite
Publicado en http://aula.virtualepn.edu.ec desde Abril 2008

CENTRO DE EDUCACIN CONTINUA


ESCUELA POLITCNICA NACIONAL
DIRECCIN DE CAPACITACIN Y CONSULTORA
CAPACITACIN EN MODALIDAD VIRTUAL
Quito Ecuador

ADMINISTRACIN DE LINUX I
Gestin de Procesos y Arranque
Material para la modalidad virtual
Master Ricardo B. Ortega O.

www.ricardoortega.com

Objetivos del captulo 4


Entender qu es un proceso en Linux.
Conocer los conceptos de gestin de procesos en Linux.
Aprender a usar las herramientas para monitoreo y trabajo con procesos.
Conocer los sistemas de arranque y parada de Linux.
Entender cmo y para qu funcionan los demonios del sistema.

Prerrequisitos para el captulo 4


Tener instalado y funcionando un computador con Linux CENTOS
Conocer los comandos de Linux

Recursos necesarios para el captulo 4


Un computador con Linux CENTOS instalado y funcionando.
La administracin de procesos y gestin de arranque se debe hacer desde el usuario root.

Recomendaciones para el captulo 4


LINUX CENTOS Nos limitaremos a explicar el funcionamiento de CENTOS. Las pruebas en otras
distribuciones quedan a su propia cuenta y riesgo.
MODO TEXTO a menos que se indique otra cosa, todos los comandos se deben escribir desde una
sesin de bash desde el usuario root. Si se dice escriba system-config-users se est diciendo
precisamente eso: desde el bash, escriba ese texto y presione ENTER.
CUIDADO CON LOS PROCESOS DEL SISTEMA: Si termina o baja la prioridad de un proceso del
sistema, tendr serias dificultades. Antes de alterar nada, infrmese.
LEA LOS MENSAJES: Observe los mensajes que le aparecen. No pase por alto los mensajes de error.
La mayora de usuarios no lee los mensajes y cuando se le pregunta qu deca el mensaje la
respuesta es no s, nunca leo los mensajes. Por supuesto que esa actitud no es propia de aspirantes
a administradores de redes.

Contenidos del captulo 4


OBJETIVOS DEL CAPTULO 4.................................................................................................................................... 3
3

PRERREQUISITOS PARA EL CAPTULO 4 ............................................................................................................. 3


RECURSOS NECESARIOS PARA EL CAPTULO 4 ................................................................................................ 3
RECOMENDACIONES PARA EL CAPTULO 4 ....................................................................................................... 3
CONTENIDOS DEL CAPTULO 4 ............................................................................................................................... 3
4.1 ADMINISTRACIN DE PROCESOS ..................................................................................................................... 4
4.1.1 Trminos generales ............................................................................................................................................ 4
4.1.2 Nice Level o nivel de amabilidad ....................................................................................................................... 5
4.1.3 Fork y exec ........................................................................................................................................................ 5
4.1.4 Formas de usar el exec ...................................................................................................................................... 6
4.1.5 Estados de un proceso ....................................................................................................................................... 7
4.1.6 Seales ............................................................................................................................................................... 7
4.2 CONTROL DE PROCESOS ................................................................................................................................... 11
4.3 HERRAMIENTAS PARA MONITOREO Y TRABAJO CON PROCESOS ...................................................... 14
Matando procesos: ................................................................................................................................................... 20
Cmo podemos hacer para matar varios procesos a la vez? ................................................................................. 21
Cambios de prioridad a los procesos ....................................................................................................................... 21
RENICE: ................................................................................................................................................................... 22
COMANDO NOHUP ................................................................................................................................................ 23
Otras herramientas de monitoreo ............................................................................................................................. 24
4.4 SISTEMA DE ARRANQUE Y PARADA ............................................................................................................... 27
Servicios: .................................................................................................................................................................. 27
Xinetd ........................................................................................................................................................................ 29
Descripcin y localizacin de recursos .................................................................................................................... 30
Netsysv, chkconfig y service...................................................................................................................................... 31
Demonios del sistema ............................................................................................................................................... 35
Arranque y parada de Linux ..................................................................................................................................... 39
La BIOS .................................................................................................................................................................... 39
El gestor de arranque ............................................................................................................................................... 40
Otros gestores de arranque ...................................................................................................................................... 40
El kernel .................................................................................................................................................................... 40
Programa /sbin/init ................................................................................................................................................... 41

4.1 Administracin de procesos


4.1.1 Trminos generales
Una de las cuestiones ms interesantes y tiles en Linux es, definitivamente, el manejo de procesos. Por
eso comenzamos con la teora y elementos previos. Un proceso es un programa que est corriendo en el
Sistema Operativo y consume recursos de memoria, cpu, dispositivos. Los procesos se caracterizan por
tener asignada un rea de memoria la cual se divide en rea de datos y rea de cdigo.
Los procesos pueden ser de un mismo programa (por ejemplo, pensemos en dos navegadores Firefox
corriendo en nuestra mquina; estos seran dos procesos separados).
En Linux tenemos muchas formas para manejar procesos, podemos ejecutarlos, o sencillamente cambiarles
la prioridad; tambin se pueden matar.

4.1.2 Nice Level o nivel de amabilidad


Todos los procesos de Linux corren bajo lo que se conoce como colas de prioridad con roundrobin; es decir
que cada nivel de prioridad, sealado por un nmero del -20 (ms prioridad) al +20 (menos prioridad),
mantiene, a su vez, una lista de procesos bajo su control.
Los procesos de una cola slo son ejecutados cuando las colas con ms prioridad a su nivel hayan
procesado todas sus listas de prioridad.
Tambin conocidos como nice levels (niveles de amabilidad o gentileza), los procesos pueden ser
asignados por el usuario que ejecuta un proceso o por el administrador del sistema.
Veamos un ejemplo tabulado de colas de prioridad: -20
Prioridad -19

SWAP

apache pop3 sendmail 10

firefox

respaldos 20

Menor

Mayor

panelcontrol

Prioridad

En la tabla de ejemplo anterior, el proceso que maneja la swap siempre tendr mayor prioridad que
cualquier otro proceso en un nice level inferior; los procesos que estn en la cola de prioridad 0, son los
iniciados por el sistema (normalmente se inician con prioridad 0) y, en esa cola, todos sern atendidos por
round robn, es decir, uno a la vez.

El Round Robn permite que se alternen los procesos en el procesador, de forma cclica. Por ejemplo, un
round robin en el nivel 0 se trabajara de forma cclica, asignndose tiempo de procesador de la siguiente
forma:
firefox -> apache -> pop3 -> sendmail -> firefox -> apache -> pop3 -> sendmail -> firefox -> apache -> pop3 > sendmail -> firefox -> apache -> pop3 -> sendmail -> y as sucesivamente en forma cclica. En esto
consiste el round robn.
En la prioridad 10, tenemos en el ejemplo un panel de control (le dejamos mejores prioridades a los
procesos con los que el sistema necesita trabajar rpidamente) de tal forma, que ste slo se ejecutar en
los momentos que el procesador no est atendiendo a las colas superiores. En este mismo nivel estn los
respaldos, de manera que cuando se estn haciendo, los respaldos no afecten a otros procesos, sino que
se vayan realizando a medida que quede libre el procesador.
Los nice levels (niveles de gentileza) pueden verse en un ejemplo de la vida real: Usted est haciendo cola
para el trole o para un bus, es el primero de la fila, y llega una seora embarazada, como usted es gentil, la
deja pasar. Usted ha bajado su prioridad, ha demostrado su gentileza, dejndole subir. Por tanto: Mientras
ms gentil uno es, menos prioridad tiene. As lo ve Linux.

4.1.3 Fork y exec


fork y exec son llamadas al sistema de Unix. Es la forma comn en que los procesos de unix crean nuevos
procesos. Tambin se les llaman procesos padres a los que crean otros procesos, que, por tanto, son
llamados hijos.
Cuando se inicia un sistema Linux, este arranca solamente con el proceso conocido como /sbin/init.

Existen dos formas de que un padre arranque (o engendre) a un hijo: exec: El padre arranca al hijo pero
dndole al hijo su memoria RAM. Es decir, el padre desaparece del sistema y, en su lugar, es ocupado por
el hijo. Fork (bifurcacin): El padre necesita permanecer vivo, por ello crea una copia de s mismo en un
rea aparte de memoria, y esta copia comete suicidio ejecutando un exec para que el hijo le reemplace.
Quedan entonces el padre y el hijo en memoria (el hijo ocupando el lugar de la copia del padre).

Un buen ejemplo del uso de fork/exec se puede ver en el login de un sistema Unix desde un terminal. El
proceso init engendra una serie de procesos getty, cada uno de ellos monitorea un puerto serial o consola
(ttyS o tty) en espera de actividad. Es el programa getty el que realmente pone la lnea que dice: login:
CentOS relase 5 (Final)
Kernel 2.6.18-53.1.19.el5 on an x86_64
servidor login:

Una vez que alguien escriba su username el trabajo del getty est terminado, este hace un exec al
programa /sbin/login. /sbin/login y entonces nos pide una clave (si la cuenta la tuviere) y si esta clave es la
correcta, entonces realiza un exec del shell del usuario (comnmente bash). Cada vez que ejecutemos un
programa dentro del shell, este har un fork de s mismo y su copia realizar un exec de cualquier programa
que le hayamos requerido. Como s que se hizo un fork? Porque al ejecutar un programa desde el shell, el
shell no se pierde definitivamente sino que regresa al finalizarse el programa.
CentOS relase 5 (Final)
Kernel 2.6.18-53.1.19.el5 on an x86_64
servidor login: root
Password: [root@servidor i

En caso de que no quisiramos que el bash hiciera un fork; hay un comando llamado exec que se puede
usar desde el prompt del sistema. Hay que usarlo con atencin pues en efecto ste ejecutar cualquier
programa que iniciemos a travs de l y eliminar la copia del shell que estemos usando sustituyndola por
el programa en cuestin.

Es muy til si queremos dejar corriendo una aplicacin que no le permita al usuario salir de ella hacia un
shell: pues tan pronto termine la ejecucin de la aplicacin, se realizar un logout ya que el shell, que se
ejecut desde el login, habr sido sustituido previamente mediante un exec por la aplicacin. Es decir, no
quedaran ms recursos detrs de este hijo y se saldra a la pantalla del login.
4.1.4 Formas de usar el exec
Veamos un ejemplo: Supongamos que tenemos que dejar un shell abierto ejecutando un ping a Internet de
forma tal que, si algn operador ve que el ping no responde, l pueda tomar ciertas medidas. Sin embargo
no queremos que este operador tenga acceso al shell y, por ello, una variante muy cmoda sera que
acceda desde el shell ejectar:
exec ping www.google.com

exec, se ocupa de reemplazar el shell (bash) por el programa que le indicamos (ping en este caso). Ya no
existe bash, tan slo es el ping.
De esta forma, el ping se estar ejecutando indefinidamente, hasta que se presione AC, entonces se saldr
directamente sin caer en ningn momento en el shell, ya que se us un exec y no un fork.
Ejercicio: probar el comando anterior, notar como al finalizar el ping (apretando AC) no se regresa al shell
sino que se cierra la sesin.
4.1.5 Estados de un proceso
Los procesos se pueden catalogar en 3 estados fundamentales (aunque existen otros):
1. Running: Es cuando un proceso est haciendo uso del procesador, o est en la lista de espera por el
procesador (Runnable)
2. Stopped: Es cuando un proceso voluntariamente se retira del procesador y solicita que no le
asigne procesador; este proceso, posiblemente, est bloqueado esperando por alguna instruccin
de e/s (disco, teclado, etc)
3. Zombie: Es cuando un proceso ha muerto, pero su tarea padre sigue esperando informacin de
ste. Estos procesos no se pueden matar, tcnicamente no existen, pero consumen recursos en la
tabla de procesos. De vez en cuando, el kernel puede limpiarlos, sobre todo si el proceso padre
tambin muere.

4.1.6 Seales
Las seales son formas de comunicarse entre procesos en Linux. Los procesos se envan mensajes a
travs del kernel, y los procesos de destino del mensaje debern obedecer o el kernel mismo podr
aceptarlas.

Las seales se envan a los procesos mediante un comando conocido como kill (matar).

Las seales pueden ser de 64 tipos diferentes; estn numeradas de forma tal que puedan ser diferenciadas
por el kernel. Las ms comunes, que estudiaremos aqu son
Nombre
SIGHUP
SIGKILL
SIGUSR1
SIGTERM

Nmero
1
9
10
15

HUP (nmero 1) Hangup (colgar) Recarga la configuracin. Es til para cuando se ha cambiado el
archivo de configuracin de un proceso y se requiere que el proceso lo relea, se le enva la seal 1
y el proceso se ocupar de releer la configuracin y se recargar sin dejar de atender a los
usuarios.

KILL (nmero 9) Mata un proceso de forma incondicional; esta seal no se ocupa de cerrar
organizadamente archivos abiertos ni de emitir ninguna advertencia, sencillamente, cuando el
kernel ve esta seal elimina el proceso de la tabla de procesos y dispone de la memoria ocupada
previamente por ste.

USR1 (Nmero 10) Es una seal para ser usada por diferentes procesos como el bash; es una
forma de matar el bash, por ejemplo, pues ste no obedece a la seal TERM. Se le conoce como:
seal a ser definida por el usuario (el programador). El programador de este programa define para
qu utilizar la seal USR1. Nos limitaremos a utilizarla en el bash.

TERM (nmero 15) Terminar. Esta seal indica a un proceso que debe cerrarse; el proceso,
entonces, proceder como mejor le convenga, posiblemente cerrando todos los archivos que tiene
abierto y mandando a liberar la memoria que ocupa en el sistema. Algunos procesos a veces caen
en un estado en el que no pueden responder a esta seal y slo se dejan matar con la seal KILL
(9), pero nunca debemos intentar enviar directamente KILL sin probar enviar TERM ya que es una
forma imperiosa y un poco brusca para cerrar los procesos.

Todas estas seales as como una descripcin de las otras seales (son en total 64)) pueden ser obtenidas
con el comando: man 7 signal

4.2 Procesos, /proc y control de procesos


Profundicemos un poco ms en el tema de qu es un proceso:

El shell, que tpicamente se usa, es el GNU BASH; sin embargo, hay muchas variantes del tipo bourne
como el sh, el ksh. Tambin existen variantes del C Shell (csh) como el tcsh.

Illustration 1: Ejemplo de un shell


El shell es un proceso; es uno de los muchos programas que seguramente estn ejecutndose al mismo
tiempo en una computadora. Cada proceso tiene diferentes tipos de informacin asociado con l,
incluyendo:

El PID o identificador del proceso: Es un nmero asignado cuando el proceso ha arrancado.


Normalmente es un nmero consecutivo que solamente se repite cuando se haya alcanzado el
mximo de procesos en la tabla de procesos aunque muchos sistemas de proteccin, para evitar
que un atacante averige fcilmente el pid, prefieren hacerlo aleatorio (as, al hacerse un fork
posiblemente no ser el PID del padre+1). En todo caso, es un nmero nico para cada uno de los
procesos corriendo en un sistema.

El UID o identificador del usuario: Nos indica a quin pertenece este proceso. Determina, por lo
tanto, a qu archivos y directorios ste proceso podr escribir o podr leer adems de a quin le
ser permitido matar este proceso.

El GID o identificador del grupo: es similar al UID, pero determina a qu grupo ste pertenece.

El ambiente de trabajo o environment: Contiene una lista de variables y valores asociados. Por ejemplo, si
nosotros escribimos: echo $HOME en el shell, ste nos indicar el nombre del directorio raz del
proceso del shell. Es decir, bsicamente, nos ha indicado los contenidos de una variable de
ambiente llamada HOME.

Directorio de trabajo actual: Si no se especifica un directorio para abrir un archivo o para ejecutarlo,
el proceso mirar al directorio actual (CWD o current working directory) y proceder a tratar de
abrirlo desde ah.

Descriptores (file descriptors): Nos indicarn qu archivos ha abierto este proceso para lectura o
escritura, as como la posicin actual dentro de cada uno de ellos.

Todos estos detalles pueden ser vistos en nuestro sistema Linux. Cada proceso que se ejecuta en el
sistema, abre un "directorio" con toda su informacin dentro del directorio /proc.

/proc no es un directorio comn y corriente, sino que contiene informacin sobre los procesos, adems de
informacin sobre el sistema y nos permite realizar cambios en el comportamiento del kernel y sus
diferentes mdulos o partes.

Centrndonos en el tema de los procesos: vayamos a /proc y listemos dentro de /proc (ls /proc).
Observaremos una serie de nmeros en forma de directorio, que nos indican los PID. Dentro de cada
directorio (pid) se ven una serie de archivos que no son ms que diferentes aspectos del proceso, algunos
anteriormente descritos, como son:

cmdline: Indica la lnea de comando con que el proceso fue ejecutado; por ejemplo, si nos cambiamos a un
directorio dentro de /proc, el del proceso 9408 (cd /proc/9408) y hacemos un cat cmdline, obtendremos lo
siguiente: cat cmdline bash

Esto nos indica que el proceso 9408 es el bash, que fue ejecutado mediante una simple llamada (bash)
Por favor, no esperen ver precisamente el pid 9408, seguramente en las mquinas de ustedes se toparn
con otros nmeros, sencillamente escojan uno o varios al azar para mirar dentro.
El archivo environ: nos indica las variables de ambiente con que este proceso
trabaja:
cat environ
SSH_AGENT_PID=4877HOSTNAME=eperez.ecuaLinux.comTERM=xtermSHELL=/bi n/bashHISTSIZE =
1000USER=rootLS_COLORS = SSH_AUTH_SOCK=/tmp/ssh-KjxSWn4876/agent.4876
PATH=/usr/java/j2re1.5.0_01/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local
/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:
/root/binDESKTOP_SESSION=defaultMAIL=/var/spool/mail/rootPWD=/root
INPUTRC=/etc/inputrcJAVA_HOME=/usr/java/j2re1.5.0_01LANG=en_US.UTF8GDMSESSION=defaultSSH_ASKPASS=/usr/libexec/openssh/gnome-sshaskpassSHLVL=1
HOME=/rootLOGNAME = rootDBUS_SESSION_BUS_ADDRESS = unix:abstract=/tmp /dbuskbf74OqytDLESSOPEN=|/usr/bin/lesspipe.sh%sDISPLAY=:0.0G_BROKEN_FILENA
MES=1
10

XAUTHORITY=/root/.XauthorityGTK_RC_FILES=/etc/gtk/gtkrc:/root/.gtkrc-1.2gnome2SESSION_MANAGER=local/eperez.ecuaLinux.com:/tmp/.ICE-unix/4852
GNOME_KEYRING_SOCKET=/tmp/keyringrrJk94/socketGNOME_DESKTOP_SESSION_ID
OLORTERM=gnome-terminalWINDOWID = 37757804

DefaultDESKTOP_STARTUP_ID=C

Las variables son las que aparecen en maysculas, por ejemplo veo una llamada HISTSIZE=1000 es decir,
una variable llamada HISTORY que tiene de valor 1000.

El archivo status: Es otra variable. Contiene diversa informacin del estado actual
del proceso: cantidad de hilos, informacin sobre el pid del padre (ppid), memoria
consumida, cantidad de descriptores reservada, el estado del proceso (en este
ejemplo, est en estado de sleeping), etc.
[root@eperez 9408]# cat status
[root@eperez 9408]# cat status
Name: bash
State: S (sleeping)

El archivo cwd: Es el directorio de trabajo actual. Nos indica en qu directorio estaba el proceso padre
cuando se ejecut. Es mu til para cuando tenemos un proceso extrao, levantado por un ajeno intruso en
nuestro sistema, para saber dnde estaba el intruso cuando levant al hijo.

Si dentro del proceso, ejecutamos el comando; "cd cwd" ste nos llevar directamente al directorio en
cuestin.

El archivo exe: Es el nombre del programa ejecutable del proceso en cuestin. Es decir, es un enlace hacia
el programa que est siendo ejecutado al que pertenece el proceso.
El archivo root: Es un enlace al directorio raz del proceso (usualmente /) El directorio fd: contiene todos los
file descriptors abiertos por este proceso.
Como curiosidad si nos cambiamos (cd) al directorio /proc/self nos dar una forma fcil de llegar al proceso
desde el que estamos ejecutndonos (bash posiblemente).

4.2 Control de procesos


Normalmente cuando se est en el shell y se ejecuta un comando, este toma el control del terminal y el shell
se queda esperando a que el comando termine. Por ejemplo, ejecutemos:
tail -f /var/log/secure
11

Como podemos ver, el comando tail ocupa todo el terminal, no nos deja escribir nada ms, est trabajando.
A

Una forma de retomar el shell es apretar C, para matar el proceso de tail. Al apretar C nos retorna al shell.
Ahora: si no se desea perder control del bash y, adems, se quiere ejecutar un proceso y dejarlo corriendo
hasta que finalice, se puede hacer mediante el comando &
tail -f /var/log/maillog &
Lo que har ser hacer un tail con polling (-f: es decir que busca siempre al final del archivo).
Si se fijan, en este ejemplo, el tail se est ejecutando (eventualmente puede mostrar alguna informacin si
llega algo al archivo maillog), pero, adems, tenemos acceso al shell. Hemos ejecutado el tail en segundo
plano o background (&).
El smbolo & al final de un comando
Al agregarse este signo al final de otro comando, lo que se hace es mandar este trabajo (proceso) al fondo,
a background, a segundo plano, y mientras el trabajo est corriendo, podremos seguir usando el shell en
primer plano (foreground).
El padre (en este caso del ejemplo, el shell) no puede interactuar para cambiar al hijo, ni el hijo en el padre,
es decir, al dejar al tail en background, se pudieron mover de directorio hacia otros lugares sin que esto
afectara el directorio de trabajo del hijo (que ser el directorio desde el que se le invoc inicialmente) ni los
archivos conque el hijo trabaje.

Por ejemplo hagamos lo siguiente:

ping www.google.com & cd /var/log ls cd


Si se fijan, hemos ejecutado el comando ping en segundo plano, lo que nos permiti ejecutar otros
comandos (cd, ls) en el mismo shell, mientras el comando ping segua funcionando.
Por supuesto que es molesto, es decir, eso de ejecutar un comando mientras aparecen caracteres de la
salida de otro comando es un tema batante difcil, pero se puede lograr con cierta habilidad.

Cmo ver los procesos que se estn ejecutando en el shell?

El comando "jobs" indicar cuntos procesos estn ejecutndose en el shell as como su nmero de trabajo.
Por este nmero se les puede trabajar:

[root@eperez ~]# jobs


[1]+ Running tail -f /var/log/maillog &

12

Aqu se tiene un slo trabajo que es el trabajo nmero 1 (fjense en [1]) y es un trabajo que est corriendo
(Running)

Podemos traer los trabajos a primer plano con el comando fg %#detrabajo, por
ejemplo:
fg %1
As se llevara este trabajo a primer plano.

En el primer plano, se ha "perdido el shell" nuevamente, pues el tail ahora se est ejecutando pero no deja
acceso al shell hasta que termine.

Cmo se puede hacer para mandar un proceso a segundo plano (background)?


Hay dos alternativas:

con el &: ejecutar el proceso y al final llamarlo con &, de esta forma se le mueve a segundo plano
desde el mismo inicio.

Pero a veces ya se ha iniciado el proceso y se le quiere llevar a segundo plano, los pasos seran:
o

Detener temporalmente el proceso

o Mandar el proceso a segundo plano


Aqu la forma: (Supongamos que estamos ejecutando el tail en primer plano porque anteriormente ya le
llamamos con fg

Z : esto detiene el proceso, nos brinda un shell pero el proceso no est corriendo, est detenido,

podemos verificarlo ejecutando el comando jobs:


Stopped tail -f /var/log/maillog

bg %1 (con este comando mandamos a correr el trabajo 1 en background (bg=background) nos dir
algo as como respuesta:
tail -f /var/log/maillog &

verificamos que est corriendo con el comando jobs:

[root@eperez ~]# jobs


[1]+ Running tail -f /var/log/maillog &

Listo, lo tenemos corriendo en background a pesar de que, al inicio, estuvo en fg. Ejercicio:

13

Como ejercicio ejecutar el gnome-calculator desde un shell, detenerle (con AZ), tratar de usarle as detenido
y posteriormente ponerle en background.

4.3 Herramientas para monitoreo y trabajo con procesos


Comandos para conocer procesos ejecutndose en el sistema:
Comencemos con los comandos ms usados para analizar los procesos ejecutndose en el sistema y con
los diferentes aspectos de ellos como la memoria consumida y la prioridad.
Comandos para verificar procesos corriendo en el sistema:
El ms simple pero til de los comandos es ps, este es un comando bien conocido y no ha variado mucho al
momento
Para las personas que conocan el comando de la forma antigua, se les sugiri no usar el signo de -, pues
puede conducir a interpretaciones errneas sobre el funcionamiento.
Algunos switches tiles para ps: Al ejecutar ps sin ningn switch, nos mostrar los procesos ejecutndose
en su shell.
ps a: Muestra todos los procesos que pertenecen a una terminal, sin importar si pertenecen al shell por ellos
abierto o no.
ps a divide la pantalla en al menos 5 columnas bsicas (algunos comandos mostrarn ms informacin
adicional), estas son:

"TTY: Terminal desde donde se est corriendo el proceso

STAT: Estado del proceso o S: Sleeping


R: Runnable (o Running) el proceso puede correr o est corriendo

W: sWapped, est en

disco o N: niced, el proceso tiene ms baja prioridad o Z: Zombie, el proceso muri sin reportarle
informacin al padre o D: Uninterruptable sleep, posiblemente esperando por disco. Este
proceso NO PUEDE SER MATADO CON NINGUNA SEAL
o

T: Stopped,

< Ejecucin artificialmente cambiada

JTIME: El tiempo de procesador (en minutos: segundos) que el proceso ha consumido. Este es un
tiempo que, normalmente, no debe ser muy grande, a no ser que la mquina sea muy accesada y
lleve muchas semanas o meses corriendo sin reiniciarse. Por ejemplo, en este servidor que tengo
con ms de 50 das sin reiniciarse, el proceso que consume ms tiempo (50 minutos y 24 segundos
de procesador) es:
o

743 ? S 50:24 syslogd -m 0

COMMAND: Es el comando mediante el cual se ejecut el proceso (puede estar truncado).

Ejemplo: ps a
PID TTY STAT TIME COMMAND
14

tty1 Ss+ 0:00 /sbin/mingetty tty1


tty2 Ss+ 0:00 /sbin/mingetty tty2
4353 tty3 Ss+ 0:00 /sbin/mingetty tty3 4356 tty4 Ss+ 0:00 /sbin/mingetty tty4
tty5 Ss+ 0:00 /sbin/mingetty tty5
tty6 Ss+ 0:00 /sbin/mingetty tty6
4446 tty7 SLs+ 10:55 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth 15164 pts/0 Ss 0:00 bash 15193
pts/0 R+ 0:00 ps a
ps ax: mostrar todos los procesos independientemente de si tienen un terminal asignado o no,
independientemente de si pertenecen a este shell o no. Esta es una de las opciones ms tiles del comando
ps

Ejemplo:
ps ax
PID TTY STAT
4091 ? Ss 0:00 xfs -droppriv -daemon
4122 ? Ss 0:00 /usr/sbin/atd
4154 ? S 0:09 /usr/bin/python /usr/sbin/yum-updatesd
? Ss 0:00 avahi-daemon: running [eperez.local]
? Ss 0:00 avahi-daemon: chroot helper
? Ss 0:07 hald
? S 0:00 hald-runner
? S 0:00 hald-addon-acpi: listening on acpid socket /var/run/a
? S 0:00 /usr/libexec/hald-addon-cpufreq
4202 ? S 0:00 hald-addon-keyboard: listening on /dev/input/event1 4208 ? S 0:00 hald-addon-keyboard:
listening on /dev/input/event0 4218 ? S 0:03 hald-addon-storage: polling /dev/hdc 4261 ? Ss 0:04
/sbin/dhcdbd --system
4265 ? Ssl 0:04 NetworkManager --pid-file=/var/run/NetworkManager/Net 4347 ? S 0:00 /usr/sbin/smartd -q
never
tty1 Ss+ 0:00 /sbin/mingetty tty1
tty2 Ss+ 0:00 /sbin/mingetty tty2
tty3 Ss+ 0:00 /sbin/mingetty tty3 4356 tty4 Ss+ 0:00 /sbin/mingetty tty4
tty5 Ss+ 0:00 /sbin/mingetty tty5
tty6 Ss+ 0:00 /sbin/mingetty tty6
4365 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon

ps aux: lo mismo que el anterior, pero mostrar adems informacin del usuario que corre el proceso y variada
informacin como la memoria consumida por cada proceso.
Por ejemplo: ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2016 0.0 0.1 1576 592 ? Ss
10:43 0:00 syslogd -m 0 root 2020 0.0 0.1 2800 468 ? Ss 10:43 0:00 klogd -x rpc 2041 0.0 0.1 3392 592 ?
Ss 10:43 0:00 portmap rpcuser 2061 0.0 0.1 1752 768 ? Ss 10:43 0:00 rpc.statd root 2094 0.0 0.2 5328
1008 ? Ss 10:43 0:00 rpc.idmapd root 2160 0.0 0.1 2860 816 ? S 10:43 0:00 /usr/sbin/smartd
15

Nos indicar en la primera columna que el usuario bajo el que se ejecuta el proceso portmap se llama rpc y
bajo el que se ejecuta el proceso rpc.statd se llama rpcuser; los otros procesos son ejecutados a nombre de
root

Adems nos indicar ciertos valores extras como son:

%CPU: Porcentaje de la cpu que consumen

%MEM: Porcentaje de la memoria que consumen

VSZ: Tamao virtual del proceso, esto es, el uso de memoria por parte del cdigo (libreras y

binario) as como datos, uso del stack

RSS: Es el uso de memoria sin contar con el uso de ciertas funciones del kernel, tabla de procesos, etc.

[root@eperez ~]# pstree init|acpid |atd


|bonobo-activati
|clock-applet
|crond
|cups-config-dae |cupsd
|21[dbus-daemon-1]
|dbus-launch
|eggcups
|events/0|aio/0
| |kacpid
| |kblockd/0
| |khelper
| >22[pdflush]
|firefoxrun-mozilla.shfirefox-binnetstat
|gaim
|gam_server
|gconfd-2

1 START: Es la hora en que el proceso comenz


ps axf (tambin auxf) nos mostrar en forma de rbol los procesos del sistema, con distincin de qu
proceso engendr a quin(es). Con la u, aumentar la cantidad de informacin mostrada.
pstree: Es otra forma de obtener una estructura arbrea reducida de los procesos del sistema.
2 START: Es la hora en que el proceso comenz
ps axf (tambin auxf) nos mostrar en forma de rbol los procesos del sistema, con distincin de qu
proceso engendr a quin(es). Con la u, aumentar la cantidad de informacin mostrada.
pstree: Es otra forma de obtener una estructura arbrea reducida de los procesos del sistema.
16

|gdm-binary ------ gdm-binary|X


1

| gnome-session |gnome-keyring-d
|gnome-panel |gnome-settings|gnome-terminal|bash6ssh | |bash
1

pstree | gnome-pty-helpe |gnome-vfs-daemo |gnomevolume-ma


|gpm |hald |khubd
|23[kjournald]
|klogd
|kseriod |ksoftirqd/0
swapd0
|mapping-daemon
|metacity
|6*[mingetty]
|mixer_applet2
|named
|nautilus
|notification-ar
|pam-panel-icon ------- pam_timestamp_c
|portmap |rpc.idmapd |
rpc.statd |2*[sendmail] |smartd
|ssh-agent |sshd |syslogd
|thunderbird ------ run-mozilla.sh -------thunderbird-bin
|udevd |vmnet-bridge |wnck1

applet |xfs xinetd


Nos dar un bonito resumen de los procesos y de qu depende cada uno. El nmero delante de sendmail
indica que, a ese nivel, hay dos procesos de sendmail levantados.

4.3.2 top:
Este es uno de los comandos ms interesantes y usados para monitorear procesos, sobre todo por su
interactividad.

En cuanto se ejecuta top, se debe tener presente que cada tecla que se apriete para top tendr un
significado. Top entra por defecto en un lazo infinito mostrando cada 3 segundos una lista de los procesos
ordenados por el nmero de proceso (de menor a mayor).

3 START: Es la hora en que el proceso comenz


ps axf (tambin auxf) nos mostrar en forma de rbol los procesos del sistema, con distincin de qu
proceso engendr a quin(es). Con la u, aumentar la cantidad de informacin mostrada.
pstree: Es otra forma de obtener una estructura arbrea reducida de los procesos del sistema.
17

El top es de gran ayuda para detectar qu procesos consumen, al momento, mayor memoria o procesador y
permite tomar acciones para mejorar este consumo.
No hay que olvidar que el top es un proceso a su vez y consume tambin procesador, por lo que si se tiene
un servidor medianamente cargado no lo debemos mantener constantemente cargado pues contribuir a
cargar ms el procesador.

un ejemplo de top:
12:45:35 up 50 days, 12:08, 1 user, load average: 2.13, 2.94, 3.06 221 processes: 219 sleeping, 1 running, 1
zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle
total 21.2% 0.0% 17.0% 0.0% 2.4% 27.4% 131.4%
cpu00 8.1% 0.0% 10.1% 0.0% 1.9% 13.1% 66.5%
cpu01 13.1% 0.0% 6.9% 0.0% 0.5% 14.3% 64.9%
Mem: 2055440k av, 2005688k used, 49752k free, 0k shrd, 147416k buff
1374096k actv, 266100k in_d, 30932k in_c Swap: 2008084k av, 20972k used, 1987112k free 887724k
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
root 19 0 388 360 336 S 0.0 0.0 4:32 1 init
root RT 0 0 0 0 SW 0.0 0.0 0:00 0 migration/0
root RT 0 0 0 0 SW 0.0 0.0 0:00 1 migration/1
root 15 0 0 0 0 SW 0.0 0.0 0:00 1 keventd
root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd/0
root 34 19 0 0 0 SWN 0.0 0.0 0:00 1 ksoftirqd/1
root 15 0 0 0 0 SW 0.0 0.0 26:51 1 kswapd
root 15 0 0 0 0 SW 1.3 0.0 292:27 1 kscand
root 15 0 0 0 0 SW 0.0 0.0 0:00 1 bdflush

root 15 0 0 0 0 SW 0.0 0.0 2:31 0 kupdated


root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd 15 root 15 0 0 0 0 SW 0.3 0.0 54:51 0 kjournald
418 root 15 0 0 0 0 SW 0.0 0.0 0:00 1 kjournald

El top normalmente trabaja mostrando dos tipos de informacin: la ventana sumaria y la ventana de tareas.

La ventana sumaria es la compuesta por las primeras lneas (depende de la cantidad de procesadores):
18

12:45:35 up 50 days, 12:08, 1 user, load average: 2.13, 2.94, 3.06


221 processes: 219 sleeping, 1 running, 1 zombie, 0 stopped CPU states: cpu user nice system irq softirq
iowait idle total 21.2% 0.0% 17.0% 0.0% 2.4% 27.4% 131.4% cpu00 8.1% 0.0% 10.1% 0.0% 1.9% 13.1%
66.5% cpu01 13.1% 0.0% 6.9% 0.0% 0.5% 14.3% 64.9% Mem: 2055440k av, 2005688k used, 49752k free,
0k shrd, 147416k buff 1374096k actv, 266100k in_d, 30932k in_c Swap: 2008084k av, 20972k used,
1987112k free 887724k cached

La primera lnea indica que la hora del servidor es "12:45:35" y que el servidor ha estado activo durante 50
das, 12 horas y 8 minutos. Actualmente el sistema tiene un slo usuario conectado y la carga es de 2.13 al
momento actual, 2.94 a 5 minutos y 3.06 a 10 minutos.
La segunda lnea nos indica que el servidor tiene 221 procesos corriendo, de los cuales 219 estn
durmiendo, uno ejecutndose y un zombie.
De la tercera a la sexta lnea, se nos indican diferentes aspectos de los dos procesadores que tiene el
sistema, tales como:

Qu porcentaje del procesador se usa por procesos de usuario (no root, no del sistema) (user)

Qu porcentaje del procesador se usa por procesos que tienen un cambio de prioridad (nice)

Qu porcentaje del procesador se usa por procesos del sistema (system)

Qu porcentaje del procesador se usa para manejar irq, softirq

Qu porcentaje del procesador se usa en procesos que estn esperando por disco

Qu porcentaje del procesador est sin ocupar (idle)

De todos estos valores, el ms importante y, a la vez, ms peligroso es el iowait, porque indica que la mquina
tiene, posiblemente, un grave problema de entrada salida; seguramente de acceso al disco; si este valor
supera, digamos el 30 al 50%, es un valor que definitivamente hay que considerar cambiar mediante trabajo
de optimizacin de disco.

Las tres ltimas lneas nos indica, bsicamente, lo mismo que el comando free -k, es decir, informacin sobre el
uso de la memoria RAM de la mquina y la memoria SWAP.

4.3.2.1 Ventana de tareas del top


De aqu en adelante, trabajamos bsicamente con lo que se llama ventana de tareas, esto es una descripcin
ordenada inicialmente por el nmero de procesos en que se nos indicarn ciertos datos sobre cada uno de
los procesos relevantes como son:
pid

usuario del proceso

prioridad (es un valor asignado por el kernel, ver slices en tema anterior)

nice level

tamao del proceso y datos

RSS

SHARE: Memoria compartida con otros procesos


19

Estado

%CPU

%MEM

Tiempo consumido por el procesador

CPU bajo la que se est ejecutando el proceso

Nombre del proceso.

Estos detalles los podemos ajustar con diferentes comandos que existen dentro del top:

P: organiza los procesos por uso de CPU

M: Organiza los procesos por uso de la memoria

N: Organiza los procesos por PID (de menor a mayor)

Otros comandos tiles:

q: sale del top

s: Cambia la tasa de refrescamiento (de 3 segundos a cualquier valor que pongamos)

[ESPACIO]: Refresca automticamente sin esperar a que se completen los 3 segundos.

Espacio=Refresca ahora.

W: Escribe los cambios en la configuracin a disco; de lo contrario cualquier cambio que hagamos
con los comandos de orden o de tasa de refrescamiento no tendrn validez para la prxima vez que
ejecutemos el top

k: mata un proceso, tenemos que indicarles el nmero de proceso a eliminar y el tipo de seal que
usaremos (por defecto sugieren 15)

Ms comandos pueden ser obtenidos mediante: man top

Matando procesos:
Una de las formas ms cmodas de matar un proceso es desde el comando top. Desde el top podemos,
viendo previamente el nmero del proceso, indicarle con la letra k, el pid del proceso que deseamos eliminar
y este comando (top) se ocupar de matarlo.
Como no siempre estamos con el top ejecutndose, el comando ms adoptado para matar un proceso es el
comando kill
kill [-SEAL] <pid1> [<pid2>...<pidN>]
kill requiere de al menos un parmetro y este es el nmero del proceso que deseamos matar. De dnde
sacar el nmero de proceso?: Ver ps y top
Si no se indica la seal que se usar, el kill trabajar con la seal 15 (TERM).

kill -15 1845 es similar a:

kill 1845 pues ambas matarn al proceso 1845 con la seal 15

kill -9 1845, lo matar de forma brusca con la seal KILL (9)


20

kill -10 1845 enviar la seal 10 al proceso 1845, el bash por ejemplo no obedece a la seal 15,

es decir con la simple seal 15 no se deja matar. Al parecer est hecho para evitar un error al
matarlo, el bash solo se muere en caso de recibir la seal 10.

kill -9 1023 1024 1025 matar con la seal 9 los procesos 1023, 1024 y 1025

kill es muy til cuando se tiene que matar un proceso en especfico. Ahora, es un poco difcil si se tuvieran
que matar varios procesos a la vez (varios: es un nmero mayor de 10, se vuelve bien complejo copiar 10 o
ms pid fuera de secuencia).

Cmo podemos hacer para matar varios procesos a la vez?


Sin duda, el comando killall viene como anillo al dedo: tiene las mismas caractersticas del kill en lo que
respecta a las seales, excepto que no se pone el pid, sino que se indica el nombre del proceso a matar:

killall httpd matar, con la seal 15, TODOS los procesos httpd del sistema

killall -10 bash matar, con la seal 10, TODOS los procesos bash que estn corriendo en el
sistema.

killall -9 ping matar, con la seal 9, TODOS los potenciales procesos ping que existan en el
sistema.

killall sendmail matar TODOS los procesos sendmail que existan en el sistema.

De esta sencilla forma se mata un nombre de proceso determinado sin tener que describirle ni el nmero de
proceso ni la cantidad de procesos, puesto que matar ya sea un proceso nombrado de esta forma o
cientos o miles de procesos que se nombren as.

Siempre se debe ser muy cuidadosos a la hora de matar un proceso, pues invariablemente hay que pensar
que no somos los nicos que trabajamos con un servidor y que, por tanto, nuestras acciones pueden estar
afectando (o beneficiando) a cientos o miles de usuarios que dependen de este mismo servidor para sus
labores normales.

Tarea:
Detectar cuntos procesos bash hay en el sistema, tratar de matarlos primeramente con kill -15 (no 10!!) y
posteriormente matarlos con killall envindole la seal 10. Qu diferencias hay?

Cambios de prioridad a los procesos


nice es el comando que nos permite correr un proceso (comando) con un cambio en su nivel de niceness.

nice: sin ninguna otra opcin, nos dir el nivel de nice conque estamos corriendo (nice hereda este valor del
shell).

nice bash ejecutar el shell bash, pero lo har con un nivel de prioridad de 10 (ms bajo que 0), por ejemplo,
verifiquemos:
21

1. El primer nice que ejecutamos lo hacemos dentro de un shell con prioridad 0, por eso sale 0
2. Dentro de este shell, invocamos a un segundo shell: (nice bash), se baja automticamente la
prioridad de este programa pues lo ejecutamos con nice.
3. Es por esto que al ejecutar nuevamente nice, nos responde: 10.. que se est ejecutando dentro de
un shell con prioridad 10.
Cerremos todos los shells que abrimos (apretando Ad varias veces).
Por ejemplo, suponiendo que nuestro shell tiene un nivel de nice de 0, al ejecutar: nice -n 5 bash
Lo que har ser ejecutar el bash con un nivel de prioridad 5 (antes tenamos 0, ahora tenemos 5).

Si ahora desde este mismo shell con prioridad 5, ejecutramos: nice -n -10 bash
Lo que haramos sera llamar al bash, pero quitarle 10 niveles de prioridad (5-10=-5) por lo que haramos
correr al bash con una escala negativa, es decir con una prioridad ms alta que el comn de los procesos
(prioridad 0). Podemos verificarlos ejecutando solamente: nice
ATENCION: Los usuarios normales no pueden llamar al nice con un valor menor al valor de su shell. Es decir, si
tenemos un usuario cualquiera (digamos: eperez), y el nice de este usuario es de 0, entonces no podremos
llamar a ningn proceso con un nice menor de 0. Por la misma razn, si el nice del usuario es 10, entonces
no podremos llamar a ningn proceso con un nice menor a 10. Bsicamente, desde un usuario normal no
podemos ajustar la prioridad (-n) a ningn valor negativo.

Verifiqumoslo:
su - eperez (me convierto en el usuario eperez) nice (nos dir que 0)
nice -n -1 bash (intento ponerme con una prioridad mayor a la original ma, me negar)
nice -n 5 bash (me dejar disminuir mi prioridad, a 5) nice (en efecto me indicar
5)
nice -n -2 bash (intento nuevamente bajarme de 5 a 3, me dir que no).

RENICE:
renice permite, dado un nmero de proceso, cambiarle su prioridad
renice <prioridad> [-p pid ....] [-g grp ....] [-u user ...]

Los usuarios no root, es decir, los usuarios normales del sistema slo pueden hacer un renice de los
procesos que les pertenecen y no pueden hacer un renice a un valor menor al del shell con el que ellos
corren.
Como root podra poner:
renice -10 -u rpc (aumentara en 10 la prioridad de todos los procesos bajo el usuario rpc)
renice +5 -u rpcuser (disminuira en 5 la prioridad de todos los procesos bajo el usuario rpcuser)
renice -5 -p 1846 (aumentara la prioridad del proceso 1846 en 5)
22

Tarea: Como un usuario no privilegiado (curso por ejemplo) cambiar la prioridad de su propio shell.
COMANDO NOHUP
nohup es un comando que viene de la palabra: No Hangup, es muy til para cuando pretendemos ejecutar
un comando que no se cuelgue en caso de que salgamos del shell.
En efecto, al ejecutar un comando con & este seguir escribiendo al terminal en que estamos, en caso de
salir por cualquier concepto (cerrando la ventana, cayndose la conexin, etc), este comando que se est
ejecutando, eventualmente, ser eliminado por el kernel.
El comando nohup nos permite que los procesos ignoren las seales KILL y TERM. De esta forma evitamos
que sean matados cuando salgamos del sistema y puedan seguir procesndose.
El comando nohup permite, adems, que toda la informacin de salida en vez de ir a la salida estndar
(monitor) lo que har ser guardar toda la salida en el archivo nohup.out para que la podamos analizar
posteriormente. Un ejemplo del comportamiento de este comando:

[cpcrcz@cpcrcz
[1]

nohup ping 102.16S.Q.1 t

18958

[eperez@eperez -]$ nohup: appending output to 'nohup.out 1

Vemos como nos devuelve al shell (por el &) pero no sale ninguna informacin del comando ping pues abajo nos
da un mensaje: agregando la salida a nohup.out
Se mantendra ejecutando el ping en el proceso 18958 an cuando salgamos del sistema, y si hacemos un
tail -f nohup.out
Podremos ir viendo la salida de ping an cuando regresemos en unas horas.

Un proceso ejecutado con nohup acaba cuando l decida que es tiempo (por ejemplo si usamos wget para bajar
un sitio lo podemos dejar con nohup y al, da siguiente, verificar que todo est bien) o si es un proceso que
no acaba (el ping por ejemplo), podemos matarlo mediante kill.

Tarea: El comando: watch free -m


nos permite ejecutar cada 3 segundos el comando free -m, de forma tal que podemos ir viendo cmo se comporta
la memoria.
Ejecutar este comando desde nohup.

23

Otras herramientas de monitoreo


Otra utilera muy usada en Linux es el vmstat
vmstat permite realizar un monitoreo de la actividad completa del sistema, que va desde chequeos de
procesos, memoria RAM, SWAP, accesos a disco y cpu. Lo que nos puede dar, de forma tabulada, una idea
general de cmo se comporta el sistema en un determinado momento.

El vmstat tiene varios switches para ejecutarse, sin embargo basmonos en esta recomendacin para
ejecutarlo, si desean conocer ms sobre otros switches, podemos hacerlo viendo la pgina de manual (man
vmstat)

El comando que usaremos ser:


vmstat -S m 5

Lo que indicar que realice un chequeo del sistema cada 5 segundos y que muestre los valores en megabyted
(de lo contrario lo mostrar en kb)

Para los usuarios que tengan rhel3, la forma antigua de ejecutar el vmstat era:
vmstat -m 5
En cualquiera de las dos variantes, la informacin mostrada es prcticamente la misma.

Veamos ahora qu significado tiene cada columna; este es un ejemplo que slo muestra la primera lnea:
[root@eperez ~]# vmstat -S m 5
procs ------------------ memory -------------- swap --------io ------ system ------ cpu ---r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 113 23 199 0 0 87 24
1060 503 11 1 85 3

Ante todo hay que sealar que la primera lnea de datos que se muestra en el vmstat indica un promedio desde
que el sistema fue encendido; es decir, los valores actuales, los valores que indican claramente cmo se
comporta el sistema en ESTOS momentos, salen a partir de la segunda lnea de informacin.

En este caso estamos mostrando solamente la primera lnea, es decir, los valores promediados desde que la
mquina arranc.

procs:
se divide en dos parmetros:

r: runneable processes, o procesos que estn corriendo o esperando ser procesados.

Normalmente el valor de r debe ser igual o menor a la cantidad de procesadores que tengamos. En
mi caso es 1 y, por lo tanto, para mi uniprocesador est bien. No debe tomarse como un valor

24

exactsimo, es decir, en mi caso hasta 2 o 5 en ciertos momentos estara bien. Lo que no estara
bien es un valor constantemente en 4 o en 5.

b: bloqued, procesos bloqueados, normalmente son procesos que estn esperando por e/s, es

decir disco. No es natural tener procesos en b, para servidores MUY altamente usados, es natural
tener algunos procesos en b, pero no es normal que el b sea mayor que r. Como siempre, no es una
receta a seguir, solamente indico que si b se mantiene constantemente con muchos procesos, esto
es signo de que algo anda mal, o lento, en el disco y debemos tomar acciones pertinentes.
memory:
se divide en 4 parmetros:

swpd: indica la cantidad de memoria que est swapeada. Normalmente el sistema Linux usa la
swap; por ello no es signo de alarma que la memoria tenga partes swapeadas, pero s lo sera si la
swap comienza a incrementarse en cada chequeo a lo largo del tiempo o que la swap
constantemente est variando (unas veces crece, otras decrece) pues es indicador de que se est
recayendo constantemente en ella y esto afecta el funcionamiento del sistema.

free: Es la memoria no usada por el sistema.

buff: Es la memoria destinada a almacenar buffers

cache: Es la memoria destinada a cachear accesos a disco y pginas de procesos en general, es til
para mejorar el funcionamiento del sistema.

La memoria libre realmente se puede considerar la suma de free+buff+cache, pues el sistema puede disponer
fcilmente de buff y cach para sus datos no descartables.
La memoria free es normalmente bastante baja, ya que el sistema siempre trata de usar el resto de la
memoria libre para cachear.
Si la memoria cache es pequea, debemos considerar que estamos con un sistema recin arrancado, o el
sistema se est quedando sin memoria (es decir, no puede cachear mucho porque casi toda la ram la
est dedicando a datos no descartables).

swap:
Lo podemos dividir en:

si: cantidad de mb que estamos swapeando hacia disco

so: cantidad de mb que estamos trayendo desde la swap.

En todo caso no es normal que el sistema est constantemente si/so, a veces puede ocurrir y es natural, lo que
no es normal es que el sistema est todo el tiempo mostrando datos de swap. Este valor debe estar
mayormente en 0 con algunos pequeos picos de acceso.

io
Lo podemos dividir en:
25

bi: bytes in, medido en mb que entran a los discos. En sistemas de mensajera, el bi siempre es

un poco alto pues normalmente hay datos entrando en el disco.

bo: bytes out, medido en mb que salen de los discos. En sistemas de mensajera, pero ms

visible en sistemas de web, este valor de bo es bastante alto ya que constantemente se estn
leyendo datos del disco.
Estos valores, sobre todo bo, pueden ser un buen indicador de que el sistema necesita incrementar la cach.
Pero no es nada malo, pues el disco est para eso: para ser accedido. Ahora, hay que saber determinar
cuando un disco no es lo suficientemente rpido para almacenar o mostrar toda esa cantidad de
informacin.

Estos valores son muy variables; en un sistema de mensajera bo normalmente tiene picos y es cuando las
mquinas de los clientes hacen pop para recoger los mensajes.
system
Se divide en 2 columnas:

in: nmero de interrupciones por segundo

cs: nmero de cambios de contexto.

Estos dos valores no los vamos a analizar pues no aportan datos interesantes.
cpu
Se divide en 4 columnas, las cuales son porcentajes de:

us: tiempo dedicado por el procesador ejecutando cdigo que no es del kernel (tiempo dedicado

al usuario)

sy: tiempo del sistema (ejecutando cdigo del kernel)

id: tiempo en que el procesador no est haciendo nada (idle)

wa: tiempo esperando por e/s (disco, waiting)

El ms interesante realmente es el wa: Si el tiempo esperando por el procesador supera el 30 debemos


tomar esto como una alarma ya que el sistema est perdiendo mucho tiempo esperando por los discos y
debemos mejorar nuestro sistema de I/O. Si supera CONSTANTEMENTE los 50 ese sistema TIENE que
ser optimizado o cambiado el sistema de I/O por algo mejor.
Comando lsof
Algunas veces nos encontramos con que un binario no puede ser sobrescrito o que una particin no puede
ser desmontada porque alguien los est accediendo, quin est accediendo a esa particin o archivo? El
comando Isof, nos podr ayudar a contestar esta pregunta.
lsof significa listing of (listado de):

26

El comando lsof es sumamente poderoso; en esta seccin slo daremos ciertos elementos, pero en
realidad es muy grande y poderoso. Para analizar ms el comportamiento de lsof por favor referirse a la
pgina manual (man lsof) o referirse a la Internet.

lsof es una herramienta muy til en todas las circunstancias, ya sea para chequeos diarios del sistema como para
auditoras de seguridad.

Veamos algunos ejemplos de lsof:


lsof
este comando me mostrar nicamente todos los archivos abiertos, conexiones de red (sockets) abiertos
as como pipes y todo elemento que use Linux para comunicarse. Es una cantidad de informacin muy
grande.

lsof 'which httpd'


nos dir todos los procesos que estn ejecutando el binario del httpd (which lo que hace es decirnos el
camino exacto de httpd).
Otra variante de lo anterior: lsof /usr/sbin/httpd
lsof /etc/passwd
Me indicar quin est accediendo a /etc/passwd lsof /dev/hda3
Dir qu procesos estn accediendo a la particin /dev/hda3
lsof -t /usr/sbin/sendmail
nos indicar solamente los nmeros de proceso que estn accediendo al binario de sendmail.
lsof -c bash
nos indicar qu archivos estn abiertos por procesos que comiencen con "bash" lsof +p 4025

indicar qu archivos estn siendo accesados por el proceso 4025. lsof -i :80
indicar qu procesos estn accediendo al puerto 80 de nuestra red. 4.4

4.4 Sistema de arranque y parada


4.4.1 Conceptos previos
Servicios:
Los servicios de Linux son demonios o servidores que ejecutan determinadas tareas, ms adelante
estudiaremos en detalle una gran cantidad de estos servicios, y cada uno de estos demonios o servidores
activan o abren puertos hacia la Internet. Personalmente veo los puertos como ventanas abiertas hacia la
Internet, y por supuesto no es lo mismo controlar una casa que tenga abiertas 50 60 ventanas a controlar

27

los accesos de intrusos en una casa con 5 ventanas; al menos el intruso tiene ms posibilidades de ser
capturado.

Los servicios son programas hechos por seres humanos, pueden contener y, de hecho, contienen errores.
En clases siguientes trataremos algunas formas que usa redhat para controlar accesos no autorizados
adems de otras formas para prevenir accesos a travs de fallas. A pesar de esto, no hay nada mejor que
tener la certeza total de que no entre un atacante por un servicio con falla y la mejor forma de que alguien
no entre a travs de un servicio es... Exacto!: Apagar el servicio. Al apagarlo ya no nos preocupar tanto si
el servicio tiene fallas o no, sencillamente no est corriendo y por lo tanto no podr ser explotado.

4.3.2

Niveles de ejecucin

Antes de comenzar a configurar los servicios (apagarlos y encenderlos) debemos entender qu son los
niveles de ejecucin de Linux.
Un nivel es un estado o un modo, que es definido por los servicios listados en /etc/rc.d/rcX.d, donde X es el
nmero del nivel.
En RedHat los siguientes niveles (runlevels):

0 - Halt

1 - Mono Usuario sin red

2 - no usado actualmente

3 - Multiusuario con red (full multiuser)

4 - no usado actualmente

5 - Multiusuario con red y ambiente X

6 - Reboot

Si al comenzar la mquina, vemos una pantalla de login en modo texto (negra con letras blancas) entonces
casi seguramente estamos trabajando en el runlevel 3.

El nico runlevel que tiene ambiente grfico por defecto (login grfico) es el runlevel 5, los dems
sencillamente se ocupan de no cargar el ambiente grfico y de manejar los servicios que le hemos indicado.

El runlevel por defecto puede ser cambiado modificando el archivo /etc/inittab, que contiene una lnea casi al
inicio que dice algo as:
id:5:initdefault:
Esto lo que significa (en mi caso) que el nivel de arranque por defecto de mi sistema es el 5. Si deseramos
que nuestro sistema arrancase en el runlevel 3, entonces sencillamente cambiaramos el 3 por el 5. Este

28

cambio no har efecto de forma inmediata, /etc/inittab es lo que ejecuta el proceso init al arrancar el
sistema, por lo tanto hasta que no reiniciemos la mquina no veramos el cambio.
Si deseramos cambiar inmediatamente de nivel, podramos usar el comando telinit seguido del nivel al que
queremos llegar telinit 3
Tanto para ejecutar telinit como para cambiar /etc/inittab se debe estar como el usuario root. telinit no
cambia el archivo /etc/inittab, sino que sencillamente cambia el runlevel que actualmente ejecutamos sin
afectar para nada el arranque previsto para el sistema en posteriores momentos. Es decir, si reiniciramos
el sistema, este arrancara en el runlevel previsto en /etc/inittab independientemente de que hayamos
ejecutado telinit o no.
Nosotros tambin usamos el comando init que realiza la misma funcin del telinit: init 3

Xinetd
El xinetd es un demonio de demonios, es un sper demonio que reemplaza al antiguo inetd.
El demonio xinetd nos ayuda a preservar recursos del sistema adems que provee sistemas de control de
acceso e histricos para los demonios que ejecuta.
El xinetd puede ser usado para conceder acceso a un host o grupos de hosts a ciertos servicios o
demonios. Adems de que no mantiene los demonios levantados todo el tiempo sino que solamente los
activa cuando son requeridos en el puerto indicado. De esta forma se ahorra memoria y cpu al no tener
constantemente un demonio esperando que le soliciten.
Claro, el xinetd tambin tiene un defecto, si lo usramos en un servidor muy ocupado, el manejar por
ejemplo el pop3 como un servicio de xinetd hace que las conexiones de pop sean muy lentas, ya que la
filosofa del xinetd es slo subir los servicios cuando se les demanda. Por ello, si tenemos que manejar la
carga para digamos 600 o 1000 usuarios (o ms) el xinetd tendra que levantar cada cierto periodo de
tiempo unos 600 o 1000 servicios de pop3 para atender los usuarios. Y levantarlos significa, tcnicamente,
leerlos del disco y ejecutarlos, por lo que hace un poco lento el proceso.
Tambin el xinetd tiene una ventaja y es que puede limitar la tasa de accesos hacia un determinado
servicio.
El archivo de configuracin del xinetd es /etc/xinetd.conf pero sugiero no tocarlo pues son configuraciones
por defecto del xinetd que funcionan bien. La parte interesante del xinetd est en /etc/xinetd.d
Para habilitar o deshabilitar cualquier servicio, debemos verificar que este exista dentro de /etc/xinetd.d. Una
vez verificado, podemos editar el servicio en cuestin. Cada uno de los archivos que describen el
comportamiento de los servicios tiene una lnea que dice:
disable = yes
Lo que significa que el servicio est deshabilitado. Si quisiramos habilitarlo sencillamente pondramos
disable = no.
Tambin se pueden editar los servicios del xinetd usando ntsysv o chkconfig como veremos ms adelante.
Una vez hayamos cambiado los valores de disable (o cualquier otro valor en un servicio) estos no se activan
o desactivan automticamente sino que hay que esperar hasta la prxima vez que reiniciemos el sistema o
hasta que reiniciemos el super demonio xinetd
29

Un ejemplo de un archivo de configuracin de un servicio: [root@eperez ~]# cat /etc/xinetd.d/rsync


#

default: off

description: The rsync server is a good addition to an ftp server, as it # allows crc checksumming etc.

service rsync {
disable = yes socket_type = stream wait = no user = root
server = /usr/bin/rsync server_args = --daemon
Este es un servicio llamado rsync, permite sincronizar datos entre servidores, por defecto est deshabilitado
(disable=yes) y el servicio que corre es /usr/bin/rsync con un parmetro adicional (--daemon)

Descripcin y localizacin de recursos


Veamos un poco ms la organizacin de los servicios dentro de /etc:
Existen dos directorios fundamentales para el manejo de servicios:

/etc/init.d: Es el directorio donde se almacenan en s los scripts que manejan la actividad de los

servicios. En las versiones de RedHat (CentOS) esto es un enlace directo al directorio real que est
localizado en /etc/rc.d/init.d

/etc/rc.d: Es el directorio que contiene al menos los 7 niveles de ejecucin en forma de

directorios. Dentro de cada uno de estos niveles de ejecucin estn descritos los procesos que se
activarn dentro de cada nivel. Son sencillamente accesos directos a /etc/init.d
En /etc/rc.d/rc3.d, por ejemplo, tendremos una serie de enlaces directos hacia el directorio /etc/init.d que
indicarn si este enlace (servicio) se ejecutar al arrancar el sistema (si comienza con una S) o al apagarse
el sistema (si comienza con una K) y un nmero que indicar el orden de arranque y parada (S10 va
primero que S80 por ejemplo) posteriormente un texto que nos dice a qu script especficamente apunta.
Por ejemplo:
Me indica todos los servicios que arrancarn al arrancar el nivel 3 o que pararn al parar el nivel 3.
En el caso de iptables (S08iptables), arrancar (S) despus que el servicio kudzu (S08 es mayor que S05,
kudzu por lo tanto arranca primero).

Una forma de evitar que un script arranque (o pare) puede ser cambiando el acceso directo del nivel que
deseo; por ejemplo podra mv /etc/rc.d/rc3.d/S44acpid /etc/rc.d/rc3.d/K44acpid y as evitara que el servicio
acpid arrancara automticamente con el nivel 3.

Estos archivos anteriormente listados, no son ms que apuntadores a /etc/init.d Dentro de /etc/init.d
podemos ver una serie de archivos que no son ms que los scripts que contienen la informacin sobre inicio
y parada de los diferentes servicios o demonios. En cada mquina, estos pueden variar, en dependencia de
lo que hayamos decidido instalar en ella, en mi caso tengo estos servicios:

30

Posteriormente haremos una breve descripcin de los servicios ms interesantes de Linux. De momento
veamos una descripcin interna de un script:

Si vemos, por ejemplo, el script del servicio sendmail (/etc/init.d/sendmail) podremos notar que las primeras
lneas, aunque comentadas, nos son de gran utilidad para determinar en qu consiste este servicio:
#!/bin/bash
#
# sendmail This shell script takes care of starting and stopping
# sendmail.
#
# chkconfig: 2345 80 30
# description: Sendmail is a Mail Transport Agent, which is the program \
# that moves mail from one machine to another.
Este es un script normal hecho en bash. Debido a que posteriormente veremos en el curso cmo hacer
algunos scripts en bash, obviemos la primera lnea que es la que indica que correr en un subshell
(/bin/bash)

Inmediatamente despus tenemos una serie de lneas con la descripcin del script, se llama sendmail y es
el script que se encarga de levantar y parar el servicio se sendmail.

Inmediatamente despus vemos una lnea muy interesante que es los valores de arrranque y parada
chkconfig: 2345 80 30
Esto le indicar a las utileras (chkconfig y ntsysv), cules sern los modos de arranque por defecto (2 3 4 y 5)
para manejar el arranque y la parada. Tambin les sealar qu posicin tendr en los enlaces directos
(S80sendmail posiblemente, por el 80) y qu valores tendr al apagarse (K30sendmail posiblemente, por el
30).
Posteriormente a esta lnea, nos dan una breve descripcin para los efectos que querramos de qu labor
realizar el servicio. En este caso nos indicar que el sendmail es un MTA o mail transport agent que es el
programa que se encarga de enviar los mails de una mquina a otra.
Ahora, editar manualmente estos enlaces, con el objetivo de borrar un servicio de la lista de arranque de un
modo, es un poco complicado y podemos caer en errores como el hecho de poner una s en vez de S, o un
nmero mal puesto o poner un servicio delante de otro que requiere para trabajar (por ejemplo, cmo
echar a andar el sendmail si la red todava no anda?).
Por ello, en la siguiente seccin veremos algunas utileras para manejar ms cmodamente estos servicios.

Netsysv, chkconfig y service


Existen varias formas de controlar los servicios del sistema. Mencionamos
31

anteriormente, que podemos arrancarlos o no, si borramos o creamos los enlaces correspondientes en
/etc/rc.d/rcX.d; sin embargo es un poco difcil de manejar servicios por esa va, por lo que nosotros veremos
dos opciones mucho ms cmodas:
ntsysv: Es una herramienta grfica que nos permitir configurar qu servicios queremos arrancar o
apagar en el runlevel que estamos. Es una forma muy fcil de echar a andar o apagar servicios,
sin embargo en mi nuestra consume demasiado recursos al tener que levantar un pequeo
ambiente grfico. Adems slo trabaja para el runlevel actual y editar otros runlevels se hace algo
complicado.

chkconfig: Es una utilera muy simple que, igualmente, nos permitir agregar o quitar servicios del
runlevel en que estamos, pero adems nos permitir
agregar ms servicios a la lista de servicios o eliminarlos de esa lista. Tambin nos permitir un trabajo
un poco ms detallado de diferentes runlevels.
En definitiva, ambas utileras lo que hacen es editar diferentes archivos y enlaces directos que estn disponibles
en /etc/rc.d y /etc/init.d
32

Cmo usamos el chkconfig?

Tenemos varios switches interesantes; en este caso el --list: chkconfig --list


nos permite listar, todos los servicios actualmente instalados en el sistema y por
cada runlevel podemos ver su estado (off/on)
[r
Por ejemplo, el servicio anacron est apagado para los niveles 0, 1 y 6, y est encendido para 2 3 4 y 5.

Si quisiramos ver una lista no tan extendida, sino sencillamente los valores para un slo servicio
podramos hacerlo indicndole el nombre del servicio: [root@eperez ~]# chkconfig --list sendmail sendmail
0:off 1 :off 2:on 3:on 4:on 5:on 6:off

Otro switch interesante es el --add y el --del chkconfig --add


servicio

nos permite configurar un servicio nuevo en todos los niveles declarados en su script de inicio.
chkconfig --del servicio
nos permitir hacer lo mismo pero al revs, eliminar todos los enlaces directos de los directorios /etc/rc.d/rcX.d
para que no levante ni sea matado al terminar el sistema.

Estos dos switches (--add y --del) tpicamente no se utilizan pues, cada paquete que instala un servicio se ocupa
de darle de alta en la lista de niveles.
Ahora el switch ms interesante: --level

--level se usa para cambiar el estado de un servicio en diferentes runlevels a la vez. Se ejecuta as:
chkconfig --level 2345 sendmail on
Esto indicar al servicio sendmail que debe activarse en los niveles 2,3,4 y 5.
Por supuesto podemos usar off para desactivarlo y, tambin, podemos usar cualquier combinacin de
niveles que deseemos, pero lo ms comn es usarlos todos a la vez (2345). Si solo quisiramos trabajar
con 3 y 5, podramos hacerlo con chkconfig --level 35 sendmail on

Ahora, hasta el momento hemos hablado de cmo apagar y levantar servicios pero refirindonos a los
niveles de arranque, es decir, hemos hablado de cmo configurar el sistema para cuando se apague o
encienda.

Tcnicamente en comportamientos normales, Linux slo exige ser reiniciado cuando ocurre una condicin:
Se actualiza el kernel. Es decir, cuando se hace cualquier labor de reconfiguracin del sistema, o cuando se
33

realiza la actualizacin del sistema, no es necesario reiniciar Linux. Todo debe correr de forma casi
inmediata, excepto cuando actualizamos el kernel, ya que ste s exige (de momento) que sea reiniciado el
sistema Linux para que el nuevo kernel comience a trabajar. Esto es un incidente que ocurre una vez cada
algunos meses; unas veces con antelacin, otras veces con atraso, pero no es un incidente frecuente como
sucede en Windows.

Entonces: cmo podemos hacer para apagar un demonio o levantarlo, de forma inmediata? Bueno,
tenemos dos formas, la primera es ejecutar directamente el script que est en /etc/init.d:
/etc/init.d/sendmail stop
Por ejemplo, este comando parara sendmail; lo apagara, nadie podra ser capaz de enviar mails a travs del
servidor.

La otra variante es usar el comando service: service network restart

Reiniciara la red (sin tener que reiniciar el sistema!), es decir, tcnicamente podra hacer cambios en la
configuracin de IP de mi red y, al emitir este comando, ya todo trabajara.

Ahora: qu es eso de restart, stop, etc? Son las acciones; es cmo podemos llamar un script e indicarle qu
debe realizar.

start: Arranca el servicio

stop: Apaga el servicio

restart: Reinicia el servicio (stop+start)

condrestart: Si el servicio est encendido, lo reinicia.

reload: Recarga el archivo de configuracin del servicio

status: Indica el estado del servicio (Is running, list de PIDs, etc)

Aunque potencialmente pueden existir otras acciones, estas son las bsicas para cada servicio.

Tarea: Probar estas acciones con el comando service para cuantos servicios tenga en /etc/init.d.

Hay que anotar que el comando service (o /etc/init.d/demonio) no apaga ni enciende permanentemente un
demonio: en cuanto el sistema es reiniciado, el sistema obedecer a lo que le hemos indicado con los
comandos chkconfig; es decir, con lo que le tengamos indicado en los directorios /etc/rc.d/rcX.d). El
comando service sirve para apagar o encender inmediatamente un servicio sin esperar a reiniciar el
sistema. Pero no indica que quedar encendido o apagado por siempre, sino que solamente mientras el
sistema est encendido as se quedar el comando.

34

Demonios del sistema


Marcaremos con negrita los demonios que deseamos activos. Los que no estn en negritas, por favor
apagarlos como tarea (chkconfig --level 2345 demonio off; service demonio stop)
Por qu los apagaremos? Muy bsico: muchos servicios tienen una inmensa utilidad, pero no todos los
servicios tienen que estar corriendo todo el tiempo en el sistema, primero porque consumen recursos (cpu,
memoria) y ms importante, porque pueden ser la puerta de entrada para que los atacantes logren ganar
accesos a nuestro sistema.
Siempre hay que pensar: Qu servicios usaremos realmente? Debemos apagar los que no vayamos a
para evitar lo anteriormente expuesto. De cualquier modo, si posteriormente lo requerimos, podemos
volverlos a activar.

acpid - Escucha y despacha eventos ACPI al kernel, para ms informacin sobre el acpi, ver aqu

anacron - Ejecuta trabajos del cron que no han sido ejecutados por estar apagado el server.

apmd - Se usa para monitorear el uso de la batera y guardarlo en los logs. Para configurarlo se
puede hacer en /etc/sysconfig/apmd

atd - Ejecutar comandos que han sido programados usando el comando at

autofs - Monta filesystems en demanda (posiblemente cdrom, floppy, Personalmente no es de mi


total agrado: prefiero montar manualmente los filesystems)

Bluetooth - Servicios Bluetooth (bsqueda, descubrimiento, autenticacin); Bluetooth es una


tecnologa bastante nueva que permite la comunicacin entre equipos de forma inalmbrica.
Bluetooth para Linux funciona bastante bien, pero es un poco inseguro, adems en el curso no
veremos este tipo de comunicacin.

cpuspeed - Es un demonio que se encarga de reducir los ciclos del procesador en caso de que el
sistema est con baja carga, de esta forma ahorra corriente. Solamente es efectivo para
procesadores que lo soporten (por ejemplo mi amd sempron no lo soporta). En todo caso es un
demonio que corre slo y no es necesario tocarlo. Si notamos que el sistema se cuelga en
momentos de inactividad (por las noches), sugiero, primero que todo, apagar el cpuspeed a ver si
esto ayuda a salir de los problemas.

crond - Ejecuta tareas programadas mediante el sistema cron (en la siguiente clase hablaremos

de l).

cups - Encargado de encender o apagar el Common Unix Printing System.

cups-config-daemon - Configura el demonio de impresin

dc_client, dc_server - Sistema de distribucin de carga de sesiones

diskdump - Guarda la informacin de un crash del sistema

dund - Bluetooth dialup networking.

functions - Funciones para ser usadas por la mayora de los scripts de /etc/init.d

35

gpm - Soporte del mouse para el ambiente texto. Si pone el mouse en el modo texto, podrn ver

que hay un cuadrito que se mueve, es el puntero del mouse. Con esta utilera podemos copiar/pegar
texto entre consolas. Si estamos en un servidor remoto, sin conexin permanente al teclado/mouse,
sugiero deshabilitarlo.

haldaemon - Apagar

halt - Si se manda a ejecutar en un runlevel, proceder a apagar el sistema.

hidd - Human interface devices (prove, via Bluetooth, acceso al teclado, mouse, etc)

httpd - Servidor web, apache.

iptables - sistema de firewall de redhat, hecho en iptables. Usaremos un sistema propio y no el

de redhat porque es muy complicado. Apagarlo.

irda - Demonio para el manejo de conexiones infrarrojas. Si no tenemos una laptop o conexin

IR, apagar. Sugiero apagarlo en servidores.

irqbalance - Es un demonio que se encarga de distribuir las llamadas a interrupciones del

sistema entre los diferentes procesadores. Si nuestro sistema es un uniprocesador, este demonio no
tiene mucho sentido.

isdn - Manejo de ISDN, no se usa en el pas. Sugiero apagarlo.

killall - Este script se encarga de matar todos los procesos en un runlevel, debe ser ejecutado

solamente en 0 y en 6, de lo contrario si lo activamos en otro runlevel, al llegar a este runlevel


matar todos los procesos.

kudzu - Es un demonio que se ejecuta al arrancar el sistema y detecta cualquier hardware nuevo

instalado, y nos pide que tomemos alguna accin respecto al hardware nuevo detectado (o al
hardware eliminado). Si nuestro servidor no vara en su hardware, mejor es deshabilitarlo y slo
ejecutarlo manualmente (kudzu) cuando hayamos puesto algn hardware. El kudzu no afecta el
funcionamiento del sistema, sin embargo, demora un poco ms el arranque pues en cada arranque
se molestar en verificar durante unos segundos (menos de 5) qu hay de nuevo.

mdmpd mdmonitor - Herramienta de monitoreo de raids de software. En posteriores cursos

hablaremos cmo crear un raid por software.

messagebus - Demonio que maneja mensajes sobre eventos del sistema.

microcode_ctl - Es un demonio que se ocupa de actualizar el procesador Intel con parches

liberados por Intel. Intel nunca indica qu correccin va en cada parche, pero los parches ayudan a
mejorar el funcionamiento del procesador por lo que es bueno tenerlo activado. El demonio se
actualiza a travs del sistema de actualizaciones por lo que es transparente cualquier nueva
actualizacin. Este demonio slo se ejecuta al arrancar el sistema y no consume muchos recursos.
No soporta otros procesadores que no sean Intel, puede ir apagado en amd.

named - Demonio que tiene la funcin de actuar como servidor de DNS, en cursos posteriores

haremos mucho nfasis en el trabajo con dns. Este demonio, por s slo, hace que nuestra mquina
acte como dns de cach, lo que permitir que ella misma resuelva nombres sin tener que acudir a
los dns del proveedor.

netdump
36

netfs - Es el sistema ocupado de montar y desmontar otros tipos de FS (de red) como el NFS,

samba, NCP (netware), etc. Como usaremos samba y nfs, sugiero dejarlo activado.

netplugd - Demonio que se encarga de supervisar y apagar (o encender) interfaces, no

conexiones de red, no estticas. De momento no activar. Es para poder manejar cadas o


desconexiones de interfaces temporales como ppp (modem, dialup), etc.

network - Es el demonio que se encarga de apagar/encender las interfaces de red del sistema.

NetworkManager - Demonio que se ocupa de monitorear diversas conexiones de red e

informarle al sistema sobre la ms adecuada para su uso. Es algo para m experimental y debe ser
apagado.

portmap, nfslock, nfs - Demonios que permiten compartir directorios, partes del disco, entre

sistemas unix. Lo veremos ms adelante, por favor dejar activado.

nscd - Name Switch Cache Daemon se ocupa de cachear respuestas a peticiones sobre

usuarios y grupos para sistemas de autentificacin como ldap, nis, hesiod. Apagar de momento.

ntpd - Demonio que permite a nuestro servidor actuar como un servidor para sincronizar la hora.

Apagumoslo: no trabajaremos Linux como un servidor de tiempo; sin embargo, ms adelante s


veremos cmo sincronizar la hora de nuestro Linux contra servidores de tiempo en Internet.

pand - Demonio de BT para la red personal. Apagumoslo.

pcmcia - Es un demonio que permite instalar dispositivos pcmcia en nuestras mquinas. Por

defecto viene apagado, como nuestros servidores no tienen dispositivos pcmcia, es bueno
asegurarse de que est apagado

psacct - Demonio para llevar la contabilidad de los procesos, las estadsticas y dems. Este

proceso consume muchos recursos por lo que debe mantenerse apagado.

rawdevices - Permite a ciertas aplicaciones (a Oracle, en particular) acceder a dispositivos en

crudo (raw, no formateados); sin embargo, ya se considera depreciado pues las aplicaciones no
deben hacer peticiones a travs del rawdevice sino haciendo llamadas directas al sistema. De
momento mantener encendido.

readahead, readahead_early - Permite predecir y cargar en la memoria programas que van a

ser usados. Es particularmente bueno para el ambiente grfico. Verificar que slo se ejecuta en el
ambiente grfico, no es un demonio sino que se ejecuta al comenzar el sistema. Mantener activo en
el modo 5

rhnsd - Se ocupa de conectarse a la red de actualizaciones de centros (funciona para redhat

tambin) y verificar si existen actualizaciones. En los sistemas redhat es importante dejarlo activo
para que verifique constantemente la licencia contra los servidores de redhat. Para centros podemos
apagarlo ya que usaremos yum.

rpcgssd, rpcidmapd, rpcsvcgssd - Permiten el trabajo con NFS versin 4. Dejarlo activado de

momento.

37

saslauthd - Permite manejar las autenticaciones de usuarios (en texto claro). Dejarlo activo de

momento, puede sernos til en sendmail.

sendmail - MTA que estudiaremos; se ocupa de recibir y enviar mensajes desde y hacia

nuestros clientes y nuestros dominios. Lo usaremos mucho durante en el curso.

single - Al ejecutarse, lleva al sistema al modo 1 (single, monousuario)

smartd - Demonio que permite obtener datos del sistema S.M.A.R.T, un sistema de monitoreo

presente en discos tipo IDE. No afecta al funcionamiento pero no lo veremos, as que podemos
desactivarlo

smb - Demonio que se ocupa del manejo de conexiones de mquinas Windows hacia nuestro

servidor. Es comnmente conocido como samba y permite hacer actuar nuestro servidor Linux como
un servidor de archivos de Windows. Dejmoslo activado, pues lo usaremos posteriormente en el
curso.

spamassassin - Permite cargar el demonio del spamd, para realizar chequeos antispam de los

mails que llegan a nuestro sistema. No lo usaremos de esta forma (demonio) sino que,
posteriormente en el curso, aprenderemos a llamarlo cada vez que necesitemos analizar un lote de
mensajes. Desactivar.

squid - Servidor muy popular en Internet, bastante fcil de configurar que permite cachear

peticiones que hacen las mquinas de nuestra red interna hacia la Internet, ahorrando, de esta
forma, ancho de banda. El squid tambin permite balancear carga entre servidores web. Activarlo,
pues lo veremos en el curso.

sshd - Demonio que se encarga de las conexiones seguras hacia nuestro servidor. Es uno de

los sistemas base ms utilizados para acceder remotamente a nuestros servidores. Dejarlo activado,
ya que, en las siguientes semanas, veremos cmo conectarnos por ssh.

syslog - Demonio que se ocupa de recibir las solicitudes de parte de todos los procesos del

sistema para que almacenen en los histricos. Es un demonio muy usado; siempre detrs,
trabajando, guardando los logs. Dejmoslo activado pues es bsico para el funcionamiento de los
histricos del sistema.

tux - Es un servidor web que viene insertado (embebido) dentro del kernel; es muy pequeo y

eficiente, pero slo maneja pginas estticas. En la parte de servidores web del curso posiblemente
pondremos enlaces y documentacin sobre el uso del tux. Normalmente debe ir desactivado ya que
es un poco complicado echarlo a andar junto con el apache (httpd); aunque, definitivamente, en
algunas circunstancias es muy til por su eficiencia.

vsftpd - Servidor de ftp. Dejarlo activado pues lo usaremos posteriormente en el curso. Este

servidor de ftp es muy seguro y fcil de configurar y, en la actualidad, es muy popular en el mercado.

winbind - Servicio que nos permite autenticar usuarios en nuestro sistema Linux. Estos usuarios

estn guardados en un dominio de un servidor NT. Esto nos permite consolidar los servidores de
autenticacin, pudiendo tenerlos en un NT. Quin se atrevera?, al menos yo no me atrevera a
confiar la autenticacin a un servidor NT, y como Microsoft constantemente cambia de conceptos, no
lo veremos al momento. Desactivar.

38

xfs - Se ocupa de servir tipos de fuentes (fonts) al ambiente grfico. Dejarlo activado en el modo

5. Si no tuviramos ambiente grfico instalado en nuestro servidor (sera lo recomendable por las
razones de ahorro de recursos y prevencin de ataques) podramos apagarlo completamente.

xinetd - Sperdemonio, demonio de demonios; se ocupar de autenticar algunos pequeos

servicios. Personalmente no veo su utilidad al momento, por lo que prefiero que lo desactivemos.

ypbind - Sistema de autenticacin centralizado para servidores unix. Muy popular en su poca.

LDAP en estos momentos demuestra ser mucho ms eficiente que yp (yellow pages), por lo que no
lo usaremos (al yp). Desactivar.

yum - Sistema de actualizaciones en lnea que, adems, permite instalar nuevo software sin

necesidad de CD. Es decir, toma los paquetes rpm de la red de centros y lo instala en nuestro
sistema. Este demonio nos permitir actualizar automticamente todas las madrugadas nuestro
sistema Linux, sin tener preocuparnos por hacerlo manualmente. Por supuesto, si no hay
actualizaciones, no har nada esa noche.

Arranque y parada de Linux


El inicio del proceso de arranque vara dependiendo de la plataforma de hardware usada. Sin embargo, una
vez que se encuentra el kernel y se carga por el gestor de arranque, el proceso de arranque por defecto es
idntico a travs de todas las arquitecturas. Este captulo se basa principalmente en la arquitectura x86.

La BIOS
Cuando un PC x86 se carga, el procesador busca al final de la memoria del sistema por Basic Input/Output
System o el programa BIOS y lo ejecuta. La BIOS controla, no slo el primer paso del proceso de arranque,
sino que tambin proporciona una interfaz de bajo nivel para dispositivos perifricos. Por este motivo, se
escribe tan slo en modo de lectura, de memoria permanente y est siempre disponible para el uso.

Otras plataformas usan programas diferentes para ejecutar tareas a bajo nivel equivalentes a aquellas de la
BIOS en el sistema x86. Por ejemplo, los ordenadores basados en Itanium usan el Shell Interfaz de
Firmware extendible (Extensible Firmware Interface, EFI).

Una vez cargada, la BIOS chequea los perifricos y localiza un dispositivo con el que arrancar el sistema.
Habitualmente, en primer lugar, comprueba cualquier disquete y unidades de CD-ROM presentes por los
medios de arranque y, a continuacin, si esto falla, echa un vistazo a las unidades del disco duro del
sistema. En la mayora de los casos, el orden de bsqueda de las unidades para arrancar es controlado por
una configuracin de la BIOS y busca por el dispositivo maestro IDE en el bus IDE primario. La BIOS carga
en la memoria cualquier programa que resida en el primer sector de este dispositivo, llamado Registro de
Arranque Principal o Master Boot Record (MBR). La MBR slo tiene 512 bytes de tamao y contiene las
instrucciones de cdigo de mquina para el arranque del equipo (llamado un gestor de arranque) as como,
tambin, la tabla de particiones. Una vez que la BIOS haya encontrado y cargado el gestor de arranque en
memoria, le deja el control del proceso de arranque a ste.

39

El gestor de arranque
Esta seccin revisa los gestores de arranque para la plataforma x86, GRUB.
Un gestor de arranque para la plataforma x86 se divide en al menos dos etapas. La primera es un cdigo
binario de mquina pequea en el MBR. Su nica funcin es la de localizar el gestor de arranque de la
segunda etapa y cargar la primera parte de ste en memoria.
GRUB tiene la ventaja de ser capaz de leer particiones ext2 y ext3 y cargar su archivo de configuracin
/boot/grub/grub.conf al momento de arranque.

Una vez que la segunda etapa del gestor de arranque est en la memoria, presenta al usuario con una
pantalla grfica mostrando los diferentes sistemas operativos o kernels para los que ha sido configurado
para arrancar. En esta pantalla el usuario puede usar las flechas direccionales para escoger el sistema
operativo o kernel con el que desea arrancar y presionar la tecla [Intro]. Si no se presiona ninguna tecla,
luego de un perodo de tiempo de espera (tambin configurable), el gestor de arranque carga la seleccin
predeterminada
Una vez que el gestor de arranque de la segunda etapa haya determinado qu kernel arrancar, localizar el
binario del kernel correspondiente en el directorio /boot/. El kernel binario es llamado usando el siguiente
formato /boot/vmlinuz-<kerne/-version> (donde <kerne/-version> corresponde a la versin del kernel
especificada en las configuraciones del gestor de arranque).
Despus, el gestor de arranque coloca una o ms de las imgenes apropiadas de initramfs en la memoria.
Seguidamente, el kernel descomprime estas imgenes desde la memoria a /boot/, un sistema de archivos
virtual basado en RAM, a travs de cpio. El initrd es usado por el kernel para cargar controladores y
mdulos necesarios para arrancar el sistema. Esto es muy importante si posee unidades de disco duro
SCSI o si el sistema utiliza el sistema de archivos ext3.
Una vez que el kernel y la imagen initramfs se cargan en la memoria, el gestor de arranque pasa el control
del proceso de arranque al kernel.

Otros gestores de arranque


Una vez que se carga el kernel y pasa el proceso de arranque al comando init, los mismos acontecimientos
suceden en cada arquitectura. La nica diferencia entre el proceso de arranque de cada arquitectura est
en la aplicacin que se usa para encontrar y cargar el kernel. Por ejemplo, la arquitectura Itanium utiliza el
gestor de arranque ELILO; las arquitecturas eServer pSeries de IBM utilizan YABOOT; y los sistemas IBM
eServer zSeries e IBM S/390 usan el gestor de arranque z/IPL.

Consulte el Manua/ de insta/acin de Red Hat Enterprise Linux especfico para estas plataformas para
obtener informacin sobre la configuracin de sus gestores de arranque.

El kernel
Cuando se carga el kernel, ste inicializa y configura la memoria del ordenador y los diferentes hardwares
conectados al sistema, incluyendo todos los procesadores, subsistemas de entrada/salida y dispositivos de
almacenamiento. A continuacin, busca la imagen comprimida de initramfs en una ubicacin
predeterminada en la memoria, la descomprime directamente a /sysroot/ y carga todos los controladores
necesarios. Seguidamente, inicializa los dispositivos virtuales relacionados con el sistema de ficheros, tal
como LVM o software RAID antes de completar los procesos initramfs y de liberar toda la memoria que la
imagen del disco ocup anteriormente.
40

El kernel luego crea un dispositivo root, monta la particin root como slo lectura y libera cualquier memoria
no utilizada.

Llegados a este punto, el kernel est cargado en la memoria y es operativo. Sin embargo, como no hay
aplicaciones de usuario que permitan la entrada significativa de datos al sistema, no se puede hacer mucho
ms.

Para configurar el entorno de usuario, el kernel inicia el programa /sbin/init.

Programa /sbin/init
El programa /sbin/init (tambin llamado init) coordina el resto del proceso de arranque y configura el
ambiente del usuario.
Cuando el comando init arranca, se vuelve el padre o abuelo de todos los procesos que comienzan
automticamente en el sistema. Primero, ejecuta el script /etc/rc.d/rc.sysinit, que establece la ruta del
entorno, activa el swap, verifica los sistemas de archivos y se encarga de todo lo que el sistema necesita
tener hecho al momento de la inicializacin.
Por ejemplo, la mayora de los sistemas usan un reloj, por lo tanto, el rc.sysinit lee el archivo de
configuracin para iniciar el hardware del reloj. Otro ejemplo es si hay procesos especiales en los puertos
seriales que deben ser inicializados, rc.sysinit ejecutar el archivo /etc/rc.serial.
El comando init luego ejecuta el script /etc/inittab, el cual describe cmo se debera configurar el sistema en
cada nivel de ejecucin SysV init. Los niveles de ejecucin son un estado, o modo, definido por los servicios
listados en el SysV directorio /etc/rc.d/rc<x>.d/, donde <x> es el nmero de nivel de ejecucin. Para ms
informacin sobre los niveles de ejecucin SysV init, consulte la Seccin 1.4.
A continuacin, el comando init configura la biblioteca de funciones fuente, /etc/rc.d/init.d/functions, para el
sistema, que establece el modo en cmo iniciar o matar un programa y cmo determinar el PID del
programa.
El programa init inicia todos los procesos de fondo buscando en el directorio apropiado rc para el nivel de
ejecucin especificado por defecto en /etc/inittab. Los directorios rc estn numerados para corresponder al
nivel de ejecucin que representan. Por ejemplo, /etc/rc.d/rc5.d/ es el directorio para el nivel de ejecucin 5.
Cuando se arranca el nivel de ejecucin 5, el programa init consulta el directorio /etc/rc.d/rc5.d/ para
determinar qu procesos iniciar o parar.
A continuacin un ejemplo de listado del directorio /etc/rc.d/rc5.d/:
41

K05innd -> ../init.d/innd


K05saslauthd -> ../init.d/saslauthd
K10dc_server K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54dovecot -> ../init.d/dovecot
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K70aep1000 -> ../init.d/aep1000
K70bcm5820 -> ../init.d/bcm5820
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K85mdmpd -> ../init.d/mdmpd
K89netplugd -> ../init.d/netplugd
K99microcode_ctl -> ../init.d/microcode_ctl
S04readahead_early -> ../init.d/readahead_early
S05kudzu -> ../init.d/kudzu
S06cpuspeed -> ../init.d/cpuspeed
S08ip6tables -> ../init.d/ip6tables
S08iptables -> ../init.d/iptables
S09isdn -> ../init.d/isdn
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13irqbalance -> ../init.d/irqbalance
S13portmap -> ../init.d/portmap
S15mdmonitor -> ../init.d/mdmonitor
S15zebra -> ../init.d/zebra
S16bgpd -> ../init.d/bgpd
S16ospf6d -> ../init.d/ospf6d
S16ospfd -> ../init.d/ospfd
S16ripd -> ../init.d/ripd
42

Como puede ver, ninguno de los scripts que inician y cierran los servicios estn localizados en el directorio
/etc/rc.d/rc5.d/. Casi todos los ficheros en /etc/rc.d/rc5.d/ son enlaces simblicos apuntando a los scripts
localizados en el directorio /etc/rc.d/init.d/. Los enlaces simblicos se usan en cada uno de los directorios rc
de manera que los niveles de ejecucin puedan ser reconfigurados al crear, modificar y eliminar los enlaces
simblicos sin que afecten a los scripts actuales a los que se refiere.
El nombre de cada enlace simblico comienza con K o S. Los enlaces K son procesos eliminados en ese
nivel de ejecucin, mientras que aquellos que inician por S son procesos a iniciar.

El comando init, en primer lugar, detiene todos los enlaces simblicos de K en el directorio mediante la
ejecucin del comando /etc/rc.d/init.d/<command> stop, en el que <command> es el proceso a matar. A
continuacin inicia todos los enlaces simblicos S al ejecutar /etc/rc.d/init.d/<command>. start.

Cada uno de los enlaces simblicos se numera para dictaminar el orden de inicio. Usted puede variar el
orden en el que los servicios inician o paran al cambiar este nmero. Mientras ms bajo es el nmero, ms
rpido se arrancar. Los enlaces simblicos con el mismo nmero se inician de modo alfabtico.

Despus que el comando init ha progresado a travs del directorio adecuado rc para el nivel de ejecucin, el
script /etc/inittab bifurca un proceso /sbin/mingetty para cada consola virtual (prompt de inicio de sesin) del
nivel de ejecucin. Los niveles de ejecucin del 2 al 5 tienen seis consolas virtuales; mientras que el nivel de
ejecucin 1 (modo usuario nico) tiene tan slo uno, y lo niveles de ejecucin del 0 al 6 no tienen ninguno.
El proceso /sbin/mingetty abre las rutas de la comunicacin para los dispositivos tty, establece sus modos,
imprime el indicador de inicio de sesin, toma el nombre y contrasea del usuario, e inicia el proceso de
inicio de sesin. En el nivel de ejecucin 5, /etc/inittab ejecuta un script llamado /etc/X11/prefdm. El script
prefdm ejecuta su gestor de pantalla de X preferido gdm, kdm, o xdm, dependiendo de los contenidos del
archivo /etc/sysconfig/desktop. Una vez que haya terminado, el sistema operar en el nivel de ejecucin 5 y
mostrar la pantalla de inicio de sesin.

Fin del captulo.

43