Tema 8: Procesos en Linux IES Serra Perenxisa 2009
Gestión de Procesos
Un programa ejecutable es leído del disco por el kernel y es cargado en memoria para ejecutarse, convirtiéndose en un proceso.
En un proceso no sólo hay una copia del programa, sino además el kernel le añade información adicional para poder manejarlo.
Un proceso se compone de tres bloques fundamentales:
segmento de texto
segmento de datos
pila
Espacio de Direcciones de un Proceso Unix
0xFFFFFFFF
kernel
kernel stack stack (dynamic allocated mem)
system segment (call system) $fp $sp
shared libraries address space
heap (dynamically allocated mem) un-initiated data (bss) read/write initiated data
0x0
only read initiated data code (text segment)
static data (data segment) $pc
Gestión de Procesos egmento S egmento
de texto: código de programa
egmento S egmento
de datos: variables globales y estáticas
Pila
Lo
crea el kernel y su tamaño es gestionado dinámicamente por el. Es una secuencia de bloques lógicos o stack frames Un stack frame se introduce o saca en función de si se llama o se vuelve de la llamada a una función. tack frame se compone de: S tack Las variables locales de función Parámetros de función Info. para volver al estado anterior de la llamada
Gestión de Procesos
Info. para volver al estado anterior de la llamada.
contador de programa puntero a pila al stack frame anterior
Los
procesos pueden ejecutarse en dos modos: usuario y kernel.
Cada modo maneja su propia pila o stack
stack del kernel: contiene los stack frames de las llamadas a sistema(funciones que se ejecutan en modo kernel) stack del usuario: stack frames de funciones que se ejecutan en modo usuario
Gestión de Procesos UNIX/ Linux
es un sistema multiproceso que permite la ejecución de varios procesos de forma simultánea
Requiere
de otro programa llamado ³Planificador o scheduler´ que permite gestionar que proceso entra a ejecutarse en cada instante en la CPU, ya que esta es un recurso limitado.
Todo
proceso nace cuando algún otro proceso ejecuta la llamada al sistema clone. Una de las muchas formas de llamar a clone es a través de la función fork.
clone
crea un duplicado idéntico del proceso que la ha llamado.
API de Unix para manejo de Procesos
Unix
proporciona un número de llamadas al sistema para creación y control de procesos, que incluye:
fork:
usado para crear un nuevo proceso (hijo).
exec: utilizado para cambiar el proceso actual por otro.
vfork: usado para crear un proceso nuevo, que comparte el espacio de
direcciones del padre.
clone(): llamada al sistema en Linux y es una forma genérica de fork() y pthread_create().
wait: esperar por el término de la ejecución de algún proceso hijo.
waitpid: usado para esperar el término de ejecución de un proceso proceso hijo
específico.
sleep:
suspende la ejecución de un proceso por un tiempo determinado.
kill:
abort: usado para terminar con la ejecución de un proceso en forma anormal.
getpid:
getppid:
getuid:
getpgrp:
usado para matar un proceso o enviar una señal. devuelve el pid del proceso. devuelve el pid del proceso padre.
devuelve el identificador de usuario. devuelve el identificador de grupo del proceso.
Gestión de Procesos:clone
Nuestro nuevo proceso no verá el espacio de direcciones del proceso padre, ni viceversa.
Con mucha frecuencia, después del clone el proceso llama a exec para lanzar un programa nuevo.
La llamada a exec carga un programa en el espacio de direcciones del proceso y le pasa el control, perdiéndose el proceso llamante.
Si un proceso quiere lanzar un programa sin desaparecer, lo que hace es llamar a clone y que el hijo llame a exec (servicios).
Gestión de Procesos:fork ork: F ork:
Crea un proceso hijo. Devuelve 0 al proceso hijo y el PID del hijo al proceso padre. El proceso hijo creado es una copia exacta del padre, excepto que recibe un valor diferente de la llamada fork. Devuelve un valor -1 en caso de no poder crearse el proceso hijo. ret=fork() i f (ret==-1) {pr in intf(³ERROR´);}
else i f (ret==0) {pr in intf(³HIJO´);} else pr in intf(³PADRE´)
Gestión de Procesos:fork Todos los procesos tienen un único padre, pero un padre puede tener múltiples hijos.
Existe un proceso especial cuyo PID es 0, este se crea al arrancar el sistema y después de hacer una llamada fork se convierte en el proceso intercambiador (swapper), el proceso hijo se llama init y su PID vale 1. Este se encarga de arrancar los demás procesos que requiere el sistema.
Usando fork() crear (duplicar) un proceso #include #include #include #include void main(void) { pid_t pid; int i; int n = 10; for (i = 0; i < n; i++) { pid = fork(); if ( pid != 0 ) { printf("\n\n*********************** ITERACION %d **************\n",i); printf("Recien creado: %d\n",pid); printf("Creado por: %d\n",getpid()); printf("*****************************************\n"); break; Código que ejecuta } el proceso hijo } printf("\n\n-------------------------FINAL DEL B UCLE -------------------------\n"); printf("Finalizando bucle de: %d\n",getpid()); printf("....padre = %d\n", getppid()); }
Gestión de Procesos:PID
Cuando un proceso muere libera su pid y se puede asignar a cualquier nuevo proceso.
En Linux 2.6 el PID se almacena en un entero y permite teoricamente hasta 2147483647(int 32bits=2^(31) +bit signo) procesos. cat /proc/sys/kernel/pid_max ->32768 (por defecto) echo 10000001 > /proc/sys/kernel/pid_max (hasta 1 Millón)
Con frecuencia se llega antes a la limitación de cota de descriptores, ya que cada proceso consume al menos 3 descriptores (E S E) S, SS , S E) cat /proc/sys/fs/file-max ->101815(por defecto)
Gestión de Procesos:estados
El tiempo de vida de un proceso se puede dividir en un conjunto de estados.
En un sistema monoprocesador un proceso no esta continuamente ejecutándose, su estado irá cambiando según unas reglas bién definidas.
En el siguiente gráfico veremos cual es la transición de procesos en UNIX/ Linux y procederemos a su explicación:
Gestión de Procesos:estados 1.-Ejecutánd ose ose en mod o usuar i i o: o: t i i ene el control d el el procesad or or mi entras d ura ura el quanto o no real i i ce ce una llamad a al si stema. stema. iz a 2.-Ejecutánd ose ose en mod o ker nel: Cuand o el proceso real iz una llamad a a si stema, stema, el proceso cambi a d e estad o y pasa ejecutar códig o d e área d e ker nel. Cuand o termina: T erm ermina
la tarea interrupc i i ón ( i iret) r et) vuelve a la s ig ui ente instrucc i ió n que la llamó.
Si termina el quanto se hace un cambi o d e contexto, pasand o el sig ui ente proceso a mo d o usuar i i o
Si carece d e al gún ormid o gún recurso->Estad o d orm
Si termina con ex i i t->Esta t->Estad o z omb ombi
Gestión de Procesos:estados 3.-Plani f fi i ca cad o
en memor i i a: a: t i ie ne reservad o los recursos d e si stema stema que necesi ta. ta. El proceso no se esta ejecuta nd o, o, esta en cola d e "l i isto s to para ejecutarse" espera nd o a que el plani f fi i ca cad or or d e tareas(sched uler) uler) se lo permi ta. ta. 4.-Dormid o en memor i i a: a: El proceso esta d urm urmi end o car g ga d o en memor i i a, a, ya que esta espera nd o que se complete u na operac i ió n (E/S,t i i empo empo d e espera(t i i mer)(ejm:sleep mer)(ejm:sleep 10),espera d e rec i i bi r un evento o mensaje) N ota: ota: N o
pued e haber un proceso, ejecutánd ose ose en mod o usuar i i o y ker nel a la vez .
Gestión de Procesos:estados 5 .-Pla .-Plani f fi i ca cad o
en swap: Esta en memor i i a secund ar ar i i a,l a,l i i sto sto para ejecutarse, pero el intercambi ad or or (proceso 0 ó swapper) d ebe ebe g ar car g ar el proceso en memor i i a antes d e que el plani f fi i ca cad or(sche or(sched uler) uler) pued a or d de nar que pase a ejecutarse. 6.-Dormid o en swap: El proceso esta d urm urmi end o y el or ha d escar escar g intercambi ad or g ad o el proceso hac i ia una memor i i a inc pal i i d ond e secund ar ar i ia para d ejar ejar espac i i o en la memor i i a pr in g ar pod er er car g ar otros procesos. 7.-El proceso esta volv i i end o d el el mod o superusuar i i o al mod o usuar i i o, o, pero el pla ni f fi i ca cad or or se apropi a d el el proceso y hace un cambi o d e contexto, pasand o otro proceso a ejecutarse e n mod o usuar i i o. o.
Gestión de Procesos:estados 8 .-El .-El
proceso acaba d e ser cread o(co o(con fork) y está en un estad o d e transi c c i ió n; el proceso ex i iste, s te, pero ni está preparad o para ejecutarse, ni urmi end o. o. Este estad o es el ini c c i i al al para ni d d urm tod os os los procesos, excepto el proceso 0. 9.-El proceso ejecuta la llama d a ex i it y pasa al estad o z omb ombi . El proceso l i i bera bera tod os os los recursos pero ma nt i i ene la entrad a en la T abla abla d e Procesos. N o termina d e mor i ir, r , esperand o la fi i cac cac i ió n por parte d el el pad re, re, d e que ha reco gid o el regi stro stro not i i f que cont i ie ne el códig o d e sal id o. Es un estad o id a y su estad o. temporal. E n caso d e que el proceso pa d re re muera antes d e que f in ce el h jo, inal i i ce i será el proceso ini t quién asuma su pater nid nid ad .
Gestión de Procesos: estados 1- Par Para a ver ver un proceso en ejecuc i i ón, bastaría con ejecutar ps ±aux y local iz ar en la sal id el comand o el proceso ³ps´, que d ebería ebería estar en iz ar id a d el ejecuc i i ón. 2- Si compi lamos lamos ³running .c´ .c´ con la or d c c ±o running running .c´ .c´ y de n ³ g gcc ejecutamos el prog rama rama ³./running ´ también veremos un proceso en ejecuc i i ón cont in a. inuad a. 3-Con
el prog rama rama ³wai t ting .c´ que t i i ene un g etchar(), etchar(), el prog rama rama i ng .c´ si mpleme mplemente espera una entrad a y está Sleeping . Si se le intenta env i i ar ar a seg und o plano ³./wai t ting stema nos informa que el proceso pasa a i ng &´ el si stema T ´ (stopped estad o ³ T ) por que en seg und o plano no pued e rec i i bi r r nad a por st din din.
Gestión de Procesos: estados 4-´ej_fork.c´ : El pad re re trabaja mi entras que el h jo i acaba. Esto resulta en: Pad re re con estad o ³R´ e h jo efunct> i con estad o ³Z´
Si hacemos k i i llll -9 pad re, re, el h jo i muere también
Gestión de Procesos: ciclo de vida La vida de un proceso comi enz a con la llamada al sistema d e fork , d es esd e el shell por ejemplo co n ./a.out : 1.-Con la llamad a a fork se crea el proceso, pr oceso, ini c c i iá nd ose ose la información de contexto y asignand o un PID al proceso hijo a.out. S u proceso padre será el "shell".( Un proceso no se rama, falta d e memor i i a, a, se crea si: no puede encontrar el prog rama, ha sobrepasad o el número d e procesos que se pue d e crear...) 2.-El proceso pasa a estad o "listo para ejecutarse" .
Gestión de Procesos: ciclo de vida 3.-Ex i i ste ste
una func i i ón "scheduler" o "planificador" que en ga d e seleccionar a un func i ió n d e la polít i i ca ca , se encar g proceso d e la l i i sta sta d e "l i i sto sto para ejecutarse". 4.-U n vez selecc i i onad o el proceso a ejecutarse por el "plani f fi i ca cad or", or", se llama a la fu nc i ió n "dispatcher" que se encar g cho proceso, g a d e pasar a estado de ejecución a di cho restaurand o su informac i i ón d e contexto.
5 .-E .-E n
Gestión de Procesos: ciclo de vida
ejecuc i i ón se pasa d e modo usuario a modo supervisor a trav és d e una llamada a sistema o interrupción (cad a vez que se necesi ta ta ejecutar al g el si stema stema gu na rut in ina d el operat i ivo v o tal como una operac i i ón d e E/S para escr i i bi r un mensaje en pantalla...). E n modo usuario, se ver i i f fi i ca c a la z ona d e memor i ia a la que se acce d e, e, no sobrepase su área de programa de usuario ( z zo na d atos atos e instrucc i io nes) y no virus ). U na vez modi f fi i ca c a el área d el el Si stema stema Operat i i vo( vo( virus inal iz iz ad a la ejecuc i i ón d e la rut in ina d e E/S, el S.O d evuelve f in evuelve el control al prog rama rama d e usuar i io, o , pasand o a mod o usuar i i o. o. pr in tf(³ejemplo´)) (mod o ususar i i o)->llama o)->llamad a a si stema stema intf(³ejemplo´ wr i ite(mo t e(mod o ker nel)
Gestión de Procesos: ciclo de vida g una operación de 6.-E n caso de espera d e un proceso por al g E/ S i ntervalo d e S , por un evento d e otro proceso, o u n timer ( (in planificador envía al proceso a ³ estado estado t i i empo), empo), el planificador fi i ca cad or or selecc i i ona el sig ui ente durmiendo´. Para lo cual el pla ni f proceso a ejecutar y el di spatcher spatcher lo pasa a esta d o d e ejecuc i i ón. U na vez que la raz ón por el que un proceso esta " d urmi end o" o" f in ce el plani f fi i ca cad or or pasa a estad o "listo de d urm inal i i ce ejecución".
7.-Los procesos t i i enen un quanto d e t i i empo empo d e ejecuc i i ón para el uso equi tat tat i i vo vo d e la CPU. Sabi end o que los procesos más pr i i or or i itar t ar i i os os tend rá rán mayor número d e quantos.
8 .-E .-E n
Gestión de Procesos: ciclo de vida
caso d e que la memoria esté saturada y haya necesid ad d d d e car g gar r un prog rama a rama más pr i i or or i i tar tar i i o en memor i ia, a , pas asar ar un da d e p el swapper o intercambiador se encar d uar d proceso menos prioritario a memoria secundaria g uar da nd o la informac i i ón necesar i ia para volverlo a car g a a , y gar r en memor i ia, una vez f in inal iz iz ad o la ejecuc i i ón d e un proceso, d e pasarlo a memor i i a. a. Este transi eg o d e memor i i a a di sco sco y di sco sco a memor i i a se le d enomina "swapping d e procesos". 9.-U n proceso pued e acabar su ejecuc i i ón si :
llamad a al si stema stema d e f in rama: exit in _prog rama:
Otro proceso le ma nd a un S EÑA PID EÑAL de S IGKI IGKI LL LL: k i illl l -9 nº PID
Gestión de Procesos: ciclo de vida E n ambos casos pasa a esta d o z ombi ombi . El proceso ya no ex i iste s te pero d eja eja para su proceso pa d re re un registro ( código código de empo d e salida y algunos datos estadíticos tales como t i i empo ejecuc i i ón )
Para que un proceso pued a matar a otro es necesar i i o que teng a pr i iv v i i le legi os, os, un proceso pad re re pued e matar a sus i procesos h jos.
Gestión de Procesos: ciclo de vida iz and o Los procesos se comuni ca can habi tualme tualmente real iz i llamad as as a si stema stema d e "esperar_h jo", que perm i te te al proceso inal iz iz ac i y obtener la pad re re sincroniz arse arse con la f in ac i ió n d e sus h jos informac i ió n d e cómo han acabad o los h jos i por me di o d e al gún gún t po i i d e códig o d e retor no.
ret=fork() i f (ret==-1) {pr in intf(³ERROR´);}
else i f (ret==0) {pr in intf(³HIJO´);} else {wai t(&esta t(&estad o);pr o);pr in intf(³PADRE´)}
Gestión de Procesos: Tabla de Procesos El si stema stema operat i i vo vo mant i i ene una tabla d e procesos, d entro d e la cual se almacena un Bloque d e Control d e Proceso o PCB (Process Co ntrol Block). U n PCB t i i ene los sig ui entes campos:
I nformac i i ón d e id ent i i f f i i cac cac i i ón:
PID(Process IDent i i f fi i er) er) y PPID(Parent d ent i i f i Process I d fi i er) er) para relac i i ones pad re-h re-h jo. d ent i i f d ent i i f UID (User I d fi i er) er) y GID (Group I d fi i er) er) :d eterm etermina los pr i i v v i i le legi os os d el el proceso
Gestión de Procesos: Tabla de Procesos
I nformac i ió n d e control para g est est i i onar el proceso:
Plani f fi i cac cac i ió n y estad o: o: o: Estad o: T NN I N ASK_RU NN IN G(ejecutá G(ejecutánd ose ose o preparad o) o) T NT ERRUP TIBLE( dorm rmid o, ASK_I NT ERRUP T I BLE( d o o, pero ad mi te te cualqui er er señal) T N I N T IBLE ASK_U N INT T ERRUP ERRUP T IBLE ( d orm ormid o, o, pero sólo respond e a la señal que espera) T ASK_ST OPPED( OPPED( stopped o traced ) T ASK_ZOMBIE(esperand o un wai t() t() ) Evento por el que espera s i esta bloquea d o
Gestión de Procesos: Tabla de Procesos
I nformac i ió n d e control para g est est i i onar el proceso:
Plani f fi i cac cac i ió n y estad o: o: empor iz ores que contabi l l iz empo d e iz ad ores iz an el t i i empo T empor CPU ut i i l l iz iz ad o en mod o ker nel y mod o usuar i i o Descr pc mentos d e memor i ia asignad os os i i i i ón d e los seg me al proceso. Estad o d el el procesad or: or: valor d e los regi stros stros d e la cpu
Gestión de Procesos: Tabla de Procesos
Punteros para estructurar los procesos e n colas. Para que el plani f fi i ca c ad or or las g est est i io ne. Comuni cac cac i i ón entre procesos:
Descr ptores espertarán al i i d e eventos: Qué eventos d espertará proceso. Campo d e señales: enumera las señales rec i i bid as as pero to d avía avía no tratad as. as.
Gestión de Procesos: Cambio de Contexto Cuand o se esta ejecutand o un proceso, se di ce ce que el si stema stema se esta ejecutá nd o en el contexto d e un proceso.
Se d enomina cambio de contexto a la acción de cargar el procesador con el contexto del proceso que pasa a ocupar la CPU, salvando previamente el contexto del proceso que abandona la CPU en su PCB.
Gestión de Procesos: Cambio de Contexto
Se provoca un cambi o d e contexto cuand o: o:
f in in quanto
f in inal iz iz a el proceso
operac i ió n d e sincroniz ac ac i ió n-teng a que esperar
id a) llamad a al si stema stema (operac i ió n d e entrad a/sal a/sal id a) medi ante el mecani smo smo trap ( in interrupc i ió n software) que d a bloquea d o a la espera d e f in ar la operac i i ón. inal iz iz ar
w esbloquee u n proceso más interrupc i i ón har d dware are que d esbloquee pr i ior o r i itar t ar i io. o . la lleg ad a d e un proceso más pr i i or or i i tar tar i i o
Gestión de Procesos: Planificador de Procesos:Unix,tradicional Los PCBs estarán or d os en la colas d e preparad os os d e d enad os acuer d ca d e plani f fi i cac cac i i ón ut i i l l iz a. d o a la polít i i ca iz ad a.
ga d e d ec idi r a quién d ará El plani f fi i ca c ad or or se encar g ec idi ará la tajad a (sl i ice c e o quanto) d e t i i empo. empo.
n x i se ut i i l iz a el al g gor r i i tmo E n U ni l iz o tmo d e plani f fi i cac cac i i ón que se d enomina Round Robin Multinivel con Prioridades Dinámicas.
Gestión de Procesos: Planificador de Procesos:Unix,tradicional
1º aproximación: Algoritmo Round-Robin
Cola FIFO d e procesos pla ni f f i ica c ad os os ig uo Func i io nami ento: Se cog e el proceso más a nt ig uo y una vez ejecutad o su quanto, vuelve a introd uc uc i irse r se en la cola. gor r i itmo Ventaja: Es un al g o t mo justo. Desventaja: los procesos co n mayor pr i ior o r id id ad se ejecutará n con la mi sma sma frecuenc i ia que los me nos pr i ior o r i itar t ar i i os os
Gestión de Procesos: Planificador de Procesos:Unix,tradicional
2º aproximación: Algoritmo Round-Robin Multinivel Di fere ferentes colas FIFO, cad a una para procesos d e la mi sma sma pr i ior o r id id ad . uo d e la cola Func i io nami ento: Se cog e el proceso más a nt ig ig uo o r id o r id d e mayor pr i ior id ad . Sólo s i la cola d e mayor pr i ior id ad esta vacía pasamos a la d e sig ui ente menor pr i ior o r id id ad . m stemas d e t i iempo e mpo real Ventaja: Ópt i imo o para s i stemas Desventaja: N o justo, pue d e haber procesos que jamás se ejecuten.
Gestión de Procesos: Planificador: Unix tradicional 3º aproximación: Algoritmo Round-Robin Multinivel con Prioridades Dinámicas
Di fere ferentes colas FIFO, cad a una para procesos d e la mi sma sma pr i ior o r id id ad . La pr i ior o r id id ad t i ie ne un componente estát i ico( c o( ni ni ce ce d e 19 a -20) y otro dinámi co co (según el proceso va ejecuta nd o sl i ices, c es, r id id ad dinámi ca no emplea el su pr i ior o ca va cayend o, o, y si i n procesa d or or su pr i ior o r id id ad dinámi ca ca sube). Func i io nami ento: Por cad a segundo d e t i iempo e mpo se recalcula n r id id ad es las pr i ior o es y se reajusta n las colas. Se cog e el proceso más ant ig ig uo uo d e la cola d e mayor pr i ior o r id id ad . Sólo si la cola d e mayor pr i ior o r id id ad esta vacía pasamos a la s ig ui ente menor r id id ad . pr i ior o
Ventaja: Es justo
Desventaja: El t i iempo e mpo recalcula nd o las pr i ior o r id id ad es es dinámi cas cas
Gestión de Procesos: Planificador:Unix,tradicional 3º aproximación: Algoritmo Round-Robin Multinivel con Prioridades Dinámicas
Los procesos t i ie nen pr i ior o r id id ad es. es.
r id id ad es. Ex i iste s te una cola para ca d a una d e la pr i ior o es.
nd e pr i imero ero a los procesos d e la cola -32, en caso d e Se at i ie m estar vacía se pasa al s ig ui ente ni vel vel hasta lleg ar ar a 31.
E n caso d e no haber procesos pla ni f fi i ca c ad os, os, se ejecuta el proceso idle Prioridad Total=Prioridad Base + (uso de cpu/2) + Valor Nice Prioridad Total se calcula ca d a seg und o
La Prioridad Base será un valor neg at at i ivo, v o, si proceso se ejecuta en mod o ker nel y posi t ti i vo v o s i mod o usuar i io, o , y d epe epend e d e la pr i ior r id id ad d el o el pad re. re.
Gestión de Procesos: Planificador:Unix,tradicional 3º aproximación: Algoritmo Round-Robin Multinivel con Prioridades Dinámicas.
El Valor Nice:
Es un valor comprendid o entre -20 a 19. Por d efecto efecto es 0. U n usuar i io normal úni came camente pued e bajar la pr i ior o r id id ad d e su proceso ejecutá nd olo: olo: ni ce ce -n 19 yes>/ d dev/ e v/ null & [1] 25 46 46 id ad d e un U n superusuar i i o pued e aumantar/red uc uc i ir la pr i ior o r id proceso: Cuand o va a ejecutar 1 º vez : ni ce ce -n -20 yes>/ d dev/ e v/ null & ió n: re ni ce U na vez en ejecuc i ce -20 25 46 46
Ordenes relativas a procesos: ps
Lista los procesos activos en el sistema
Examinar las opciones en el manual (castellano):
a: información de los procesos de todos los usuarios e: variables de entorno u: muestra los procesos de un solo usuario r: sólo procesos en ejecución x: todos los procesos del sistema l: salida larga
Ejemplos: ps ±aux, ps -edaf
Ordenes relativas a procesos: ps
Campos de salida: UID
(id. de usuario), PID (id. de proceso), PPID (padre), %CPU (índice de uso del procesador), START (hora de inicio), TTY (terminal en la que se ejecuta el proceso), TIME (tiempo acumulado de CPU consumido por el proceso) PRI (prioridad de ejecución, dinámica, a menor nº mayor prioridad) NI(Valor del NICE) SIZE (tamaño en bloques) RSS (tamaño en Kb del programa en memoria) STAT (Estado del proceso): D:Durmiendo D:Durm iendo ininterrumpiblemente R:En ejecución en ese momento S:Durmiendo Z:Zombie T:Parado W: Swapped out (sin páginas residentes) N:Nice positivo
Ordenes relativas a procesos: ps/top
gcc ±o running running.c
cp running running1 (dos copias del ejecutable)
./running &
jobs
ps ±edaf
+
./running1&
Top
S (intervalo) : 0.5 / 1
R (renice) -20 running (máxima prioridad)
R (renice) -5 running1
K (kill)
U (user)
Al hacer el renice el proceso con el número más negativo, consume más CPU y su tiempo de ejecución crece. Los dos procesos colapsan el 99% de uso de la CPU. El ratón ratón va va lento.
Ordenes de procesos: nice & renice
Nice ±n comando : fija el valor de nice para la ejecución de un cierto proceso
Valores válidos de -20 a 19
Los usuarios sólo pueden bajar la prioridad
El root puede subir la prioridad a un proceso.
Ejemplo: lanzar los dos running y running1 con nice diferente y con el comando top visualizar lo que ocurre.
Renice ±n PID: Modifica la prioridad a un proceso ya en ejecución Ejemplo: invertir la ejecución de running y running1, runnin g1, para que el menos prioritario pase a ser más prioritario (y consuma más CPU).
Ordenes de procesos: sleep, wait, nohup
Sleep tiempo (segundos): Demora durante un cierto tiempo el inicio de una orden o genera una espera durante la ejecución (sleep 3600; who >> registro) &
Wait: cuando en programación shell, nos interesa esperar a que acaben los procesos en background (&) antes de ejecutar la siguiente orden:
Orden1 > archivo1 &
Orden2 > archivo2 &
Wait
Sort archivo1 archivo2
Nohup: Cuando un proceso muere, todos sus subordinados ±si los hubieramueren también. Al finalizar una sesión (login, konsole) también. también. Con nohup, un comando seguirá en ejecución a pesar de que el usuario que lo lanza se haya desconectado. Es interesante redirigir las salidas para capturarlas:
Nohup orden > salida 2>errores &
Ordenes de procesos: kill y señales
Kill: envía señales a procesos
Kill ±nº_de_señal PID
Un
usuario puede eliminar cualquier proceso suyo
El root puede eliminar cualquier proceso
Las señales son sucesos externos a los procesos que tienen un número asociado.
Por defecto se ejecuta la señal 15 SIGTERM (finalización software)
La señal nº 9 SIGKILL provoca la terminación incondicional e inmediata del proceso
Kill -9 PID
Ejemplo: Desde konsole arrancar varios varios programas y finalizarlos con kill y/o con xkill.
Ordenes de procesos: señales
Las señales son mecanismos de comunicación asíncrona de procesos (interrupciones software que pueden ser enviadas a un proceso para informarle de alguna situación especial) Permiten al proceso reaccionar a los eventos provocado provocadoss por ellos mismos o por otros procesos. procesos. Puede generarse generarse de diversas diversas maneras:
Excepción Hardware (acceso a página de memoria no asignada= SIGSEGV)
CTRL+C (SIGINT) del usuario
Llamada a kill (envía esa señal a un proceso)
Evento gestionado por el núcleo)
Cuando un proceso recibe una señal hay 3 acciones predeterminadas:
Ignorar la señal Invocar una rutina de tratamiento standard (por lo general provocan la terminación del proceso y generan un core) Invocar una rutina propia (modificada por el proceso)
Procesos: señales de terminación de procesos Núm. Nombre Descripción 1
SIGHUP
Terminación del proceso, desconexión
2
SIGINT
CTRL+C por teclado
3
SIGQUIT
Terminación con core
6
SIGABRT
Terminación anormal
9
SIGKILL
Terminación no n o evitable
15
SIGTERM
Terminación emitida por kill
Procesos: señales de excepción hardware Núm. Nombre Descripción 4
SIGILL
Instrucción ilegal
5
SIGTRAP
Punto de parada en programa
8
SIGFPE
Floating Point Exception
11
SIGSEGV
Dirección de memoria no válida
Procesos: señales de suspensión o seguimiento en la ejecución de procesos Núm. Nombre Descripción 17
SIGCHLD
Terminación de un hijo
18
SIGCONT
El proceso se lleva a primer o segundo plano
19
SIGSTOP
Suspensión de proceso
20
SIGTSTP
Emisión de CTRL+Z
Procesos: señales de gestión de alarmas, SAI, entradas/salidas Núm. Nombre Descripción 24
SIGXCPU
Límite de CPU (tiempo) sobrepasado
2
SIGALRM
Fin del tiempo de un ti timer mer
SIGPWR
Fallo de alimentación
SIGUR G
Datos urgentes para los sockets
23
Procesos: Control de trabajos (bg, fg, jobs, CTRL+Z) 1-Desde
un terminal en X lanzamos un proceso (mozilla)
2-El terminal queda bloqueado 3-Con CTRL+Z paramos el proceso 4-Con ps vemos que el proceso esta sTopped 5-Con ³jobs´ vemos la lista de tareas de esa terminal 6-Con bg lo mandamos a segundo plano 7-Con fg + nº de trabajo lo traemos a primer plano de nuevo (bloqueamos terminal)
