Documente Academic
Documente Profesional
Documente Cultură
DE PROCESOS
Y ARRANQUE
de
textos
http://aula.virtualepn.edu.ec
infovirtual@cec-epn.edu.ec
ADMINISTRACIN DE LINUX I
Gestin de Procesos y Arranque
Material para la modalidad virtual
Master Ricardo B. Ortega O.
www.ricardoortega.com
SWAP
firefox
respaldos 20
Menor
Mayor
panelcontrol
Prioridad
En la tabla de ejemplo anterior, el proceso que maneja la swap siempre tendr mayor prioridad que
cualquier otro proceso en un nice level inferior; los procesos que estn en la cola de prioridad 0, son los
iniciados por el sistema (normalmente se inician con prioridad 0) y, en esa cola, todos sern atendidos por
round robn, es decir, uno a la vez.
El Round Robn permite que se alternen los procesos en el procesador, de forma cclica. Por ejemplo, un
round robin en el nivel 0 se trabajara de forma cclica, asignndose tiempo de procesador de la siguiente
forma:
firefox -> apache -> pop3 -> sendmail -> firefox -> apache -> pop3 -> sendmail -> firefox -> apache -> pop3 > sendmail -> firefox -> apache -> pop3 -> sendmail -> y as sucesivamente en forma cclica. En esto
consiste el round robn.
En la prioridad 10, tenemos en el ejemplo un panel de control (le dejamos mejores prioridades a los
procesos con los que el sistema necesita trabajar rpidamente) de tal forma, que ste slo se ejecutar en
los momentos que el procesador no est atendiendo a las colas superiores. En este mismo nivel estn los
respaldos, de manera que cuando se estn haciendo, los respaldos no afecten a otros procesos, sino que
se vayan realizando a medida que quede libre el procesador.
Los nice levels (niveles de gentileza) pueden verse en un ejemplo de la vida real: Usted est haciendo cola
para el trole o para un bus, es el primero de la fila, y llega una seora embarazada, como usted es gentil, la
deja pasar. Usted ha bajado su prioridad, ha demostrado su gentileza, dejndole subir. Por tanto: Mientras
ms gentil uno es, menos prioridad tiene. As lo ve Linux.
Existen dos formas de que un padre arranque (o engendre) a un hijo: exec: El padre arranca al hijo pero
dndole al hijo su memoria RAM. Es decir, el padre desaparece del sistema y, en su lugar, es ocupado por
el hijo. Fork (bifurcacin): El padre necesita permanecer vivo, por ello crea una copia de s mismo en un
rea aparte de memoria, y esta copia comete suicidio ejecutando un exec para que el hijo le reemplace.
Quedan entonces el padre y el hijo en memoria (el hijo ocupando el lugar de la copia del padre).
Un buen ejemplo del uso de fork/exec se puede ver en el login de un sistema Unix desde un terminal. El
proceso init engendra una serie de procesos getty, cada uno de ellos monitorea un puerto serial o consola
(ttyS o tty) en espera de actividad. Es el programa getty el que realmente pone la lnea que dice: login:
CentOS relase 5 (Final)
Kernel 2.6.18-53.1.19.el5 on an x86_64
servidor login:
Una vez que alguien escriba su username el trabajo del getty est terminado, este hace un exec al
programa /sbin/login. /sbin/login y entonces nos pide una clave (si la cuenta la tuviere) y si esta clave es la
correcta, entonces realiza un exec del shell del usuario (comnmente bash). Cada vez que ejecutemos un
programa dentro del shell, este har un fork de s mismo y su copia realizar un exec de cualquier programa
que le hayamos requerido. Como s que se hizo un fork? Porque al ejecutar un programa desde el shell, el
shell no se pierde definitivamente sino que regresa al finalizarse el programa.
CentOS relase 5 (Final)
Kernel 2.6.18-53.1.19.el5 on an x86_64
servidor login: root
Password: [root@servidor i
En caso de que no quisiramos que el bash hiciera un fork; hay un comando llamado exec que se puede
usar desde el prompt del sistema. Hay que usarlo con atencin pues en efecto ste ejecutar cualquier
programa que iniciemos a travs de l y eliminar la copia del shell que estemos usando sustituyndola por
el programa en cuestin.
Es muy til si queremos dejar corriendo una aplicacin que no le permita al usuario salir de ella hacia un
shell: pues tan pronto termine la ejecucin de la aplicacin, se realizar un logout ya que el shell, que se
ejecut desde el login, habr sido sustituido previamente mediante un exec por la aplicacin. Es decir, no
quedaran ms recursos detrs de este hijo y se saldra a la pantalla del login.
4.1.4 Formas de usar el exec
Veamos un ejemplo: Supongamos que tenemos que dejar un shell abierto ejecutando un ping a Internet de
forma tal que, si algn operador ve que el ping no responde, l pueda tomar ciertas medidas. Sin embargo
no queremos que este operador tenga acceso al shell y, por ello, una variante muy cmoda sera que
acceda desde el shell ejectar:
exec ping www.google.com
exec, se ocupa de reemplazar el shell (bash) por el programa que le indicamos (ping en este caso). Ya no
existe bash, tan slo es el ping.
De esta forma, el ping se estar ejecutando indefinidamente, hasta que se presione AC, entonces se saldr
directamente sin caer en ningn momento en el shell, ya que se us un exec y no un fork.
Ejercicio: probar el comando anterior, notar como al finalizar el ping (apretando AC) no se regresa al shell
sino que se cierra la sesin.
4.1.5 Estados de un proceso
Los procesos se pueden catalogar en 3 estados fundamentales (aunque existen otros):
1. Running: Es cuando un proceso est haciendo uso del procesador, o est en la lista de espera por el
procesador (Runnable)
2. Stopped: Es cuando un proceso voluntariamente se retira del procesador y solicita que no le
asigne procesador; este proceso, posiblemente, est bloqueado esperando por alguna instruccin
de e/s (disco, teclado, etc)
3. Zombie: Es cuando un proceso ha muerto, pero su tarea padre sigue esperando informacin de
ste. Estos procesos no se pueden matar, tcnicamente no existen, pero consumen recursos en la
tabla de procesos. De vez en cuando, el kernel puede limpiarlos, sobre todo si el proceso padre
tambin muere.
4.1.6 Seales
Las seales son formas de comunicarse entre procesos en Linux. Los procesos se envan mensajes a
travs del kernel, y los procesos de destino del mensaje debern obedecer o el kernel mismo podr
aceptarlas.
Las seales se envan a los procesos mediante un comando conocido como kill (matar).
Las seales pueden ser de 64 tipos diferentes; estn numeradas de forma tal que puedan ser diferenciadas
por el kernel. Las ms comunes, que estudiaremos aqu son
Nombre
SIGHUP
SIGKILL
SIGUSR1
SIGTERM
Nmero
1
9
10
15
HUP (nmero 1) Hangup (colgar) Recarga la configuracin. Es til para cuando se ha cambiado el
archivo de configuracin de un proceso y se requiere que el proceso lo relea, se le enva la seal 1
y el proceso se ocupar de releer la configuracin y se recargar sin dejar de atender a los
usuarios.
KILL (nmero 9) Mata un proceso de forma incondicional; esta seal no se ocupa de cerrar
organizadamente archivos abiertos ni de emitir ninguna advertencia, sencillamente, cuando el
kernel ve esta seal elimina el proceso de la tabla de procesos y dispone de la memoria ocupada
previamente por ste.
USR1 (Nmero 10) Es una seal para ser usada por diferentes procesos como el bash; es una
forma de matar el bash, por ejemplo, pues ste no obedece a la seal TERM. Se le conoce como:
seal a ser definida por el usuario (el programador). El programador de este programa define para
qu utilizar la seal USR1. Nos limitaremos a utilizarla en el bash.
TERM (nmero 15) Terminar. Esta seal indica a un proceso que debe cerrarse; el proceso,
entonces, proceder como mejor le convenga, posiblemente cerrando todos los archivos que tiene
abierto y mandando a liberar la memoria que ocupa en el sistema. Algunos procesos a veces caen
en un estado en el que no pueden responder a esta seal y slo se dejan matar con la seal KILL
(9), pero nunca debemos intentar enviar directamente KILL sin probar enviar TERM ya que es una
forma imperiosa y un poco brusca para cerrar los procesos.
Todas estas seales as como una descripcin de las otras seales (son en total 64)) pueden ser obtenidas
con el comando: man 7 signal
El shell, que tpicamente se usa, es el GNU BASH; sin embargo, hay muchas variantes del tipo bourne
como el sh, el ksh. Tambin existen variantes del C Shell (csh) como el tcsh.
El UID o identificador del usuario: Nos indica a quin pertenece este proceso. Determina, por lo
tanto, a qu archivos y directorios ste proceso podr escribir o podr leer adems de a quin le
ser permitido matar este proceso.
El GID o identificador del grupo: es similar al UID, pero determina a qu grupo ste pertenece.
El ambiente de trabajo o environment: Contiene una lista de variables y valores asociados. Por ejemplo, si
nosotros escribimos: echo $HOME en el shell, ste nos indicar el nombre del directorio raz del
proceso del shell. Es decir, bsicamente, nos ha indicado los contenidos de una variable de
ambiente llamada HOME.
Directorio de trabajo actual: Si no se especifica un directorio para abrir un archivo o para ejecutarlo,
el proceso mirar al directorio actual (CWD o current working directory) y proceder a tratar de
abrirlo desde ah.
Descriptores (file descriptors): Nos indicarn qu archivos ha abierto este proceso para lectura o
escritura, as como la posicin actual dentro de cada uno de ellos.
Todos estos detalles pueden ser vistos en nuestro sistema Linux. Cada proceso que se ejecuta en el
sistema, abre un "directorio" con toda su informacin dentro del directorio /proc.
/proc no es un directorio comn y corriente, sino que contiene informacin sobre los procesos, adems de
informacin sobre el sistema y nos permite realizar cambios en el comportamiento del kernel y sus
diferentes mdulos o partes.
Centrndonos en el tema de los procesos: vayamos a /proc y listemos dentro de /proc (ls /proc).
Observaremos una serie de nmeros en forma de directorio, que nos indican los PID. Dentro de cada
directorio (pid) se ven una serie de archivos que no son ms que diferentes aspectos del proceso, algunos
anteriormente descritos, como son:
cmdline: Indica la lnea de comando con que el proceso fue ejecutado; por ejemplo, si nos cambiamos a un
directorio dentro de /proc, el del proceso 9408 (cd /proc/9408) y hacemos un cat cmdline, obtendremos lo
siguiente: cat cmdline bash
Esto nos indica que el proceso 9408 es el bash, que fue ejecutado mediante una simple llamada (bash)
Por favor, no esperen ver precisamente el pid 9408, seguramente en las mquinas de ustedes se toparn
con otros nmeros, sencillamente escojan uno o varios al azar para mirar dentro.
El archivo environ: nos indica las variables de ambiente con que este proceso
trabaja:
cat environ
SSH_AGENT_PID=4877HOSTNAME=eperez.ecuaLinux.comTERM=xtermSHELL=/bi n/bashHISTSIZE =
1000USER=rootLS_COLORS = SSH_AUTH_SOCK=/tmp/ssh-KjxSWn4876/agent.4876
PATH=/usr/java/j2re1.5.0_01/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local
/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:
/root/binDESKTOP_SESSION=defaultMAIL=/var/spool/mail/rootPWD=/root
INPUTRC=/etc/inputrcJAVA_HOME=/usr/java/j2re1.5.0_01LANG=en_US.UTF8GDMSESSION=defaultSSH_ASKPASS=/usr/libexec/openssh/gnome-sshaskpassSHLVL=1
HOME=/rootLOGNAME = rootDBUS_SESSION_BUS_ADDRESS = unix:abstract=/tmp /dbuskbf74OqytDLESSOPEN=|/usr/bin/lesspipe.sh%sDISPLAY=:0.0G_BROKEN_FILENA
MES=1
10
XAUTHORITY=/root/.XauthorityGTK_RC_FILES=/etc/gtk/gtkrc:/root/.gtkrc-1.2gnome2SESSION_MANAGER=local/eperez.ecuaLinux.com:/tmp/.ICE-unix/4852
GNOME_KEYRING_SOCKET=/tmp/keyringrrJk94/socketGNOME_DESKTOP_SESSION_ID
OLORTERM=gnome-terminalWINDOWID = 37757804
DefaultDESKTOP_STARTUP_ID=C
Las variables son las que aparecen en maysculas, por ejemplo veo una llamada HISTSIZE=1000 es decir,
una variable llamada HISTORY que tiene de valor 1000.
El archivo status: Es otra variable. Contiene diversa informacin del estado actual
del proceso: cantidad de hilos, informacin sobre el pid del padre (ppid), memoria
consumida, cantidad de descriptores reservada, el estado del proceso (en este
ejemplo, est en estado de sleeping), etc.
[root@eperez 9408]# cat status
[root@eperez 9408]# cat status
Name: bash
State: S (sleeping)
El archivo cwd: Es el directorio de trabajo actual. Nos indica en qu directorio estaba el proceso padre
cuando se ejecut. Es mu til para cuando tenemos un proceso extrao, levantado por un ajeno intruso en
nuestro sistema, para saber dnde estaba el intruso cuando levant al hijo.
Si dentro del proceso, ejecutamos el comando; "cd cwd" ste nos llevar directamente al directorio en
cuestin.
El archivo exe: Es el nombre del programa ejecutable del proceso en cuestin. Es decir, es un enlace hacia
el programa que est siendo ejecutado al que pertenece el proceso.
El archivo root: Es un enlace al directorio raz del proceso (usualmente /) El directorio fd: contiene todos los
file descriptors abiertos por este proceso.
Como curiosidad si nos cambiamos (cd) al directorio /proc/self nos dar una forma fcil de llegar al proceso
desde el que estamos ejecutndonos (bash posiblemente).
Como podemos ver, el comando tail ocupa todo el terminal, no nos deja escribir nada ms, est trabajando.
A
Una forma de retomar el shell es apretar C, para matar el proceso de tail. Al apretar C nos retorna al shell.
Ahora: si no se desea perder control del bash y, adems, se quiere ejecutar un proceso y dejarlo corriendo
hasta que finalice, se puede hacer mediante el comando &
tail -f /var/log/maillog &
Lo que har ser hacer un tail con polling (-f: es decir que busca siempre al final del archivo).
Si se fijan, en este ejemplo, el tail se est ejecutando (eventualmente puede mostrar alguna informacin si
llega algo al archivo maillog), pero, adems, tenemos acceso al shell. Hemos ejecutado el tail en segundo
plano o background (&).
El smbolo & al final de un comando
Al agregarse este signo al final de otro comando, lo que se hace es mandar este trabajo (proceso) al fondo,
a background, a segundo plano, y mientras el trabajo est corriendo, podremos seguir usando el shell en
primer plano (foreground).
El padre (en este caso del ejemplo, el shell) no puede interactuar para cambiar al hijo, ni el hijo en el padre,
es decir, al dejar al tail en background, se pudieron mover de directorio hacia otros lugares sin que esto
afectara el directorio de trabajo del hijo (que ser el directorio desde el que se le invoc inicialmente) ni los
archivos conque el hijo trabaje.
El comando "jobs" indicar cuntos procesos estn ejecutndose en el shell as como su nmero de trabajo.
Por este nmero se les puede trabajar:
12
Aqu se tiene un slo trabajo que es el trabajo nmero 1 (fjense en [1]) y es un trabajo que est corriendo
(Running)
Podemos traer los trabajos a primer plano con el comando fg %#detrabajo, por
ejemplo:
fg %1
As se llevara este trabajo a primer plano.
En el primer plano, se ha "perdido el shell" nuevamente, pues el tail ahora se est ejecutando pero no deja
acceso al shell hasta que termine.
con el &: ejecutar el proceso y al final llamarlo con &, de esta forma se le mueve a segundo plano
desde el mismo inicio.
Pero a veces ya se ha iniciado el proceso y se le quiere llevar a segundo plano, los pasos seran:
o
Z : esto detiene el proceso, nos brinda un shell pero el proceso no est corriendo, est detenido,
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 &
Listo, lo tenemos corriendo en background a pesar de que, al inicio, estuvo en fg. Ejercicio:
13
Como ejercicio ejecutar el gnome-calculator desde un shell, detenerle (con AZ), tratar de usarle as detenido
y posteriormente ponerle en background.
W: sWapped, est en
disco o N: niced, el proceso tiene ms baja prioridad o Z: Zombie, el proceso muri sin reportarle
informacin al padre o D: Uninterruptable sleep, posiblemente esperando por disco. Este
proceso NO PUEDE SER MATADO CON NINGUNA SEAL
o
T: Stopped,
JTIME: El tiempo de procesador (en minutos: segundos) que el proceso ha consumido. Este es un
tiempo que, normalmente, no debe ser muy grande, a no ser que la mquina sea muy accesada y
lleve muchas semanas o meses corriendo sin reiniciarse. Por ejemplo, en este servidor que tengo
con ms de 50 das sin reiniciarse, el proceso que consume ms tiempo (50 minutos y 24 segundos
de procesador) es:
o
Ejemplo: ps a
PID TTY STAT TIME COMMAND
14
Ejemplo:
ps ax
PID TTY STAT
4091 ? Ss 0:00 xfs -droppriv -daemon
4122 ? Ss 0:00 /usr/sbin/atd
4154 ? S 0:09 /usr/bin/python /usr/sbin/yum-updatesd
? Ss 0:00 avahi-daemon: running [eperez.local]
? Ss 0:00 avahi-daemon: chroot helper
? Ss 0:07 hald
? S 0:00 hald-runner
? S 0:00 hald-addon-acpi: listening on acpid socket /var/run/a
? S 0:00 /usr/libexec/hald-addon-cpufreq
4202 ? S 0:00 hald-addon-keyboard: listening on /dev/input/event1 4208 ? S 0:00 hald-addon-keyboard:
listening on /dev/input/event0 4218 ? S 0:03 hald-addon-storage: polling /dev/hdc 4261 ? Ss 0:04
/sbin/dhcdbd --system
4265 ? Ssl 0:04 NetworkManager --pid-file=/var/run/NetworkManager/Net 4347 ? S 0:00 /usr/sbin/smartd -q
never
tty1 Ss+ 0:00 /sbin/mingetty tty1
tty2 Ss+ 0:00 /sbin/mingetty tty2
tty3 Ss+ 0:00 /sbin/mingetty tty3 4356 tty4 Ss+ 0:00 /sbin/mingetty tty4
tty5 Ss+ 0:00 /sbin/mingetty tty5
tty6 Ss+ 0:00 /sbin/mingetty tty6
4365 ? Ss 0:00 /usr/sbin/gdm-binary -nodaemon
ps aux: lo mismo que el anterior, pero mostrar adems informacin del usuario que corre el proceso y variada
informacin como la memoria consumida por cada proceso.
Por ejemplo: ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2016 0.0 0.1 1576 592 ? Ss
10:43 0:00 syslogd -m 0 root 2020 0.0 0.1 2800 468 ? Ss 10:43 0:00 klogd -x rpc 2041 0.0 0.1 3392 592 ?
Ss 10:43 0:00 portmap rpcuser 2061 0.0 0.1 1752 768 ? Ss 10:43 0:00 rpc.statd root 2094 0.0 0.2 5328
1008 ? Ss 10:43 0:00 rpc.idmapd root 2160 0.0 0.1 2860 816 ? S 10:43 0:00 /usr/sbin/smartd
15
Nos indicar en la primera columna que el usuario bajo el que se ejecuta el proceso portmap se llama rpc y
bajo el que se ejecuta el proceso rpc.statd se llama rpcuser; los otros procesos son ejecutados a nombre de
root
VSZ: Tamao virtual del proceso, esto es, el uso de memoria por parte del cdigo (libreras y
RSS: Es el uso de memoria sin contar con el uso de ciertas funciones del kernel, tabla de procesos, etc.
| gnome-session |gnome-keyring-d
|gnome-panel |gnome-settings|gnome-terminal|bash6ssh | |bash
1
4.3.2 top:
Este es uno de los comandos ms interesantes y usados para monitorear procesos, sobre todo por su
interactividad.
En cuanto se ejecuta top, se debe tener presente que cada tecla que se apriete para top tendr un
significado. Top entra por defecto en un lazo infinito mostrando cada 3 segundos una lista de los procesos
ordenados por el nmero de proceso (de menor a mayor).
El top es de gran ayuda para detectar qu procesos consumen, al momento, mayor memoria o procesador y
permite tomar acciones para mejorar este consumo.
No hay que olvidar que el top es un proceso a su vez y consume tambin procesador, por lo que si se tiene
un servidor medianamente cargado no lo debemos mantener constantemente cargado pues contribuir a
cargar ms el procesador.
un ejemplo de top:
12:45:35 up 50 days, 12:08, 1 user, load average: 2.13, 2.94, 3.06 221 processes: 219 sleeping, 1 running, 1
zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle
total 21.2% 0.0% 17.0% 0.0% 2.4% 27.4% 131.4%
cpu00 8.1% 0.0% 10.1% 0.0% 1.9% 13.1% 66.5%
cpu01 13.1% 0.0% 6.9% 0.0% 0.5% 14.3% 64.9%
Mem: 2055440k av, 2005688k used, 49752k free, 0k shrd, 147416k buff
1374096k actv, 266100k in_d, 30932k in_c Swap: 2008084k av, 20972k used, 1987112k free 887724k
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
root 19 0 388 360 336 S 0.0 0.0 4:32 1 init
root RT 0 0 0 0 SW 0.0 0.0 0:00 0 migration/0
root RT 0 0 0 0 SW 0.0 0.0 0:00 1 migration/1
root 15 0 0 0 0 SW 0.0 0.0 0:00 1 keventd
root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd/0
root 34 19 0 0 0 SWN 0.0 0.0 0:00 1 ksoftirqd/1
root 15 0 0 0 0 SW 0.0 0.0 26:51 1 kswapd
root 15 0 0 0 0 SW 1.3 0.0 292:27 1 kscand
root 15 0 0 0 0 SW 0.0 0.0 0:00 1 bdflush
El top normalmente trabaja mostrando dos tipos de informacin: la ventana sumaria y la ventana de tareas.
La ventana sumaria es la compuesta por las primeras lneas (depende de la cantidad de procesadores):
18
La primera lnea indica que la hora del servidor es "12:45:35" y que el servidor ha estado activo durante 50
das, 12 horas y 8 minutos. Actualmente el sistema tiene un slo usuario conectado y la carga es de 2.13 al
momento actual, 2.94 a 5 minutos y 3.06 a 10 minutos.
La segunda lnea nos indica que el servidor tiene 221 procesos corriendo, de los cuales 219 estn
durmiendo, uno ejecutndose y un zombie.
De la tercera a la sexta lnea, se nos indican diferentes aspectos de los dos procesadores que tiene el
sistema, tales como:
Qu porcentaje del procesador se usa por procesos de usuario (no root, no del sistema) (user)
Qu porcentaje del procesador se usa por procesos que tienen un cambio de prioridad (nice)
Qu porcentaje del procesador se usa en procesos que estn esperando por disco
De todos estos valores, el ms importante y, a la vez, ms peligroso es el iowait, porque indica que la mquina
tiene, posiblemente, un grave problema de entrada salida; seguramente de acceso al disco; si este valor
supera, digamos el 30 al 50%, es un valor que definitivamente hay que considerar cambiar mediante trabajo
de optimizacin de disco.
Las tres ltimas lneas nos indica, bsicamente, lo mismo que el comando free -k, es decir, informacin sobre el
uso de la memoria RAM de la mquina y la memoria SWAP.
prioridad (es un valor asignado por el kernel, ver slices en tema anterior)
nice level
RSS
Estado
%CPU
%MEM
Estos detalles los podemos ajustar con diferentes comandos que existen dentro del top:
Espacio=Refresca ahora.
W: Escribe los cambios en la configuracin a disco; de lo contrario cualquier cambio que hagamos
con los comandos de orden o de tasa de refrescamiento no tendrn validez para la prxima vez que
ejecutemos el top
k: mata un proceso, tenemos que indicarles el nmero de proceso a eliminar y el tipo de seal que
usaremos (por defecto sugieren 15)
Matando procesos:
Una de las formas ms cmodas de matar un proceso es desde el comando top. Desde el top podemos,
viendo previamente el nmero del proceso, indicarle con la letra k, el pid del proceso que deseamos eliminar
y este comando (top) se ocupar de matarlo.
Como no siempre estamos con el top ejecutndose, el comando ms adoptado para matar un proceso es el
comando kill
kill [-SEAL] <pid1> [<pid2>...<pidN>]
kill requiere de al menos un parmetro y este es el nmero del proceso que deseamos matar. De dnde
sacar el nmero de proceso?: Ver ps y top
Si no se indica la seal que se usar, el kill trabajar con la seal 15 (TERM).
kill -10 1845 enviar la seal 10 al proceso 1845, el bash por ejemplo no obedece a la seal 15,
es decir con la simple seal 15 no se deja matar. Al parecer est hecho para evitar un error al
matarlo, el bash solo se muere en caso de recibir la seal 10.
kill -9 1023 1024 1025 matar con la seal 9 los procesos 1023, 1024 y 1025
kill es muy til cuando se tiene que matar un proceso en especfico. Ahora, es un poco difcil si se tuvieran
que matar varios procesos a la vez (varios: es un nmero mayor de 10, se vuelve bien complejo copiar 10 o
ms pid fuera de secuencia).
killall httpd matar, con la seal 15, TODOS los procesos httpd del sistema
killall -10 bash matar, con la seal 10, TODOS los procesos bash que estn corriendo en el
sistema.
killall -9 ping matar, con la seal 9, TODOS los potenciales procesos ping que existan en el
sistema.
killall sendmail matar TODOS los procesos sendmail que existan en el sistema.
De esta sencilla forma se mata un nombre de proceso determinado sin tener que describirle ni el nmero de
proceso ni la cantidad de procesos, puesto que matar ya sea un proceso nombrado de esta forma o
cientos o miles de procesos que se nombren as.
Siempre se debe ser muy cuidadosos a la hora de matar un proceso, pues invariablemente hay que pensar
que no somos los nicos que trabajamos con un servidor y que, por tanto, nuestras acciones pueden estar
afectando (o beneficiando) a cientos o miles de usuarios que dependen de este mismo servidor para sus
labores normales.
Tarea:
Detectar cuntos procesos bash hay en el sistema, tratar de matarlos primeramente con kill -15 (no 10!!) y
posteriormente matarlos con killall envindole la seal 10. Qu diferencias hay?
nice: sin ninguna otra opcin, nos dir el nivel de nice conque estamos corriendo (nice hereda este valor del
shell).
nice bash ejecutar el shell bash, pero lo har con un nivel de prioridad de 10 (ms bajo que 0), por ejemplo,
verifiquemos:
21
1. El primer nice que ejecutamos lo hacemos dentro de un shell con prioridad 0, por eso sale 0
2. Dentro de este shell, invocamos a un segundo shell: (nice bash), se baja automticamente la
prioridad de este programa pues lo ejecutamos con nice.
3. Es por esto que al ejecutar nuevamente nice, nos responde: 10.. que se est ejecutando dentro de
un shell con prioridad 10.
Cerremos todos los shells que abrimos (apretando Ad varias veces).
Por ejemplo, suponiendo que nuestro shell tiene un nivel de nice de 0, al ejecutar: nice -n 5 bash
Lo que har ser ejecutar el bash con un nivel de prioridad 5 (antes tenamos 0, ahora tenemos 5).
Si ahora desde este mismo shell con prioridad 5, ejecutramos: nice -n -10 bash
Lo que haramos sera llamar al bash, pero quitarle 10 niveles de prioridad (5-10=-5) por lo que haramos
correr al bash con una escala negativa, es decir con una prioridad ms alta que el comn de los procesos
(prioridad 0). Podemos verificarlos ejecutando solamente: nice
ATENCION: Los usuarios normales no pueden llamar al nice con un valor menor al valor de su shell. Es decir, si
tenemos un usuario cualquiera (digamos: eperez), y el nice de este usuario es de 0, entonces no podremos
llamar a ningn proceso con un nice menor de 0. Por la misma razn, si el nice del usuario es 10, entonces
no podremos llamar a ningn proceso con un nice menor a 10. Bsicamente, desde un usuario normal no
podemos ajustar la prioridad (-n) a ningn valor negativo.
Verifiqumoslo:
su - eperez (me convierto en el usuario eperez) nice (nos dir que 0)
nice -n -1 bash (intento ponerme con una prioridad mayor a la original ma, me negar)
nice -n 5 bash (me dejar disminuir mi prioridad, a 5) nice (en efecto me indicar
5)
nice -n -2 bash (intento nuevamente bajarme de 5 a 3, me dir que no).
RENICE:
renice permite, dado un nmero de proceso, cambiarle su prioridad
renice <prioridad> [-p pid ....] [-g grp ....] [-u user ...]
Los usuarios no root, es decir, los usuarios normales del sistema slo pueden hacer un renice de los
procesos que les pertenecen y no pueden hacer un renice a un valor menor al del shell con el que ellos
corren.
Como root podra poner:
renice -10 -u rpc (aumentara en 10 la prioridad de todos los procesos bajo el usuario rpc)
renice +5 -u rpcuser (disminuira en 5 la prioridad de todos los procesos bajo el usuario rpcuser)
renice -5 -p 1846 (aumentara la prioridad del proceso 1846 en 5)
22
Tarea: Como un usuario no privilegiado (curso por ejemplo) cambiar la prioridad de su propio shell.
COMANDO NOHUP
nohup es un comando que viene de la palabra: No Hangup, es muy til para cuando pretendemos ejecutar
un comando que no se cuelgue en caso de que salgamos del shell.
En efecto, al ejecutar un comando con & este seguir escribiendo al terminal en que estamos, en caso de
salir por cualquier concepto (cerrando la ventana, cayndose la conexin, etc), este comando que se est
ejecutando, eventualmente, ser eliminado por el kernel.
El comando nohup nos permite que los procesos ignoren las seales KILL y TERM. De esta forma evitamos
que sean matados cuando salgamos del sistema y puedan seguir procesndose.
El comando nohup permite, adems, que toda la informacin de salida en vez de ir a la salida estndar
(monitor) lo que har ser guardar toda la salida en el archivo nohup.out para que la podamos analizar
posteriormente. Un ejemplo del comportamiento de este comando:
[cpcrcz@cpcrcz
[1]
18958
Vemos como nos devuelve al shell (por el &) pero no sale ninguna informacin del comando ping pues abajo nos
da un mensaje: agregando la salida a nohup.out
Se mantendra ejecutando el ping en el proceso 18958 an cuando salgamos del sistema, y si hacemos un
tail -f nohup.out
Podremos ir viendo la salida de ping an cuando regresemos en unas horas.
Un proceso ejecutado con nohup acaba cuando l decida que es tiempo (por ejemplo si usamos wget para bajar
un sitio lo podemos dejar con nohup y al, da siguiente, verificar que todo est bien) o si es un proceso que
no acaba (el ping por ejemplo), podemos matarlo mediante kill.
23
El vmstat tiene varios switches para ejecutarse, sin embargo basmonos en esta recomendacin para
ejecutarlo, si desean conocer ms sobre otros switches, podemos hacerlo viendo la pgina de manual (man
vmstat)
Lo que indicar que realice un chequeo del sistema cada 5 segundos y que muestre los valores en megabyted
(de lo contrario lo mostrar en kb)
Para los usuarios que tengan rhel3, la forma antigua de ejecutar el vmstat era:
vmstat -m 5
En cualquiera de las dos variantes, la informacin mostrada es prcticamente la misma.
Veamos ahora qu significado tiene cada columna; este es un ejemplo que slo muestra la primera lnea:
[root@eperez ~]# vmstat -S m 5
procs ------------------ memory -------------- swap --------io ------ system ------ cpu ---r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 113 23 199 0 0 87 24
1060 503 11 1 85 3
Ante todo hay que sealar que la primera lnea de datos que se muestra en el vmstat indica un promedio desde
que el sistema fue encendido; es decir, los valores actuales, los valores que indican claramente cmo se
comporta el sistema en ESTOS momentos, salen a partir de la segunda lnea de informacin.
En este caso estamos mostrando solamente la primera lnea, es decir, los valores promediados desde que la
mquina arranc.
procs:
se divide en dos parmetros:
Normalmente el valor de r debe ser igual o menor a la cantidad de procesadores que tengamos. En
mi caso es 1 y, por lo tanto, para mi uniprocesador est bien. No debe tomarse como un valor
24
exactsimo, es decir, en mi caso hasta 2 o 5 en ciertos momentos estara bien. Lo que no estara
bien es un valor constantemente en 4 o en 5.
b: bloqued, procesos bloqueados, normalmente son procesos que estn esperando por e/s, es
decir disco. No es natural tener procesos en b, para servidores MUY altamente usados, es natural
tener algunos procesos en b, pero no es normal que el b sea mayor que r. Como siempre, no es una
receta a seguir, solamente indico que si b se mantiene constantemente con muchos procesos, esto
es signo de que algo anda mal, o lento, en el disco y debemos tomar acciones pertinentes.
memory:
se divide en 4 parmetros:
swpd: indica la cantidad de memoria que est swapeada. Normalmente el sistema Linux usa la
swap; por ello no es signo de alarma que la memoria tenga partes swapeadas, pero s lo sera si la
swap comienza a incrementarse en cada chequeo a lo largo del tiempo o que la swap
constantemente est variando (unas veces crece, otras decrece) pues es indicador de que se est
recayendo constantemente en ella y esto afecta el funcionamiento del sistema.
cache: Es la memoria destinada a cachear accesos a disco y pginas de procesos en general, es til
para mejorar el funcionamiento del sistema.
La memoria libre realmente se puede considerar la suma de free+buff+cache, pues el sistema puede disponer
fcilmente de buff y cach para sus datos no descartables.
La memoria free es normalmente bastante baja, ya que el sistema siempre trata de usar el resto de la
memoria libre para cachear.
Si la memoria cache es pequea, debemos considerar que estamos con un sistema recin arrancado, o el
sistema se est quedando sin memoria (es decir, no puede cachear mucho porque casi toda la ram la
est dedicando a datos no descartables).
swap:
Lo podemos dividir en:
En todo caso no es normal que el sistema est constantemente si/so, a veces puede ocurrir y es natural, lo que
no es normal es que el sistema est todo el tiempo mostrando datos de swap. Este valor debe estar
mayormente en 0 con algunos pequeos picos de acceso.
io
Lo podemos dividir en:
25
bi: bytes in, medido en mb que entran a los discos. En sistemas de mensajera, el bi siempre es
bo: bytes out, medido en mb que salen de los discos. En sistemas de mensajera, pero ms
visible en sistemas de web, este valor de bo es bastante alto ya que constantemente se estn
leyendo datos del disco.
Estos valores, sobre todo bo, pueden ser un buen indicador de que el sistema necesita incrementar la cach.
Pero no es nada malo, pues el disco est para eso: para ser accedido. Ahora, hay que saber determinar
cuando un disco no es lo suficientemente rpido para almacenar o mostrar toda esa cantidad de
informacin.
Estos valores son muy variables; en un sistema de mensajera bo normalmente tiene picos y es cuando las
mquinas de los clientes hacen pop para recoger los mensajes.
system
Se divide en 2 columnas:
Estos dos valores no los vamos a analizar pues no aportan datos interesantes.
cpu
Se divide en 4 columnas, las cuales son porcentajes de:
us: tiempo dedicado por el procesador ejecutando cdigo que no es del kernel (tiempo dedicado
al usuario)
26
El comando lsof es sumamente poderoso; en esta seccin slo daremos ciertos elementos, pero en
realidad es muy grande y poderoso. Para analizar ms el comportamiento de lsof por favor referirse a la
pgina manual (man lsof) o referirse a la Internet.
lsof es una herramienta muy til en todas las circunstancias, ya sea para chequeos diarios del sistema como para
auditoras de seguridad.
indicar qu archivos estn siendo accesados por el proceso 4025. lsof -i :80
indicar qu procesos estn accediendo al puerto 80 de nuestra red. 4.4
27
los accesos de intrusos en una casa con 5 ventanas; al menos el intruso tiene ms posibilidades de ser
capturado.
Los servicios son programas hechos por seres humanos, pueden contener y, de hecho, contienen errores.
En clases siguientes trataremos algunas formas que usa redhat para controlar accesos no autorizados
adems de otras formas para prevenir accesos a travs de fallas. A pesar de esto, no hay nada mejor que
tener la certeza total de que no entre un atacante por un servicio con falla y la mejor forma de que alguien
no entre a travs de un servicio es... Exacto!: Apagar el servicio. Al apagarlo ya no nos preocupar tanto si
el servicio tiene fallas o no, sencillamente no est corriendo y por lo tanto no podr ser explotado.
4.3.2
Niveles de ejecucin
Antes de comenzar a configurar los servicios (apagarlos y encenderlos) debemos entender qu son los
niveles de ejecucin de Linux.
Un nivel es un estado o un modo, que es definido por los servicios listados en /etc/rc.d/rcX.d, donde X es el
nmero del nivel.
En RedHat los siguientes niveles (runlevels):
0 - Halt
2 - no usado actualmente
4 - no usado actualmente
6 - Reboot
Si al comenzar la mquina, vemos una pantalla de login en modo texto (negra con letras blancas) entonces
casi seguramente estamos trabajando en el runlevel 3.
El nico runlevel que tiene ambiente grfico por defecto (login grfico) es el runlevel 5, los dems
sencillamente se ocupan de no cargar el ambiente grfico y de manejar los servicios que le hemos indicado.
El runlevel por defecto puede ser cambiado modificando el archivo /etc/inittab, que contiene una lnea casi al
inicio que dice algo as:
id:5:initdefault:
Esto lo que significa (en mi caso) que el nivel de arranque por defecto de mi sistema es el 5. Si deseramos
que nuestro sistema arrancase en el runlevel 3, entonces sencillamente cambiaramos el 3 por el 5. Este
28
cambio no har efecto de forma inmediata, /etc/inittab es lo que ejecuta el proceso init al arrancar el
sistema, por lo tanto hasta que no reiniciemos la mquina no veramos el cambio.
Si deseramos cambiar inmediatamente de nivel, podramos usar el comando telinit seguido del nivel al que
queremos llegar telinit 3
Tanto para ejecutar telinit como para cambiar /etc/inittab se debe estar como el usuario root. telinit no
cambia el archivo /etc/inittab, sino que sencillamente cambia el runlevel que actualmente ejecutamos sin
afectar para nada el arranque previsto para el sistema en posteriores momentos. Es decir, si reiniciramos
el sistema, este arrancara en el runlevel previsto en /etc/inittab independientemente de que hayamos
ejecutado telinit o no.
Nosotros tambin usamos el comando init que realiza la misma funcin del telinit: init 3
Xinetd
El xinetd es un demonio de demonios, es un sper demonio que reemplaza al antiguo inetd.
El demonio xinetd nos ayuda a preservar recursos del sistema adems que provee sistemas de control de
acceso e histricos para los demonios que ejecuta.
El xinetd puede ser usado para conceder acceso a un host o grupos de hosts a ciertos servicios o
demonios. Adems de que no mantiene los demonios levantados todo el tiempo sino que solamente los
activa cuando son requeridos en el puerto indicado. De esta forma se ahorra memoria y cpu al no tener
constantemente un demonio esperando que le soliciten.
Claro, el xinetd tambin tiene un defecto, si lo usramos en un servidor muy ocupado, el manejar por
ejemplo el pop3 como un servicio de xinetd hace que las conexiones de pop sean muy lentas, ya que la
filosofa del xinetd es slo subir los servicios cuando se les demanda. Por ello, si tenemos que manejar la
carga para digamos 600 o 1000 usuarios (o ms) el xinetd tendra que levantar cada cierto periodo de
tiempo unos 600 o 1000 servicios de pop3 para atender los usuarios. Y levantarlos significa, tcnicamente,
leerlos del disco y ejecutarlos, por lo que hace un poco lento el proceso.
Tambin el xinetd tiene una ventaja y es que puede limitar la tasa de accesos hacia un determinado
servicio.
El archivo de configuracin del xinetd es /etc/xinetd.conf pero sugiero no tocarlo pues son configuraciones
por defecto del xinetd que funcionan bien. La parte interesante del xinetd est en /etc/xinetd.d
Para habilitar o deshabilitar cualquier servicio, debemos verificar que este exista dentro de /etc/xinetd.d. Una
vez verificado, podemos editar el servicio en cuestin. Cada uno de los archivos que describen el
comportamiento de los servicios tiene una lnea que dice:
disable = yes
Lo que significa que el servicio est deshabilitado. Si quisiramos habilitarlo sencillamente pondramos
disable = no.
Tambin se pueden editar los servicios del xinetd usando ntsysv o chkconfig como veremos ms adelante.
Una vez hayamos cambiado los valores de disable (o cualquier otro valor en un servicio) estos no se activan
o desactivan automticamente sino que hay que esperar hasta la prxima vez que reiniciemos el sistema o
hasta que reiniciemos el super demonio xinetd
29
default: off
description: The rsync server is a good addition to an ftp server, as it # allows crc checksumming etc.
service rsync {
disable = yes socket_type = stream wait = no user = root
server = /usr/bin/rsync server_args = --daemon
Este es un servicio llamado rsync, permite sincronizar datos entre servidores, por defecto est deshabilitado
(disable=yes) y el servicio que corre es /usr/bin/rsync con un parmetro adicional (--daemon)
/etc/init.d: Es el directorio donde se almacenan en s los scripts que manejan la actividad de los
servicios. En las versiones de RedHat (CentOS) esto es un enlace directo al directorio real que est
localizado en /etc/rc.d/init.d
directorios. Dentro de cada uno de estos niveles de ejecucin estn descritos los procesos que se
activarn dentro de cada nivel. Son sencillamente accesos directos a /etc/init.d
En /etc/rc.d/rc3.d, por ejemplo, tendremos una serie de enlaces directos hacia el directorio /etc/init.d que
indicarn si este enlace (servicio) se ejecutar al arrancar el sistema (si comienza con una S) o al apagarse
el sistema (si comienza con una K) y un nmero que indicar el orden de arranque y parada (S10 va
primero que S80 por ejemplo) posteriormente un texto que nos dice a qu script especficamente apunta.
Por ejemplo:
Me indica todos los servicios que arrancarn al arrancar el nivel 3 o que pararn al parar el nivel 3.
En el caso de iptables (S08iptables), arrancar (S) despus que el servicio kudzu (S08 es mayor que S05,
kudzu por lo tanto arranca primero).
Una forma de evitar que un script arranque (o pare) puede ser cambiando el acceso directo del nivel que
deseo; por ejemplo podra mv /etc/rc.d/rc3.d/S44acpid /etc/rc.d/rc3.d/K44acpid y as evitara que el servicio
acpid arrancara automticamente con el nivel 3.
Estos archivos anteriormente listados, no son ms que apuntadores a /etc/init.d Dentro de /etc/init.d
podemos ver una serie de archivos que no son ms que los scripts que contienen la informacin sobre inicio
y parada de los diferentes servicios o demonios. En cada mquina, estos pueden variar, en dependencia de
lo que hayamos decidido instalar en ella, en mi caso tengo estos servicios:
30
Posteriormente haremos una breve descripcin de los servicios ms interesantes de Linux. De momento
veamos una descripcin interna de un script:
Si vemos, por ejemplo, el script del servicio sendmail (/etc/init.d/sendmail) podremos notar que las primeras
lneas, aunque comentadas, nos son de gran utilidad para determinar en qu consiste este servicio:
#!/bin/bash
#
# sendmail This shell script takes care of starting and stopping
# sendmail.
#
# chkconfig: 2345 80 30
# description: Sendmail is a Mail Transport Agent, which is the program \
# that moves mail from one machine to another.
Este es un script normal hecho en bash. Debido a que posteriormente veremos en el curso cmo hacer
algunos scripts en bash, obviemos la primera lnea que es la que indica que correr en un subshell
(/bin/bash)
Inmediatamente despus tenemos una serie de lneas con la descripcin del script, se llama sendmail y es
el script que se encarga de levantar y parar el servicio se sendmail.
Inmediatamente despus vemos una lnea muy interesante que es los valores de arrranque y parada
chkconfig: 2345 80 30
Esto le indicar a las utileras (chkconfig y ntsysv), cules sern los modos de arranque por defecto (2 3 4 y 5)
para manejar el arranque y la parada. Tambin les sealar qu posicin tendr en los enlaces directos
(S80sendmail posiblemente, por el 80) y qu valores tendr al apagarse (K30sendmail posiblemente, por el
30).
Posteriormente a esta lnea, nos dan una breve descripcin para los efectos que querramos de qu labor
realizar el servicio. En este caso nos indicar que el sendmail es un MTA o mail transport agent que es el
programa que se encarga de enviar los mails de una mquina a otra.
Ahora, editar manualmente estos enlaces, con el objetivo de borrar un servicio de la lista de arranque de un
modo, es un poco complicado y podemos caer en errores como el hecho de poner una s en vez de S, o un
nmero mal puesto o poner un servicio delante de otro que requiere para trabajar (por ejemplo, cmo
echar a andar el sendmail si la red todava no anda?).
Por ello, en la siguiente seccin veremos algunas utileras para manejar ms cmodamente estos servicios.
anteriormente, que podemos arrancarlos o no, si borramos o creamos los enlaces correspondientes en
/etc/rc.d/rcX.d; sin embargo es un poco difcil de manejar servicios por esa va, por lo que nosotros veremos
dos opciones mucho ms cmodas:
ntsysv: Es una herramienta grfica que nos permitir configurar qu servicios queremos arrancar o
apagar en el runlevel que estamos. Es una forma muy fcil de echar a andar o apagar servicios,
sin embargo en mi nuestra consume demasiado recursos al tener que levantar un pequeo
ambiente grfico. Adems slo trabaja para el runlevel actual y editar otros runlevels se hace algo
complicado.
chkconfig: Es una utilera muy simple que, igualmente, nos permitir agregar o quitar servicios del
runlevel en que estamos, pero adems nos permitir
agregar ms servicios a la lista de servicios o eliminarlos de esa lista. Tambin nos permitir un trabajo
un poco ms detallado de diferentes runlevels.
En definitiva, ambas utileras lo que hacen es editar diferentes archivos y enlaces directos que estn disponibles
en /etc/rc.d y /etc/init.d
32
Si quisiramos ver una lista no tan extendida, sino sencillamente los valores para un slo servicio
podramos hacerlo indicndole el nombre del servicio: [root@eperez ~]# chkconfig --list sendmail sendmail
0:off 1 :off 2:on 3:on 4:on 5:on 6:off
nos permite configurar un servicio nuevo en todos los niveles declarados en su script de inicio.
chkconfig --del servicio
nos permitir hacer lo mismo pero al revs, eliminar todos los enlaces directos de los directorios /etc/rc.d/rcX.d
para que no levante ni sea matado al terminar el sistema.
Estos dos switches (--add y --del) tpicamente no se utilizan pues, cada paquete que instala un servicio se ocupa
de darle de alta en la lista de niveles.
Ahora el switch ms interesante: --level
--level se usa para cambiar el estado de un servicio en diferentes runlevels a la vez. Se ejecuta as:
chkconfig --level 2345 sendmail on
Esto indicar al servicio sendmail que debe activarse en los niveles 2,3,4 y 5.
Por supuesto podemos usar off para desactivarlo y, tambin, podemos usar cualquier combinacin de
niveles que deseemos, pero lo ms comn es usarlos todos a la vez (2345). Si solo quisiramos trabajar
con 3 y 5, podramos hacerlo con chkconfig --level 35 sendmail on
Ahora, hasta el momento hemos hablado de cmo apagar y levantar servicios pero refirindonos a los
niveles de arranque, es decir, hemos hablado de cmo configurar el sistema para cuando se apague o
encienda.
Tcnicamente en comportamientos normales, Linux slo exige ser reiniciado cuando ocurre una condicin:
Se actualiza el kernel. Es decir, cuando se hace cualquier labor de reconfiguracin del sistema, o cuando se
33
realiza la actualizacin del sistema, no es necesario reiniciar Linux. Todo debe correr de forma casi
inmediata, excepto cuando actualizamos el kernel, ya que ste s exige (de momento) que sea reiniciado el
sistema Linux para que el nuevo kernel comience a trabajar. Esto es un incidente que ocurre una vez cada
algunos meses; unas veces con antelacin, otras veces con atraso, pero no es un incidente frecuente como
sucede en Windows.
Entonces: cmo podemos hacer para apagar un demonio o levantarlo, de forma inmediata? Bueno,
tenemos dos formas, la primera es ejecutar directamente el script que est en /etc/init.d:
/etc/init.d/sendmail stop
Por ejemplo, este comando parara sendmail; lo apagara, nadie podra ser capaz de enviar mails a travs del
servidor.
Reiniciara la red (sin tener que reiniciar el sistema!), es decir, tcnicamente podra hacer cambios en la
configuracin de IP de mi red y, al emitir este comando, ya todo trabajara.
Ahora: qu es eso de restart, stop, etc? Son las acciones; es cmo podemos llamar un script e indicarle qu
debe realizar.
status: Indica el estado del servicio (Is running, list de PIDs, etc)
Aunque potencialmente pueden existir otras acciones, estas son las bsicas para cada servicio.
Tarea: Probar estas acciones con el comando service para cuantos servicios tenga en /etc/init.d.
Hay que anotar que el comando service (o /etc/init.d/demonio) no apaga ni enciende permanentemente un
demonio: en cuanto el sistema es reiniciado, el sistema obedecer a lo que le hemos indicado con los
comandos chkconfig; es decir, con lo que le tengamos indicado en los directorios /etc/rc.d/rcX.d). El
comando service sirve para apagar o encender inmediatamente un servicio sin esperar a reiniciar el
sistema. Pero no indica que quedar encendido o apagado por siempre, sino que solamente mientras el
sistema est encendido as se quedar el comando.
34
acpid - Escucha y despacha eventos ACPI al kernel, para ms informacin sobre el acpi, ver aqu
anacron - Ejecuta trabajos del cron que no han sido ejecutados por estar apagado el server.
apmd - Se usa para monitorear el uso de la batera y guardarlo en los logs. Para configurarlo se
puede hacer en /etc/sysconfig/apmd
cpuspeed - Es un demonio que se encarga de reducir los ciclos del procesador en caso de que el
sistema est con baja carga, de esta forma ahorra corriente. Solamente es efectivo para
procesadores que lo soporten (por ejemplo mi amd sempron no lo soporta). En todo caso es un
demonio que corre slo y no es necesario tocarlo. Si notamos que el sistema se cuelga en
momentos de inactividad (por las noches), sugiero, primero que todo, apagar el cpuspeed a ver si
esto ayuda a salir de los problemas.
crond - Ejecuta tareas programadas mediante el sistema cron (en la siguiente clase hablaremos
de l).
functions - Funciones para ser usadas por la mayora de los scripts de /etc/init.d
35
gpm - Soporte del mouse para el ambiente texto. Si pone el mouse en el modo texto, podrn ver
que hay un cuadrito que se mueve, es el puntero del mouse. Con esta utilera podemos copiar/pegar
texto entre consolas. Si estamos en un servidor remoto, sin conexin permanente al teclado/mouse,
sugiero deshabilitarlo.
haldaemon - Apagar
hidd - Human interface devices (prove, via Bluetooth, acceso al teclado, mouse, etc)
irda - Demonio para el manejo de conexiones infrarrojas. Si no tenemos una laptop o conexin
sistema entre los diferentes procesadores. Si nuestro sistema es un uniprocesador, este demonio no
tiene mucho sentido.
killall - Este script se encarga de matar todos los procesos en un runlevel, debe ser ejecutado
kudzu - Es un demonio que se ejecuta al arrancar el sistema y detecta cualquier hardware nuevo
instalado, y nos pide que tomemos alguna accin respecto al hardware nuevo detectado (o al
hardware eliminado). Si nuestro servidor no vara en su hardware, mejor es deshabilitarlo y slo
ejecutarlo manualmente (kudzu) cuando hayamos puesto algn hardware. El kudzu no afecta el
funcionamiento del sistema, sin embargo, demora un poco ms el arranque pues en cada arranque
se molestar en verificar durante unos segundos (menos de 5) qu hay de nuevo.
liberados por Intel. Intel nunca indica qu correccin va en cada parche, pero los parches ayudan a
mejorar el funcionamiento del procesador por lo que es bueno tenerlo activado. El demonio se
actualiza a travs del sistema de actualizaciones por lo que es transparente cualquier nueva
actualizacin. Este demonio slo se ejecuta al arrancar el sistema y no consume muchos recursos.
No soporta otros procesadores que no sean Intel, puede ir apagado en amd.
named - Demonio que tiene la funcin de actuar como servidor de DNS, en cursos posteriores
haremos mucho nfasis en el trabajo con dns. Este demonio, por s slo, hace que nuestra mquina
acte como dns de cach, lo que permitir que ella misma resuelva nombres sin tener que acudir a
los dns del proveedor.
netdump
36
netfs - Es el sistema ocupado de montar y desmontar otros tipos de FS (de red) como el NFS,
samba, NCP (netware), etc. Como usaremos samba y nfs, sugiero dejarlo activado.
network - Es el demonio que se encarga de apagar/encender las interfaces de red del sistema.
informarle al sistema sobre la ms adecuada para su uso. Es algo para m experimental y debe ser
apagado.
portmap, nfslock, nfs - Demonios que permiten compartir directorios, partes del disco, entre
nscd - Name Switch Cache Daemon se ocupa de cachear respuestas a peticiones sobre
usuarios y grupos para sistemas de autentificacin como ldap, nis, hesiod. Apagar de momento.
ntpd - Demonio que permite a nuestro servidor actuar como un servidor para sincronizar la hora.
pcmcia - Es un demonio que permite instalar dispositivos pcmcia en nuestras mquinas. Por
defecto viene apagado, como nuestros servidores no tienen dispositivos pcmcia, es bueno
asegurarse de que est apagado
psacct - Demonio para llevar la contabilidad de los procesos, las estadsticas y dems. Este
crudo (raw, no formateados); sin embargo, ya se considera depreciado pues las aplicaciones no
deben hacer peticiones a travs del rawdevice sino haciendo llamadas directas al sistema. De
momento mantener encendido.
ser usados. Es particularmente bueno para el ambiente grfico. Verificar que slo se ejecuta en el
ambiente grfico, no es un demonio sino que se ejecuta al comenzar el sistema. Mantener activo en
el modo 5
tambin) y verificar si existen actualizaciones. En los sistemas redhat es importante dejarlo activo
para que verifique constantemente la licencia contra los servidores de redhat. Para centros podemos
apagarlo ya que usaremos yum.
rpcgssd, rpcidmapd, rpcsvcgssd - Permiten el trabajo con NFS versin 4. Dejarlo activado de
momento.
37
saslauthd - Permite manejar las autenticaciones de usuarios (en texto claro). Dejarlo activo de
sendmail - MTA que estudiaremos; se ocupa de recibir y enviar mensajes desde y hacia
smartd - Demonio que permite obtener datos del sistema S.M.A.R.T, un sistema de monitoreo
presente en discos tipo IDE. No afecta al funcionamiento pero no lo veremos, as que podemos
desactivarlo
smb - Demonio que se ocupa del manejo de conexiones de mquinas Windows hacia nuestro
servidor. Es comnmente conocido como samba y permite hacer actuar nuestro servidor Linux como
un servidor de archivos de Windows. Dejmoslo activado, pues lo usaremos posteriormente en el
curso.
spamassassin - Permite cargar el demonio del spamd, para realizar chequeos antispam de los
mails que llegan a nuestro sistema. No lo usaremos de esta forma (demonio) sino que,
posteriormente en el curso, aprenderemos a llamarlo cada vez que necesitemos analizar un lote de
mensajes. Desactivar.
squid - Servidor muy popular en Internet, bastante fcil de configurar que permite cachear
peticiones que hacen las mquinas de nuestra red interna hacia la Internet, ahorrando, de esta
forma, ancho de banda. El squid tambin permite balancear carga entre servidores web. Activarlo,
pues lo veremos en el curso.
sshd - Demonio que se encarga de las conexiones seguras hacia nuestro servidor. Es uno de
los sistemas base ms utilizados para acceder remotamente a nuestros servidores. Dejarlo activado,
ya que, en las siguientes semanas, veremos cmo conectarnos por ssh.
syslog - Demonio que se ocupa de recibir las solicitudes de parte de todos los procesos del
sistema para que almacenen en los histricos. Es un demonio muy usado; siempre detrs,
trabajando, guardando los logs. Dejmoslo activado pues es bsico para el funcionamiento de los
histricos del sistema.
tux - Es un servidor web que viene insertado (embebido) dentro del kernel; es muy pequeo y
eficiente, pero slo maneja pginas estticas. En la parte de servidores web del curso posiblemente
pondremos enlaces y documentacin sobre el uso del tux. Normalmente debe ir desactivado ya que
es un poco complicado echarlo a andar junto con el apache (httpd); aunque, definitivamente, en
algunas circunstancias es muy til por su eficiencia.
vsftpd - Servidor de ftp. Dejarlo activado pues lo usaremos posteriormente en el curso. Este
servidor de ftp es muy seguro y fcil de configurar y, en la actualidad, es muy popular en el mercado.
winbind - Servicio que nos permite autenticar usuarios en nuestro sistema Linux. Estos usuarios
estn guardados en un dominio de un servidor NT. Esto nos permite consolidar los servidores de
autenticacin, pudiendo tenerlos en un NT. Quin se atrevera?, al menos yo no me atrevera a
confiar la autenticacin a un servidor NT, y como Microsoft constantemente cambia de conceptos, no
lo veremos al momento. Desactivar.
38
xfs - Se ocupa de servir tipos de fuentes (fonts) al ambiente grfico. Dejarlo activado en el modo
5. Si no tuviramos ambiente grfico instalado en nuestro servidor (sera lo recomendable por las
razones de ahorro de recursos y prevencin de ataques) podramos apagarlo completamente.
servicios. Personalmente no veo su utilidad al momento, por lo que prefiero que lo desactivemos.
ypbind - Sistema de autenticacin centralizado para servidores unix. Muy popular en su poca.
LDAP en estos momentos demuestra ser mucho ms eficiente que yp (yellow pages), por lo que no
lo usaremos (al yp). Desactivar.
yum - Sistema de actualizaciones en lnea que, adems, permite instalar nuevo software sin
necesidad de CD. Es decir, toma los paquetes rpm de la red de centros y lo instala en nuestro
sistema. Este demonio nos permitir actualizar automticamente todas las madrugadas nuestro
sistema Linux, sin tener preocuparnos por hacerlo manualmente. Por supuesto, si no hay
actualizaciones, no har nada esa noche.
La BIOS
Cuando un PC x86 se carga, el procesador busca al final de la memoria del sistema por Basic Input/Output
System o el programa BIOS y lo ejecuta. La BIOS controla, no slo el primer paso del proceso de arranque,
sino que tambin proporciona una interfaz de bajo nivel para dispositivos perifricos. Por este motivo, se
escribe tan slo en modo de lectura, de memoria permanente y est siempre disponible para el uso.
Otras plataformas usan programas diferentes para ejecutar tareas a bajo nivel equivalentes a aquellas de la
BIOS en el sistema x86. Por ejemplo, los ordenadores basados en Itanium usan el Shell Interfaz de
Firmware extendible (Extensible Firmware Interface, EFI).
Una vez cargada, la BIOS chequea los perifricos y localiza un dispositivo con el que arrancar el sistema.
Habitualmente, en primer lugar, comprueba cualquier disquete y unidades de CD-ROM presentes por los
medios de arranque y, a continuacin, si esto falla, echa un vistazo a las unidades del disco duro del
sistema. En la mayora de los casos, el orden de bsqueda de las unidades para arrancar es controlado por
una configuracin de la BIOS y busca por el dispositivo maestro IDE en el bus IDE primario. La BIOS carga
en la memoria cualquier programa que resida en el primer sector de este dispositivo, llamado Registro de
Arranque Principal o Master Boot Record (MBR). La MBR slo tiene 512 bytes de tamao y contiene las
instrucciones de cdigo de mquina para el arranque del equipo (llamado un gestor de arranque) as como,
tambin, la tabla de particiones. Una vez que la BIOS haya encontrado y cargado el gestor de arranque en
memoria, le deja el control del proceso de arranque a ste.
39
El gestor de arranque
Esta seccin revisa los gestores de arranque para la plataforma x86, GRUB.
Un gestor de arranque para la plataforma x86 se divide en al menos dos etapas. La primera es un cdigo
binario de mquina pequea en el MBR. Su nica funcin es la de localizar el gestor de arranque de la
segunda etapa y cargar la primera parte de ste en memoria.
GRUB tiene la ventaja de ser capaz de leer particiones ext2 y ext3 y cargar su archivo de configuracin
/boot/grub/grub.conf al momento de arranque.
Una vez que la segunda etapa del gestor de arranque est en la memoria, presenta al usuario con una
pantalla grfica mostrando los diferentes sistemas operativos o kernels para los que ha sido configurado
para arrancar. En esta pantalla el usuario puede usar las flechas direccionales para escoger el sistema
operativo o kernel con el que desea arrancar y presionar la tecla [Intro]. Si no se presiona ninguna tecla,
luego de un perodo de tiempo de espera (tambin configurable), el gestor de arranque carga la seleccin
predeterminada
Una vez que el gestor de arranque de la segunda etapa haya determinado qu kernel arrancar, localizar el
binario del kernel correspondiente en el directorio /boot/. El kernel binario es llamado usando el siguiente
formato /boot/vmlinuz-<kerne/-version> (donde <kerne/-version> corresponde a la versin del kernel
especificada en las configuraciones del gestor de arranque).
Despus, el gestor de arranque coloca una o ms de las imgenes apropiadas de initramfs en la memoria.
Seguidamente, el kernel descomprime estas imgenes desde la memoria a /boot/, un sistema de archivos
virtual basado en RAM, a travs de cpio. El initrd es usado por el kernel para cargar controladores y
mdulos necesarios para arrancar el sistema. Esto es muy importante si posee unidades de disco duro
SCSI o si el sistema utiliza el sistema de archivos ext3.
Una vez que el kernel y la imagen initramfs se cargan en la memoria, el gestor de arranque pasa el control
del proceso de arranque al kernel.
Consulte el Manua/ de insta/acin de Red Hat Enterprise Linux especfico para estas plataformas para
obtener informacin sobre la configuracin de sus gestores de arranque.
El kernel
Cuando se carga el kernel, ste inicializa y configura la memoria del ordenador y los diferentes hardwares
conectados al sistema, incluyendo todos los procesadores, subsistemas de entrada/salida y dispositivos de
almacenamiento. A continuacin, busca la imagen comprimida de initramfs en una ubicacin
predeterminada en la memoria, la descomprime directamente a /sysroot/ y carga todos los controladores
necesarios. Seguidamente, inicializa los dispositivos virtuales relacionados con el sistema de ficheros, tal
como LVM o software RAID antes de completar los procesos initramfs y de liberar toda la memoria que la
imagen del disco ocup anteriormente.
40
El kernel luego crea un dispositivo root, monta la particin root como slo lectura y libera cualquier memoria
no utilizada.
Llegados a este punto, el kernel est cargado en la memoria y es operativo. Sin embargo, como no hay
aplicaciones de usuario que permitan la entrada significativa de datos al sistema, no se puede hacer mucho
ms.
Programa /sbin/init
El programa /sbin/init (tambin llamado init) coordina el resto del proceso de arranque y configura el
ambiente del usuario.
Cuando el comando init arranca, se vuelve el padre o abuelo de todos los procesos que comienzan
automticamente en el sistema. Primero, ejecuta el script /etc/rc.d/rc.sysinit, que establece la ruta del
entorno, activa el swap, verifica los sistemas de archivos y se encarga de todo lo que el sistema necesita
tener hecho al momento de la inicializacin.
Por ejemplo, la mayora de los sistemas usan un reloj, por lo tanto, el rc.sysinit lee el archivo de
configuracin para iniciar el hardware del reloj. Otro ejemplo es si hay procesos especiales en los puertos
seriales que deben ser inicializados, rc.sysinit ejecutar el archivo /etc/rc.serial.
El comando init luego ejecuta el script /etc/inittab, el cual describe cmo se debera configurar el sistema en
cada nivel de ejecucin SysV init. Los niveles de ejecucin son un estado, o modo, definido por los servicios
listados en el SysV directorio /etc/rc.d/rc<x>.d/, donde <x> es el nmero de nivel de ejecucin. Para ms
informacin sobre los niveles de ejecucin SysV init, consulte la Seccin 1.4.
A continuacin, el comando init configura la biblioteca de funciones fuente, /etc/rc.d/init.d/functions, para el
sistema, que establece el modo en cmo iniciar o matar un programa y cmo determinar el PID del
programa.
El programa init inicia todos los procesos de fondo buscando en el directorio apropiado rc para el nivel de
ejecucin especificado por defecto en /etc/inittab. Los directorios rc estn numerados para corresponder al
nivel de ejecucin que representan. Por ejemplo, /etc/rc.d/rc5.d/ es el directorio para el nivel de ejecucin 5.
Cuando se arranca el nivel de ejecucin 5, el programa init consulta el directorio /etc/rc.d/rc5.d/ para
determinar qu procesos iniciar o parar.
A continuacin un ejemplo de listado del directorio /etc/rc.d/rc5.d/:
41
Como puede ver, ninguno de los scripts que inician y cierran los servicios estn localizados en el directorio
/etc/rc.d/rc5.d/. Casi todos los ficheros en /etc/rc.d/rc5.d/ son enlaces simblicos apuntando a los scripts
localizados en el directorio /etc/rc.d/init.d/. Los enlaces simblicos se usan en cada uno de los directorios rc
de manera que los niveles de ejecucin puedan ser reconfigurados al crear, modificar y eliminar los enlaces
simblicos sin que afecten a los scripts actuales a los que se refiere.
El nombre de cada enlace simblico comienza con K o S. Los enlaces K son procesos eliminados en ese
nivel de ejecucin, mientras que aquellos que inician por S son procesos a iniciar.
El comando init, en primer lugar, detiene todos los enlaces simblicos de K en el directorio mediante la
ejecucin del comando /etc/rc.d/init.d/<command> stop, en el que <command> es el proceso a matar. A
continuacin inicia todos los enlaces simblicos S al ejecutar /etc/rc.d/init.d/<command>. start.
Cada uno de los enlaces simblicos se numera para dictaminar el orden de inicio. Usted puede variar el
orden en el que los servicios inician o paran al cambiar este nmero. Mientras ms bajo es el nmero, ms
rpido se arrancar. Los enlaces simblicos con el mismo nmero se inician de modo alfabtico.
Despus que el comando init ha progresado a travs del directorio adecuado rc para el nivel de ejecucin, el
script /etc/inittab bifurca un proceso /sbin/mingetty para cada consola virtual (prompt de inicio de sesin) del
nivel de ejecucin. Los niveles de ejecucin del 2 al 5 tienen seis consolas virtuales; mientras que el nivel de
ejecucin 1 (modo usuario nico) tiene tan slo uno, y lo niveles de ejecucin del 0 al 6 no tienen ninguno.
El proceso /sbin/mingetty abre las rutas de la comunicacin para los dispositivos tty, establece sus modos,
imprime el indicador de inicio de sesin, toma el nombre y contrasea del usuario, e inicia el proceso de
inicio de sesin. En el nivel de ejecucin 5, /etc/inittab ejecuta un script llamado /etc/X11/prefdm. El script
prefdm ejecuta su gestor de pantalla de X preferido gdm, kdm, o xdm, dependiendo de los contenidos del
archivo /etc/sysconfig/desktop. Una vez que haya terminado, el sistema operar en el nivel de ejecucin 5 y
mostrar la pantalla de inicio de sesin.
43