tema 4 gestion procesos y sistema arranque

7/21/2019 Tema 4 Gestion Procesos y Sistema Arranque

http://slidepdf.com/reader/full/tema-4-gestion-procesos-y-sistema-arranque 1/43

4

Adminis tración Linux I - Modalidad Virtual

Tema 4

Gestión de procesos y arranque

C e n t

r o d e

E d u c

a c i ó n

C o n t i n u

a

Edificio “Aulas y relación con el medio externo”

Toledo y Lerida, Planta baja

PBX: 25-25-766

[email protected]



Capacitación en Modalidad Virtual

Administración Linux I, Gestión de Procesos y ArranqueRicardo Ortega

Levantamiento de texto 2008: Ernesto Pérez

Redacción de textos 2010: Ricardo Ortega

Registro de derecho autoral: en trámiteISBN de este volumen: en trámiteDepósito Legal: en trámite

Publicado en http://cursos.cec-epn.edu.ec/aulavirtual/ desde Abril 2008

CENTRO DE EDUCACIÓN CONTINUAESCUELA POLITÉCNICA NACIONALUNIDAD DE EDUCACIÓN VIRTUALQuito –Ecuador



1

ADMINISTRACIÓN DE LINUX I

Gestión de Procesos y Arranque

Material para la modalidad virtual

Master Ricardo B. Ortega O.

www.ricardoortega.com

Objetivos del capítulo 4

Entender qué es un proceso en Linux. Conocer los conceptos de gestión 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 cómo y para qué funcionan los demonios del sistema.

Prerrequisitos para el capítulo 4

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

Recursos necesarios para el capítulo 4

Un computador con Linux CENTOS instalado y funcionando.

La administración de procesos y gestión de arranque se debe hacer desde el usuario root.

Recomendaciones para el capítulo 4

LINUX CENTOS Nos limitaremos a explicar el funcionamiento de CENTOS. Las pruebas en otrasdistribuciones quedan a su propia cuenta y riesgo.

MODO TEXTO a menos que se indique otra cosa, todos los comandos se deben escribir desde unasesión de bash desde el usuario root. Si se dice escriba system-config-users se está diciendoprecisamente 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 delsistema, tendrá serias dificultades. Antes de alterar nada, infórmese.

LEA LOS MENSAJES: Observe los mensajes que le aparecen. No pase por alto los mensajes de error.La mayoría de usuarios no lee los mensajes y cuando se le pregunta “qué decía 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 capítulo 4

OBJETIVOS DEL CAPÍTULO 4 ............................................................... ............................................................... ...... 1

PRERREQUISITOS PARA EL CAPÍTULO 4 ............................................................................................................. 1



2

RECURSOS NECESARIOS PARA EL CAPÍTULO 4 ................................................................................................ 1

RECOMENDACIONES PARA EL CAPÍTULO 4 ....................................................................................................... 1

CONTENIDOS DEL CAPÍTULO 4 ............................................................................................................................... 1

4.1 ADMINISTRACIÓN DE PROCESOS ..................................................................................................................... 2

4.1.1 Términos generales .............................................................. ........................................................................ ...... 2

4.1.2 Nice Level o nivel de amabilidad ............................................................................... ........................................ 2

4.1.3 Fork y exec ............................................................ ................................................................. ........................... 3

4.1.4 Formas de usar el exec ....................................................................... ............................................................... 4

4.1.5 Estados de un proceso ....................................................................................................................................... 5

4.1.6 Señales ......................................................... .................................................................. .................................... 5

4.2 CONTROL DE PROCESOS ..................................................................................................................................... 9

4.3 HERRAMIENTAS PARA MONITOREO Y TRABAJO CON PROCESOS ...................................................... 11

Matando procesos: ...................................................... ................................................................... .......................... 18

¿Cómo podemos hacer para matar varios procesos a la vez? ...... ....................................................... .................... 18

Cambios de prioridad a los procesos ................................................. ............................................................... ....... 19

RENICE: ................................................................ ................................................................ ................................... 20

COMANDO NOHUP .............................................................................. ............................................................ ...... 20

Otras herramientas de monitoreo ....................................................................... ...................................................... 21

4.4 SISTEMA DE ARRANQUE Y PARADA ............................................................................................................... 25

Servicios: .................................................................................................................................................................. 25

Xinetd ................................................................ ..................................................................... ................................... 26

Descripción y localización de recursos ......................................................... ........................................................... 27

Netsysv, chkconfig y service .................................................................................... .................................................. 29

Demonios del sistema ....................................................................... ................................................................. ....... 32

Arranque y parada de Linux ....................................................... ............................................................... ............... 37

La BIOS ................................................................................................................... ................................................. 37

El gestor de arranque .................................................................. ............................................................ ................. 37

Otros gestores de arranque .................................................................................... .................................................. 38

El kernel ................................................................ ................................................................. ................................... 38

Programa /sbin/init ..................................................... .................................................................... .......................... 39

4.1 Administración de procesos

4.1.1 Términos generales

Una de las cuestiones más interesantes y útiles en Linux es, definitivamente, el manejo de procesos. Poreso comenzamos con la teoría y elementos previos. Un proceso es un programa que está corriendo en elSistema Operativo y consume recursos de memoria, cpu, dispositivos. Los procesos se caracterizan portener asignada un área de memoria la cual se divide en área de datos y área de código.

Los procesos pueden ser de un mismo programa (por ejemplo, pensemos en dos navegadores Firefoxcorriendo en nuestra máquina; estos serían dos procesos separados).

En Linux tenemos muchas formas para manejar procesos, podemos ejecutarlos, o sencillamente cambiarlesla prioridad; también 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 decirque cada nivel de prioridad, señalado por un número del -20 (más prioridad) al +20 (menos prioridad),mantiene, a su vez, una lista de procesos bajo su control.



3

Los procesos de una cola sólo son ejecutados cuando las colas con más prioridad a su nivel hayanprocesado todas sus listas de prioridad.

También conocidos como nice levels (niveles de amabilidad o gentileza), los procesos pueden serasignados por el usuario que ejecuta un proceso o por el administrador del sistema.

Veamos un ejemplo tabulado de colas de prioridad: -20 Mayor

Prioridad -19 SWAP

0 firefox apache pop3 sendmail 10 panelcontrol

respaldos 20 Menor Prioridad

En la tabla de ejemplo anterior, el proceso que maneja la swap siempre tendrá mayor prioridad quecualquier otro proceso en un nice level inferior; los procesos que están en la cola de prioridad 0, son los

iniciados por el sistema (normalmente se inician con prioridad 0) y, en esa cola, todos serán atendidos porround robín, es decir, uno a la vez.

El Round Robín permite que se alternen los procesos en el procesador, de forma cíclica. Por ejemplo, un

round robin en el nivel 0 se trabajaría de forma cíclica, asignándose 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 cíclica. En estoconsiste el round robín.

En la prioridad 10, tenemos en el ejemplo un panel de control (le dejamos mejores prioridades a losprocesos con los que el sistema necesita trabajar rápidamente) de tal forma, que éste sólo se ejecutará enlos momentos que el procesador no esté atendiendo a las colas superiores. En este mismo nivel están losrespaldos, de manera que cuando se estén haciendo, los respaldos no afecten a otros procesos, sino quese 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 colapara el trole o para un bus, es el primero de la fila, y llega una señora embarazada, como usted es gentil, ladeja pasar. Usted ha bajado su prioridad, ha demostrado su gentileza, dejándole subir. Por tanto: Mientrasmás 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 común en que los procesos de unix crean nuevosprocesos. También se les llaman procesos padres a los que crean otros procesos, que, por tanto, sonllamados 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 perodándole al hijo su memoria RAM. Es decir, el padre desaparece del sistema y, en su lugar, es ocupado porel hijo. Fork (bifurcación): 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).



4

Un buen ejemplo del uso de fork/exec se puede ver en el login de un sistema Unix desde un terminal. Elproceso 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 línea que dice: login:

CentOS reléase 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 alprograma /sbin/login. /sbin/login y entonces nos pide una clave (si la cuenta la tuviere) y si esta clave es lacorrecta, entonces realiza un exec del shell del usuario (comúnmente bash). Cada vez que ejecutemos unprograma dentro del shell, este hará un fork de sí mismo y su copia realizará un exec de cualquier programaque 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 reléase 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 quisiéramos que el bash hiciera un fork; hay un comando llamado exec que se puede

usar desde el prompt del sistema. Hay que usarlo con atención pues en efecto éste ejecutará cualquierprograma que iniciemos a través de él y eliminará la copia del shell que estemos usando sustituyéndola porel programa en cuestión.

Es muy útil si queremos dejar corriendo una aplicación que no le permita al usuario salir de ella hacia unshell: pues tan pronto termine la ejecución de la aplicación, se realizará un logout ya que el shell, que seejecutó desde el login, habrá sido sustituido previamente mediante un exec por la aplicación. Es decir, noquedarían más recursos detrás de este hijo y se saldría 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 deforma tal que, si algún operador ve que el ping no responde, él pueda tomar ciertas medidas. Sin embargono queremos que este operador tenga acceso al shell y, por ello, una variante muy cómoda sería queacceda 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 noexiste bash, tan sólo es el ping.

De esta forma, el ping se estará ejecutando indefinidamente, hasta que se presione AC, entonces se saldrá

directamente sin caer en ningún 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 shellsino que se cierra la sesión.



5

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 leasigne procesador; este proceso, posiblemente, esté bloqueado esperando por alguna instrucción

de e/s (disco, teclado, etc)

3. Zombie: Es cuando un proceso ha muerto, pero su tarea padre sigue esperando información de

éste. Estos procesos no se pueden matar, técnicamente no existen, pero consumen recursos en la

tabla de procesos. De vez en cuando, el kernel puede limpiarlos, sobre todo si el proceso padre

también muere.

4.1.6 Señales

Las señales son formas de comunicarse entre procesos en Linux. Los procesos se envían mensajes através del kernel, y los procesos de destino del mensaje deberán obedecer o el kernel mismo podráaceptarlas.

Las señales se envían a los procesos mediante un comando conocido como kill (matar).

Las señales pueden ser de 64 tipos diferentes; están numeradas de forma tal que puedan ser diferenciadaspor el kernel. Las más comunes, que estudiaremos aquí son

Nombre NúmeroSIGHUP 1SIGKILL 9SIGUSR1 10SIGTERM 15

• HUP (número 1) Hangup (colgar) Recarga la configuración. Es útil para cuando se ha cambiado el

archivo de configuración de un proceso y se requiere que el proceso lo relea, se le envía la señal 1

y el proceso se ocupará de releer la configuración y se recargará sin dejar de atender a los

usuarios.

• KILL (número 9) Mata un proceso de forma incondicional; esta señal no se ocupa de cerrar

organizadamente archivos abiertos ni de emitir ninguna advertencia, sencillamente, cuando el

kernel ve esta señal elimina el proceso de la tabla de procesos y dispone de la memoria ocupada

previamente por éste.

• USR1 (Número 10) Es una señal para ser usada por diferentes procesos como el bash; es unaforma de matar el bash, por ejemplo, pues éste no obedece a la señal TERM. Se le conoce como:



6

señal a ser definida por el usuario (el programador). El programador de este programa define para

qué utilizará la señal USR1. Nos limitaremos a utilizarla en el bash.

• TERM (número 15) Terminar. Esta señal 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 señal y sólo se dejan matar con la señal 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 señales así como una descripción de las otras señales (son en total 64)) pueden ser obtenidas

con el comando: man 7 signal

4.2 Procesos, /proc y control de procesos

Profundicemos un poco más en el tema de qué es un proceso:

El shell, que típicamente se usa, es el GNU BASH; sin embargo, hay muchas variantes del tipo bourne

como el sh, el ksh. También existen variantes del C Shell (csh) como el tcsh.El shell es un proceso; es uno de los muchos programas que seguramente están ejecutándose al mismotiempo en una computadora. Cada proceso tiene diferentes tipos de información asociado con él,

incluyendo:

Illustration 1: Ejemplo de un shell



7

• El PID o identificador del proceso: Es un número asignado cuando el proceso ha arrancado.

Normalmente es un número consecutivo que solamente se repite cuando se haya alcanzado el

máximo de procesos en la tabla de procesos aunque muchos sistemas de protección, para evitar

que un atacante averigüe fácilmente el pid, prefieren hacerlo aleatorio (así, al hacerse un fork

posiblemente no será el PID del padre+1). En todo caso, es un número único para cada uno de los

procesos corriendo en un sistema.

• El UID o identificador del usuario: Nos indica a quién pertenece este proceso. Determina, por lo

tanto, a qué archivos y directorios éste proceso podrá escribir o podrá leer además de a quién 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 raíz del

proceso del shell. Es decir, básicamente, nos ha indicado los contenidos de una variable deambiente 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 indicarán qué archivos ha abierto este proceso para lectura o

escritura, así como la posición actual dentro de cada uno de ellos.

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

/proc no es un directorio común y corriente, sino que contiene información sobre los procesos, además deinformación sobre el sistema y nos permite realizar cambios en el comportamiento del kernel y susdiferentes módulos o partes.

Centrándonos en el tema de los procesos: vayamos a /proc y listemos dentro de /proc (ls /proc).Observaremos una serie de números en forma de directorio, que nos indican los PID. Dentro de cadadirectorio (pid) se ven una serie de archivos que no son más que diferentes aspectos del proceso, algunosanteriormente descritos, como son:

cmdline: Indica la línea de comando con que el proceso fue ejecutado; por ejemplo, si nos cambiamos a undirectorio dentro de /proc, el del proceso 9408 (cd /proc/9408) y hacemos un cat cmdline, obtendremos losiguiente: cat cmdline bash

Esto nos indica que el proceso 9408 es el bash, que fue ejecutado mediante una simple llamada (bash)



8

Por favor, no esperen ver precisamente el pid 9408, seguramente en las máquinas de ustedes se toparáncon otros números, 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.UTF-

8GDMSESSION=defaultSSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-

askpassSHLVL=1

HOME=/rootLOGNAME = rootDBUS_SESSION_BUS_ADDRESS = unix:abstract=/tmp /dbus-

kbf74OqytDLESSOPEN=|/usr/bin/lesspipe.sh%sDISPLAY=:0.0G_BROKEN_FILENA

MES=1

XAUTHORITY=/root/.XauthorityGTK_RC_FILES=/etc/gtk/gtkrc:/root/.gtkrc-1.2-gnome2SESSION_MANAGER=local/eperez.ecuaLinux.com:/tmp/.ICE-unix/4852

GNOME_KEYRING_SOCKET=/tmp/keyring-rrJk94/socketGNOME_DESKTOP_SESSION_ID = DefaultDESKTOP_STARTUP_ID=COLORTERM=gnome-terminalWINDOWID = 37757804

Las variables son las que aparecen en mayúsculas, 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 información del estado actual

del proceso: cantidad de hilos, información 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)



9

El archivo cwd: Es el directorio de trabajo actual. Nos indica en qué directorio estaba el proceso padrecuando se ejecutó. Es mu útil para cuando tenemos un proceso extraño, levantado por un ajeno intruso ennuestro sistema, para saber dónde estaba el intruso cuando levantó al hijo.

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

cuestión.

El archivo exe: Es el nombre del programa ejecutable del proceso en cuestión. Es decir, es un enlace haciael programa que está siendo ejecutado al que pertenece el proceso.

El archivo root: Es un enlace al directorio raíz del proceso (usualmente /) El directorio fd: contiene todos losfile descriptors abiertos por este proceso.

Como curiosidad si nos cambiamos (cd) al directorio /proc/self nos dará una forma fácil de llegar al procesodesde el que estamos ejecutándonos (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 shellse queda esperando a que el comando termine. Por ejemplo, ejecutemos:

tail -f /var/log/secure

Como podemos ver, el comando tail ocupa todo el terminal, no nos deja escribir nada más, está trabajando.

Una forma de retomar el shell es apretar AC, para matar el proceso de tail. Al apretar AC nos retorna al shell.

Ahora: si no se desea perder control del bash y, además, se quiere ejecutar un proceso y dejarlo corriendohasta 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 información si

llega algo al archivo maillog), pero, además, tenemos acceso al shell. Hemos ejecutado el tail en segundo

plano o background (&).

El símbolo & 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 losarchivos conque el hijo trabaje.



10

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 seguía funcionando.

Por supuesto que es molesto, es decir, eso de ejecutar un comando mientras aparecen caracteres de lasalida de otro comando es un tema batante difícil, pero se puede lograr con cierta habilidad.

¿Cómo ver los procesos que se están ejecutando en el shell?

El comando "jobs" indicará cuántos procesos están ejecutándose en el shell así como su número de trabajo.Por este número se les puede trabajar:

[root@eperez ~]# jobs

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

Aquí se tiene un sólo trabajo que es el trabajo número 1 (fíjense 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 llevaría 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.

¿Cómo 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 serían:

o

Detener temporalmente el proceso

o Mandar el proceso a segundo plano



11

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

• AZ : 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:

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

4.3 Herramientas para monitoreo y trabajo con procesos

Comandos para conocer procesos ejecutándose en el sistema:

Comencemos con los comandos más usados para analizar los procesos ejecutándose en el sistema y conlos diferentes aspectos de ellos como la memoria consumida y la prioridad.

Comandos para verificar procesos corriendo en el sistema:

El más simple pero útil de los comandos es ps, este es un comando bien conocido y no ha variado mucho almomento

Para las personas que conocían el comando de la forma antigua, se les sugirió no usar el signo de -, puespuede conducir a interpretaciones erróneas sobre el funcionamiento.

Algunos switches útiles para ps: Al ejecutar ps sin ningún switch, nos mostrará los procesos ejecutándoseen su shell.

ps a: Muestra todos los procesos que pertenecen a una terminal, sin importar si pertenecen al shell por ellosabierto o no.

ps a divide la pantalla en al menos 5 columnas básicas (algunos comandos mostrarán más informaciónadicional), estas son:



12

• "TTY: Terminal desde donde se está corriendo el proceso

• STAT: Estado del proceso o S: Sleeping

o R: Runnable (o Running) el proceso puede correr o está corriendo o W: sWapped, está en

disco o N: niced, el proceso tiene más baja prioridad o Z: Zombie, el proceso murió sin reportarle

información al padre o D: Uninterruptable sleep, posiblemente esperando por disco. Este

proceso NO PUEDE SER MATADO CON NINGUNA SEÑAL o T: Stopped,

o < Ejecución 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 máquina sea muy accesada y

lleve muchas semanas o meses corriendo sin reiniciarse. Por ejemplo, en este servidor que tengo

con más de 50 días sin reiniciarse, el proceso que consume más 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

tty1 Ss+ 0:00 /sbin/mingetty tty1


4353 tty3 Ss+ 0:00 /sbin/mingetty tty3 4356 tty4 Ss+ 0:00 /sbin/mingetty tty4tty5 Ss+ 0:00 /sbin/mingetty tty5


4446 tty7 SLs+ 10:55 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth 15164 pts/0 Ss 0:00 bash 15193pts/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 más útiles del comando

ps

Ejemplo:

ps axPID TTY STAT4091 ? Ss 0:00 xfs -droppriv -daemon4122 ? Ss 0:00 /usr/sbin/atd4154 ? 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



13

? S 0:00 /usr/libexec/hald-addon-cpufreq4202 ? 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 --system4265 ? Ssl 0:04 NetworkManager --pid-file=/var/run/NetworkManager/Net 4347 ? S 0:00 /usr/sbin/smartd -qnevertty1 Ss+ 0:00 /sbin/mingetty tty1

tty2 Ss+ 0:00 /sbin/mingetty tty2tty3 Ss+ 0:00 /sbin/mingetty tty3 4356 tty4 Ss+ 0:00 /sbin/mingetty tty4

tty5 Ss+ 0:00 /sbin/mingetty tty5tty6 Ss+ 0:00 /sbin/mingetty tty64365 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon

ps aux: lo mismo que el anterior, pero mostrará además información del usuario que corre el proceso y variada

información 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

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

Además nos indicará ciertos valores extras como son:

• %CPU: Porcentaje de la cpu que consumen

• %MEM: Porcentaje de la memoria que consumen

• VSZ: Tamaño virtual del proceso, esto es, el uso de memoria por parte del código (librerías 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]

1 START: Es la hora en que el proceso comenzó



15

|—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 |—wnck-

applet |—xfs 1—xinetd

Nos dará un bonito resumen de los procesos y de qué depende cada uno. El número delante de sendmail

indica que, a ese nivel, hay dos procesos de sendmail levantados.

4.3.2 top:

Este es uno de los comandos más interesantes y usados para monitorear procesos, sobre todo por suinteractividad.

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 número de proceso (de menor a mayor).

El top es de gran ayuda para detectar qué procesos consumen, al momento, mayor memoria o procesador ypermite tomar acciones para mejorar este consumo.

No hay que olvidar que el top es un proceso a su vez y consume también procesador, por lo que si se tieneun servidor medianamente cargado no lo debemos mantener constantemente cargado pues contribuirá acargar más 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, 1zombie, 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 887724kcached

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



16

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 información: la ventana sumaria y la ventana de tareas.

La ventana sumaria es la compuesta por las primeras líneas (depende de la cantidad de procesadores):

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 softirqiowait 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 línea indica que la hora del servidor es "12:45:35" y que el servidor ha estado activo durante 50días, 12 horas y 8 minutos. Actualmente el sistema tiene un sólo usuario conectado y la carga es de 2.13 almomento actual, 2.94 a 5 minutos y 3.06 a 10 minutos.

La segunda línea nos indica que el servidor tiene 221 procesos corriendo, de los cuales 219 estándurmiendo, uno ejecutándose y un zombie.

De la tercera a la sexta línea, se nos indican diferentes aspectos de los dos procesadores que tiene elsistema, 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 están esperando por disco

• Qué porcentaje del procesador está sin ocupar (idle)



17

De todos estos valores, el más importante y, a la vez, más peligroso es el iowait, porque indica que la máquina

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 optimización de disco.

Las tres últimas líneas nos indica, básicamente, lo mismo que el comando free -k, es decir, información sobre el

uso de la memoria RAM de la máquina y la memoria SWAP.

4.3.2.1 Ventana de tareas del top

De aquí en adelante, trabajamos básicamente con lo que se llama ventana de tareas, esto es una descripción

ordenada inicialmente por el número de procesos en que se nos indicarán 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

• tamaño del proceso y datos

• RSS

• SHARE: Memoria compartida con otros procesos

• 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 automáticamente sin esperar a que se completen los 3 segundos.

Espacio=Refresca ahora.



18

• W: Escribe los cambios en la configuración a disco; de lo contrario cualquier cambio que hagamos

con los comandos de orden o de tasa de refrescamiento no tendrán validez para la próxima vez que

ejecutemos el top

• k: mata un proceso, tenemos que indicarles el número de proceso a eliminar y el tipo de señal que

usaremos (por defecto sugieren 15)

Más comandos pueden ser obtenidos mediante: man top

Matando procesos:

Una de las formas más cómodas de matar un proceso es desde el comando top. Desde el top podemos,viendo previamente el número del proceso, indicarle con la letra k, el pid del proceso que deseamos eliminary este comando (top) se ocupará de matarlo.

Como no siempre estamos con el top ejecutándose, el comando más adoptado para matar un proceso es el

comando kill

kill [-SEÑAL] <pid1> [<pid2>...<pidN>]kill requiere de al menos un parámetro y este es el número del proceso que deseamos matar. ¿De dóndesacar el número de proceso?: Ver ps y top

Si no se indica la señal que se usará, el kill trabajará con la señal 15 (TERM).

• kil l -15 1845 es similar a:

• kil l 1845 pues ambas matarán al proceso 1845 con la señal 15

• kill -9 1845, lo matará de forma brusca con la señal KILL (9)

• kill -10 1845 enviará la señal 10 al proceso 1845, el bash por ejemplo no obedece a la señal 15,

es decir con la simple señal 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 señal 10.

• ki ll -9 1023 1024 1025 matará con la señal 9 los procesos 1023, 1024 y 1025

kill es muy útil cuando se tiene que matar un proceso en específico. Ahora, es un poco difícil si se tuvieran

que matar varios procesos a la vez (varios: es un número mayor de 10, se vuelve bien complejo copiar 10 o

más pid fuera de secuencia).

¿Cómo podemos hacer para matar varios procesos a la vez?

Sin duda, el comando killall viene como anillo al dedo: tiene las mismas características del kill en lo querespecta a las señales, excepto que no se pone el pid, sino que se indica el nombre del proceso a matar:

• killall httpd matará, con la señal 15, TODOS los procesos httpd del sistema

• killall -10 bash matará, con la señal 10, TODOS los procesos bash que estén corriendo en el

sistema.

• killall -9 ping matará, con la señal 9, TODOS los potenciales procesos ping que existan en el

sistema.

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



19

De esta sencilla forma se mata un nombre de proceso determinado sin tener que describirle ni el número deproceso ni la cantidad de procesos, puesto que matará ya sea un proceso nombrado de esta forma ocientos 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 estarafectando (o beneficiando) a cientos o miles de usuarios que dependen de este mismo servidor para suslabores normales.

Tarea:

Detectar cuántos procesos bash hay en el sistema, tratar de matarlos primeramente con kill -15 (no 10!!) yposteriormente matarlos con killall enviándole la señal 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 opción, 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 (más bajo que 0), por ejemplo,

verifiquemos:

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 automáticamente 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 teníamos 0, ahora tenemos 5).

Si ahora desde este mismo shell con prioridad 5, ejecutáramos: nice -n -10 bash

Lo que haríamos sería llamar al bash, pero quitarle 10 niveles de prioridad (5-10=-5) por lo que haríamos

correr al bash con una escala negativa, es decir con una prioridad más alta que el común 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 ningún proceso con un nice menor de 0. Por la misma razón, si el nice del usuario es 10, entoncesno podremos llamar a ningún proceso con un nice menor a 10. Básicamente, desde un usuario normal no

podemos ajustar la priori dad (-n) a ningún valor negativo.



20

Verifiquémoslo:

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 mía, 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 número de proceso, cambiarle su prioridad

renice <prioridad> [-p pid ....] [-g grp ....] [-u user ...]

Los usuarios no root, es decir, los usuarios normales del sistema sólo pueden hacer un renice de losprocesos que les pertenecen y no pueden hacer un renice a un valor menor al del shell con el que elloscorren.

Como root podría poner:

renice -10 -u rpc (aumentaría en 10 la prioridad de todos los procesos bajo el usuario rpc)

renice +5 -u rpcuser (disminuiría en 5 la prioridad de todos los procesos bajo el usuario rpcuser)

renice -5 -p 1846 (aumentaría la prioridad del proceso 1846 en 5)

Tarea: Como un usuario no privilegiado (curso por ejemplo) cambiar la prioridad de su propio shell.

COMANDO NOHUPnohup es un comando que viene de la palabra: No Hangup, es muy útil para cuando pretendemos ejecutarun 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 desalir por cualquier concepto (cerrando la ventana, cayéndose la conexión, etc), este comando que se estáejecutando, eventualmente, será eliminado por el kernel.

El comando nohup nos permite que los procesos ignoren las señales KILL y TERM. De esta forma evitamosque sean matados cuando salgamos del sistema y puedan seguir procesándose.

El comando nohup permite, además, que toda la información de salida en vez de ir a la salida estándar

(monitor) lo que hará será guardar toda la salida en el archivo nohup.out para que la podamos analizarposteriormente. Un ejemplo del comportamiento de este comando:

[cpcrcz@cpcrcz

nohup ping 102.16S.Q.1 ít

[1] 18958

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



21

Vemos como nos devuelve al shell (por el &) pero no sale ninguna información del comando ping pues abajo nos

da un mensaje: agregando la salida a nohup.out

Se mantendría ejecutando el ping en el proceso 18958 aún cuando salgamos del sistema, y si hacemos untail -f nohup.out

Podremos ir viendo la salida de ping aún 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, día 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 cómo se comporta

la memoria.

Ejecutar este comando desde nohup.

Otras herramientas de monitoreo

Otra utilería 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 cómo se comporta el sistema en un determinado momento.

El vmstat tiene varios switches para ejecutarse, sin embargo basémonos en esta recomendación para

ejecutarlo, si desean conocer más sobre otros switches, podemos hacerlo viendo la página 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 información mostrada es prácticamente la misma.

Veamos ahora qué significado tiene cada columna; este es un ejemplo que sólo muestra la primera línea:



22

[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 señalar que la primera línea 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 cómo se

comporta el sistema en ESTOS momentos, salen a partir de la segunda línea de información.

En este caso estamos mostrando solamente la primera línea, es decir, los valores promediados desde que la

máquina arrancó.

procs:

se divide en dos parámetros:

• r: runneable processes, o procesos que están 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

exactísimo, es decir, en mi caso hasta 2 o 5 en ciertos momentos estaría bien. Lo que no estaría

bien es un valor constantemente en 4 o en 5.

• b: bloqued, procesos bloqueados, normalmente son procesos que están 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 parámetros:

• 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 sería 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 páginas 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 disponerfácilmente de buff y caché para sus datos no descartables.



23

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 pequeña, debemos considerar que estamos con un sistema recién 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 pequeños picos de acceso.

io

Lo podemos dividir en:

• bi: bytes in, medido en mb que entran a los discos. En sistemas de mensajería, 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 mensajería, pero más

visible en sistemas de web, este valor de bo es bastante alto ya que constantemente se estánleyendo 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 rápido para almacenar o mostrar toda esa cantidad de

información.

Estos valores son muy variables; en un sistema de mensajería bo normalmente tiene picos y es cuando las

máquinas de los clientes hacen pop para recoger los mensajes.

system

Se divide en 2 columnas:

• in: número de interrupciones por segundo

• cs: número 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:



24

• us: tiempo dedicado por el procesador ejecutando código que no es del kernel (tiempo dedicado

al usuario)

• sy: tiempo del sistema (ejecutando código del kernel)

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

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

El más 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 partición no puede

ser desmontada porque alguien los está accediendo, ¿quién está accediendo a esa partición o archivo? El

comando Isof, nos podrá ayudar a contestar esta pregunta.

lsof significa listing of (listado de):

El comando lsof es sumamente poderoso; en esta sección sólo daremos ciertos elementos, pero en

realidad es muy grande y poderoso. Para analizar más el comportamiento de lsof por favor referirse a la

página 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

auditorías 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 información muy

grande.

lsof 'which httpd'nos dirá todos los procesos que estén 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/passwdMe indicará quién está accediendo a /etc/passwd lsof /dev/hda3

Dirá qué procesos están accediendo a la partición /dev/hda3

lsof -t /usr/sbin/sendmail

nos indicará solamente los números de proceso que están accediendo al binario de sendmail.



25

lsof -c bash

nos indicará qué archivos están abiertos por procesos que comiencen con "bash" lsof +p 4025

indicará qué archivos están siendo accesados por el proceso 4025. lsof -i :80

indicará qué procesos están 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, más 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

los accesos de intrusos en una casa con 5 ventanas; al menos el intruso tiene más 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

además de otras formas para prevenir accesos a través 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 través 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 ejecución

Antes de comenzar a configurar los servicios (apagarlos y encenderlos) debemos entender qué son los

niveles de ejecución 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 elnúmero 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



26

• 6 - Reboot

Si al comenzar la máquina, 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 gráfico por defecto (login gráfico) es el runlevel 5, los demás

sencillamente se ocupan de no cargar el ambiente gráfico y de manejar los servicios que le hemos indicado.

El runlevel por defecto puede ser cambiado modificando el archivo /etc/inittab, que contiene una línea 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 deseáramosque nuestro sistema arrancase en el runlevel 3, entonces sencillamente cambiaríamos el 3 por el 5. Este

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 máquina no veríamos el cambio.

Si deseáramos cambiar inmediatamente de nivel, podríamos 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 sinafectar para nada el arranque previsto para el sistema en posteriores momentos. Es decir, si reiniciáramos

el sistema, este arrancaría en el runlevel previsto en /etc/inittab independientemente de que hayamos

ejecutado telinit o no.

Nosotros también usamos el comando init que realiza la misma función del telinit: init 3

Xinetd

El xinetd es un demonio de demonios, es un súper demonio que reemplaza al antiguo inetd.

El demonio xinetd nos ayuda a preservar recursos del sistema además que provee sistemas de control deacceso e históricos para los demonios que ejecuta.

El xinetd puede ser usado para conceder acceso a un host o grupos de hosts a ciertos servicios odemonios. Además de que no mantiene los demonios levantados todo el tiempo sino que solamente losactiva cuando son requeridos en el puerto indicado. De esta forma se ahorra memoria y cpu al no tenerconstantemente un demonio esperando que le soliciten.

Claro, el xinetd también tiene un defecto, si lo usáramos en un servidor muy ocupado, el manejar porejemplo el pop3 como un servicio de xinetd hace que las conexiones de pop sean muy lentas, ya que lafilosofía del xinetd es sólo subir los servicios cuando se les demanda. Por ello, si tenemos que manejar lacarga para digamos 600 o 1000 usuarios (o más) el xinetd tendría que levantar cada cierto periodo detiempo unos 600 o 1000 servicios de pop3 para atender los usuarios. Y levantarlos significa, técnicamente,leerlos del disco y ejecutarlos, por lo que hace un poco lento el proceso.



27

También el xinetd tiene una ventaja y es que puede limitar la tasa de accesos hacia un determinadoservicio.

El archivo de configuración del xinetd es /etc/xinetd.conf pero sugiero no tocarlo pues son configuracionespor 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 cuestión. Cada uno de los archivos que describen elcomportamiento de los servicios tiene una línea que dice:

disable = yes

Lo que significa que el servicio está deshabilitado. Si quisiéramos habilitarlo sencillamente pondríamosdisable = no.

También se pueden editar los servicios del xinetd usando ntsysv o chkconfig como veremos más adelante.

Una vez hayamos cambiado los valores de disable (o cualquier otro valor en un servicio) estos no se activano desactivan automáticamente sino que hay que esperar hasta la próxima vez que reiniciemos el sistema o

hasta que reiniciemos el super demonio xinetd

Un ejemplo de un archivo de configuración 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 parámetro adicional (--daemon)

Descripción y localización de recursos

Veamos un poco más la organización 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 losservicios. 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 ejecución en forma de

directorios. Dentro de cada uno de estos niveles de ejecución están descritos los procesos que se

activarán 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 queindicarán si este enlace (servicio) se ejecutará al arrancar el sistema (si comienza con una S) o al apagarseel sistema (si comienza con una K) y un número que indicará el orden de arranque y parada (S10 va

primero que S80 por ejemplo) posteriormente un texto que nos dice a qué script específicamente apunta.Por ejemplo:



28

Me indica todos los servicios que arrancarán al arrancar el nivel 3 o que pararán al parar el nivel 3.

En el caso de iptables (S08iptables), arrancará (S) después 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 quedeseo; por ejemplo podría mv /etc/rc.d/rc3.d/S44acpid /etc/rc.d/rc3.d/K44acpid y así evitaría que el servicio

acpid arrancara automáticamente con el nivel 3.

Estos archivos anteriormente listados, no son más que apuntadores a /etc/init.d Dentro de /etc/init.d

podemos ver una serie de archivos que no son más que los scripts que contienen la información sobre inicio

y parada de los diferentes servicios o demonios. En cada máquina, estos pueden variar, en dependencia de

lo que hayamos decidido instalar en ella, en mi caso tengo estos servicios:

Posteriormente haremos una breve descripción de los servicios más interesantes de Linux. De momentoveamos una descripción interna de un script:

Si vemos, por ejemplo, el script del servicio sendmail (/etc/init.d/sendmail) podremos notar que las primeras

líneas, 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 cómo hacer

algunos scripts en bash, obviemos la primera línea que es la que indica que correrá en un subshell

(/bin/bash)

Inmediatamente después tenemos una serie de líneas con la descripción del script, se llama sendmail y esel script que se encarga de levantar y parar el servicio se sendmail.

Inmediatamente después vemos una línea muy interesante que es los valores de arrranque y parada

chkconfig: 2345 80 30

Esto le indicará a las utilerías (chkconfig y ntsysv), cuáles serán los modos de arranque por defecto (2 3 4 y 5)

para manejar el arranque y la parada. También les señalará qué posición tendrá en los enlaces directos

(S80sendmail posiblemente, por el 80) y qué valores tendrá al apagarse (K30sendmail posiblemente, por el

30).



29

Posteriormente a esta línea, nos dan una breve descripción 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 máquina 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

número mal puesto o poner un servicio delante de otro que requiere para trabajar (por ejemplo, ¿cómo

echar a andar el sendmail si la red todavía no anda?).

Por ello, en la siguiente sección veremos algunas utilerías para manejar más cómodamente estos servicios.

Netsysv, chkconfig y service

Existen varias formas de controlar los servicios del sistema. Mencionamos

anteriormente, que podemos arrancarlos o no, si borramos o creamos los enlaces correspondientes en/etc/rc.d/rcX.d; sin embargo es un poco difícil de manejar servicios por esa vía, por lo que nosotros veremos

dos opciones mucho más cómodas:

• ntsysv: Es una herramienta gráfica que nos permitirá configurar qué servicios queremos arrancar o

apagar en el runlevel que estamos. Es una forma muy fácil de echar a andar o apagar servicios,

sin embargo en mi nuestra consume demasiado recursos al tener que levantar un pequeño

ambiente gráfico. Además sólo trabaja para el runlevel actual y editar otros runlevels se hace algo

complicado.



30

• chkconfig: Es una utilería muy simple que, igualmente, nos permitirá agregar o quitar servicios del

runlevel en que estamos, pero además nos permitirá

agregar más servicios a la lista de servicios o eliminarlos de esa lista. También nos permitirá un trabajo

un poco más detallado de diferentes runlevels.

En definitiva, ambas utilerías lo que hacen es editar diferentes archivos y enlaces directos que están disponibles

en /etc/rc.d y /etc/init.d

¿Cómo 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.



31

Si quisiéramos ver una lista no tan extendida, sino sencillamente los valores para un sólo servicio

podríamos hacerlo indicándole 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 revés, 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) típicamente no se utilizan pues, cada paquete que instala un servicio se ocupa

de darle de alta en la lista de niveles.

Ahora el switch más 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, también, podemos usar cualquier combinación de

niveles que deseemos, pero lo más común es usarlos todos a la vez (2345). Si solo quisiéramos trabajar

con 3 y 5, podríamos hacerlo con chkconfig --level 35 sendmail on

Ahora, hasta el momento hemos hablado de cómo apagar y levantar servicios pero refiriéndonos a los

niveles de arranque, es decir, hemos hablado de cómo configurar el sistema para cuando se apague o

encienda.

Técnicamente en comportamientos normales, Linux sólo exige ser reiniciado cuando ocurre una condición:

Se actualiza el kernel. Es decir, cuando se hace cualquier labor de reconfiguración del sistema, o cuando se

realiza la actualización 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 antelación, otras veces con atraso, pero no es un incidente frecuente como

sucede en Windows.

Entonces: ¿cómo 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:



32

/etc/init.d/sendmail stop

Por ejemplo, este comando pararía sendmail; lo apagaría, nadie podría ser capaz de enviar mails a través del

servidor.

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

Reiniciaría la red (¡sin tener que reiniciar el sistema!), es decir, técnicamente podría hacer cambios en la

configuración de IP de mi red y, al emitir este comando, ya todo trabajaría.

Ahora: ¿qué es eso de restart, stop, etc? Son las acciones; es cómo 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 configuración del servicio

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

Aunque potencialmente pueden existir otras acciones, estas son las básicas 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.

Demonios del sistema

Marcaremos con negrita los demonios que deseamos activos. Los que no estén en negritas, por favorapagarlos como tarea (chkconfig --level 2345 demonio off; service demonio stop)

¿Por qué los apagaremos? Muy básico: muchos servicios tienen una inmensa utilidad, pero no todos losservicios tienen que estar corriendo todo el tiempo en el sistema, primero porque consumen recursos (cpu,memoria) y más importante, porque pueden ser la puerta de entrada para que los atacantes logren ganaraccesos a nuestro sistema.

Siempre hay que pensar: ¿Qué servicios usaremos realmente? Debemos apagar los que no vayamos apara evitar lo anteriormente expuesto. De cualquier modo, si posteriormente lo requerimos, podemos

volverlos a activar.



33

• acpid - Escucha y despacha eventos ACPI al kernel, para más información 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 batería 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 (búsqueda, descubrimiento, autenticación); Bluetooth es una

tecnología bastante nueva que permite la comunicación entre equipos de forma inalámbrica.

Bluetooth para Linux funciona bastante bien, pero es un poco inseguro, además en el curso noveremos este tipo de comunicación.

• 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 sólo 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 impresión

• dc_client, dc_server - Sistema de distribución de carga de sesiones

• diskdump - Guarda la información de un crash del sistema

• dund - Bluetooth dialup networking.

• functions - Funciones para ser usadas por la mayoría de los scripts de /etc/init.d

• gpm - Soporte del mouse para el ambiente texto. Si pone el mouse en el modo texto, podrán verque hay un cuadrito que se mueve, es el puntero del mouse. Con esta utilería podemos copiar/pegar

texto entre consolas. Si estamos en un servidor remoto, sin conexión 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.



34

• irda - Demonio para el manejo de conexiones infrarrojas. Si no tenemos una laptop o conexión

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 país. 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 acción respecto al hardware nuevo detectado (o al

hardware eliminado). Si nuestro servidor no varía en su hardware, mejor es deshabilitarlo y sólo

ejecutarlo manualmente (kudzu) cuando hayamos puesto algún hardware. El kudzu no afecta elfuncionamiento del sistema, sin embargo, demora un poco más 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 cómo 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é corrección 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 través del sistema de actualizaciones por lo que es transparente cualquier nueva

actualización. Este demonio sólo 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 función de actuar como servidor de DNS, en cursos posteriores

haremos mucho énfasis en el trabajo con dns. Este demonio, por sí sólo, hace que nuestra máquina

actúe como dns de caché, lo que permitirá que ella misma resuelva nombres sin tener que acudir a

los dns del proveedor.

• netdump

• 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 estáticas. De momento no activar. Es para poder manejar caídas 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 más adecuada para su uso. Es algo para mí experimental y debe ser

apagado.



35

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

sistemas unix. Lo veremos más adelante, por favor dejar activado.

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

usuarios y grupos para sistemas de autentificación como ldap, nis, hesiod. Apagar de momento.

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

Apaguémoslo: no trabajaremos Linux como un servidor de tiempo; sin embargo, más adelante sí

veremos cómo sincronizar la hora de nuestro Linux contra servidores de tiempo en Internet.

• pand - Demonio de BT para la red personal. Apaguémoslo.

• pcmcia - Es un demonio que permite instalar dispositivos pcmcia en nuestras máquinas. 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 estadísticas y demás. 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 través 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 gráfico. Verificar que sólo se ejecuta en el

ambiente gráfico, 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

también) 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 versión 4. Dejarlo activado de

momento.

• 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 máquinas Windows hacia nuestro

servidor. Es comúnmente conocido como samba y permite hacer actuar nuestro servidor Linux como



36

un servidor de archivos de Windows. Dejémoslo 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 fácil de configurar que permite cachear

peticiones que hacen las máquinas de nuestra red interna hacia la Internet, ahorrando, de esta

forma, ancho de banda. El squid también 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 más utilizados para acceder remotamente a nuestros servidores. Dejarlo activado,

ya que, en las siguientes semanas, veremos cómo conectarnos por ssh.

• syslog - Demonio que se ocupa de recibir las solicitudes de parte de todos los procesos delsistema para que almacenen en los históricos. Es un demonio muy usado; siempre detrás,

trabajando, guardando los logs. Dejémoslo activado pues es básico para el funcionamiento de los

históricos del sistema.

• tux - Es un servidor web que viene insertado (embebido) dentro del kernel; es muy pequeño y

eficiente, pero sólo maneja páginas estáticas. En la parte de servidores web del curso posiblemente

pondremos enlaces y documentación 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 fácil 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

están guardados en un dominio de un servidor NT. Esto nos permite consolidar los servidores de

autenticación, pudiendo tenerlos en un NT. ¿Quién se atrevería?, al menos yo no me atrevería a

confiar la autenticación a un servidor NT, y como Microsoft constantemente cambia de conceptos, no

lo veremos al momento. Desactivar.

• xfs - Se ocupa de servir tipos de fuentes (fonts) al ambiente gráfico. Dejarlo activado en el modo

5. Si no tuviéramos ambiente gráfico instalado en nuestro servidor (sería lo recomendable por las

razones de ahorro de recursos y prevención de ataques) podríamos apagarlo completamente.

• xinetd - Súperdemonio, demonio de demonios; se ocupará de autenticar algunos pequeños

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

• ypbind - Sistema de autenticación centralizado para servidores unix. Muy popular en su época.

LDAP en estos momentos demuestra ser mucho más eficiente que yp (yellow pages), por lo que no

lo usaremos (al yp). Desactivar.

• yum - Sistema de actualizaciones en línea que, además, permite instalar nuevo software sin

necesidad de CD. Es decir, toma los paquetes rpm de la red de centros y lo instala en nuestrosistema. Este demonio nos permitirá actualizar automáticamente todas las madrugadas nuestro



37

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 varía dependiendo de la plataforma de hardware usada. Sin embargo, unavez que se encuentra el kernel y se carga por el gestor de arranque, el proceso de arranque por defecto esidéntico a través de todas las arquitecturas. Este capítulo 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/OutputSystem o el programa BIOS y lo ejecuta. La BIOS controla, no sólo el primer paso del proceso de arranque,sino que también proporciona una interfaz de bajo nivel para dispositivos periféricos. Por este motivo, se

escribe tan sólo 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 laBIOS en el sistema x86. Por ejemplo, los ordenadores basados en Itanium usan el Shell Interfaz deFirmware extendible (Extensible Firmware Interface, EFI).

Una vez cargada, la BIOS chequea los periféricos 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 continuación, si esto falla, echa un vistazo a las unidades del disco duro delsistema. En la mayoría de los casos, el orden de búsqueda de las unidades para arrancar es controlado poruna configuración de la BIOS y busca por el dispositivo maestro IDE en el bus IDE primario. La BIOS cargaen la memoria cualquier programa que resida en el primer sector de este dispositivo, llamado Registro deArranque Principal o Master Boot Record (MBR). La MBR sólo tiene 512 bytes de tamaño y contiene lasinstrucciones de código de máquina para el arranque del equipo (llamado un gestor de arranque) así como,también, la tabla de particiones. Una vez que la BIOS haya encontrado y cargado el gestor de arranque enmemoria, le deja el control del proceso de arranque a éste.

El gestor de arranque

Esta sección 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 códigobinario de máquina pequeña en el MBR. Su única función es la de localizar el gestor de arranque de lasegunda 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 configuración/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 unapantalla gráfica mostrando los diferentes sistemas operativos o kernels para los que ha sido configuradopara arrancar. En esta pantalla el usuario puede usar las flechas direccionales para escoger el sistema



38

operativo o kernel con el que desea arrancar y presionar la tecla [Intro]. Si no se presiona ninguna tecla,luego de un período de tiempo de espera (también configurable), el gestor de arranque carga la selecciónpredeterminada

Una vez que el gestor de arranque de la segunda etapa haya determinado qué kernel arrancar, localizará elbinario del kernel correspondiente en el directorio /boot/. El kernel binario es llamado usando el siguienteformato — /boot/vmlinuz-<kerne/-version> (donde <kerne/-version> corresponde a la versión del kernel

especificada en las configuraciones del gestor de arranque).

Después, el gestor de arranque coloca una o más de las imágenes apropiadas de initramfs en la memoria.Seguidamente, el kernel descomprime estas imágenes desde la memoria a /boot/, un sistema de archivosvirtual basado en RAM, a través de cpio. El initrd es usado por el kernel para cargar controladores ymódulos necesarios para arrancar el sistema. Esto es muy importante si posee unidades de disco duroSCSI 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 controldel 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 acontecimientossuceden en cada arquitectura. La única diferencia entre el proceso de arranque de cada arquitectura estáen la aplicación que se usa para encontrar y cargar el kernel. Por ejemplo, la arquitectura Itanium utiliza elgestor de arranque ELILO; las arquitecturas eServer pSeries de IBM utilizan YABOOT; y los sistemas IBMeServer zSeries e IBM S/390 usan el gestor de arranque z/IPL.

Consulte el Manua/ de insta/ación de Red Hat Enterprise Linux específico para estas plataformas paraobtener información sobre la configuración de sus gestores de arranque.

El kernel

Cuando se carga el kernel, éste inicializa y configura la memoria del ordenador y los diferentes hardwaresconectados al sistema, incluyendo todos los procesadores, subsistemas de entrada/salida y dispositivos dealmacenamiento. A continuación, busca la imagen comprimida de initramfs en una ubicaciónpredeterminada en la memoria, la descomprime directamente a /sysroot/ y carga todos los controladoresnecesarios. Seguidamente, inicializa los dispositivos virtuales relacionados con el sistema de ficheros, talcomo LVM o software RAID antes de completar los procesos initramfs y de liberar toda la memoria que laimagen del disco ocupó anteriormente.

El kernel luego crea un dispositivo root, monta la partición root como sólo lectura y libera cualquier memoriano utilizada.

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

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



39

Programa /sbin/init

El programa /sbin/init (también 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 comienzanautomáticamente 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 inicialización.

Por ejemplo, la mayoría de los sistemas usan un reloj, por lo tanto, el rc.sysinit lee el archivo de

configuración 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 cómo se debería configurar el sistema encada nivel de ejecución SysV init. Los niveles de ejecución son un estado, o modo, definido por los servicios

listados en el SysV directorio /etc/rc.d/rc<x>.d/, donde <x> es el número de nivel de ejecución. Para más

información sobre los niveles de ejecución SysV init, consulte la Sección 1.4.

A continuación, el comando init configura la biblioteca de funciones fuente, /etc/rc.d/init.d/functions, para el

sistema, que establece el modo en cómo iniciar o matar un programa y cómo determinar el PID del

programa.

El programa init inicia todos los procesos de fondo buscando en el directorio apropiado rc para el nivel de

ejecución especificado por defecto en /etc/inittab. Los directorios rc están numerados para corresponder al

nivel de ejecución que representan. Por ejemplo, /etc/rc.d/rc5.d/ es el directorio para el nivel de ejecución 5.

Cuando se arranca el nivel de ejecución 5, el programa init consulta el directorio /etc/rc.d/rc5.d/ para

determinar qué procesos iniciar o parar.

A continuación un ejemplo de listado del directorio /etc/rc.d/rc5.d/:

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



40

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_earlyS05kudzu -> ../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/irqbalanceS13portmap -> ../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

Como puede ver, ninguno de los scripts que inician y cierran los servicios están localizados en el directorio/etc/rc.d/rc5.d/. Casi todos los ficheros en /etc/rc.d/rc5.d/ son enlaces simbólicos apuntando a los scriptslocalizados en el directorio /etc/rc.d/init.d/. Los enlaces simbólicos se usan en cada uno de los directorios rcde manera que los niveles de ejecución puedan ser reconfigurados al crear, modificar y eliminar los enlacessimbólicos sin que afecten a los scripts actuales a los que se refiere.

El nombre de cada enlace simbólico comienza con K o S. Los enlaces K son procesos eliminados en esenivel de ejecución, mientras que aquellos que inician por S son procesos a iniciar.

El comando init, en primer lugar, detiene todos los enlaces simbólicos de K en el directorio mediante la

ejecución del comando /etc/rc.d/init.d/<command> stop, en el que <command> es el proceso a matar. Acontinuación inicia todos los enlaces simbólicos S al ejecutar /etc/rc.d/init.d/<command>. start.



Cada uno de los enlaces simbólicos se numera para dictaminar el orden de inicio. Usted puede variar elorden en el que los servicios inician o paran al cambiar este número. Mientras más bajo es el número, másrápido se arrancará. Los enlaces simbólicos con el mismo número se inician de modo alfabético.

Después que el comando init ha progresado a través del directorio adecuado rc para el nivel de ejecución, el

script /etc/inittab bifurca un proceso /sbin/mingetty para cada consola virtual (prompt de inicio de sesión) delnivel de ejecución. Los niveles de ejecución del 2 al 5 tienen seis consolas virtuales; mientras que el nivel deejecución 1 (modo usuario único) tiene tan sólo uno, y lo niveles de ejecución del 0 al 6 no tienen ninguno.El proceso /sbin/mingetty abre las rutas de la comunicación para los dispositivos tty, establece sus modos,imprime el indicador de inicio de sesión, toma el nombre y contraseña del usuario, e inicia el proceso deinicio de sesión. En el nivel de ejecución 5, /etc/inittab ejecuta un script llamado /etc/X11/prefdm. El scriptprefdm ejecuta su gestor de pantalla de X preferido — gdm, kdm, o xdm, dependiendo de los contenidos delarchivo /etc/sysconfig/desktop. Una vez que haya terminado, el sistema operará en el nivel de ejecución 5 ymostrará la pantalla de inicio de sesión.

Fin del capítulo.

tema 4 gestion procesos y sistema arranque

Documents