Administració de processos del sistema

Tot programari executable, inclòs el mateix sistema operatiu, s’acaba constituint en una sèrie d’unitats anomenades processos que s’organitzen, ordenen i consumeixen recursos, per acabar sent executats pel processador. L’administració d’aquests processos i dels seus recursos associats constitueix una de les tasques bàsiques i primordials del nucli del sistema operatiu que, entre d’altres, comprendrà funcions com ara:

  • La creació i destrucció de processos
  • El despatx (dispatcher), és a dir, l’assignació de processos a execució en el processador
  • Els canvis d’estat que anomenem transicions
  • La suspensió i represa de processos
  • La sincronització de processos
  • La comunicació entre processos
  • La manipulació de blocs de control de procés (PCB)
    Moltes d’aquestes activitats estan només en mans del sistema operatiu i seran transparents per a l’usuari, però cal conèixer bé els mecanismes de l’administració de processos, ja que l’usuari pot intervenir en aspectes crucials com ara la configuració de l’arrencada del sistema, l’assignació de prioritats o la finalitzant, suspensió i represa d’aquests processos.

Conceptes bàsics sobre processos

Un procés és la instància d’un programa en execució que necessita per realitzar la seva tasca recursos com ara:

  • Temps de processador
  • Memòria
  • Arxius
  • Dispositius d’entrada/sortida

Aquests recursos es poden assignar en el moment de la creació del procés o bé durant la seva execució.

Des de aquesta perspectiva, un procés es pot considerar unes línies de codi carregades a memòria i un context associat constituït per l’activitat del processador en un moment determinat, és a dir:

  • El valor del comptador del programa
  • El contingut dels registres del processador

i per una sèrie de dades emmagatzemades a la memòria:

  • Variables globals i memòria dinàmica
  • Dades temporals a la pila (stack) com adreces de retorn i variables locals

Conceptes d'aplicació, procés i servei

Es considera generalment una aplicació informàtica com un programa dissenyat per interaccionar amb l’usuari, per tant s’executa en primer pla (foreground) amb una determinada interfície d’usuari. Són exemples típics d’aplicacions els programes d’ofimàtica, els navegadors, els reproductors multimèdia, etc.

En canvi, un servei és un terme que correspon al concepte i funcionalitat del dimoni (daemon) en la terminologia de Linux. Anomenem servei a un programa normalment associat al sistema operatiu, encara que també es pot engegar de forma manual, i que treballa en segon pla (background) sense interfície d’usuari, donant suport a altres programes. Els serveis proporcionen prestacions com serveis de pàgines web, registre d’esdeveniments, serveis d’impressió, criptografia…

El concepte de procés, en canvi, té més a veure amb el funcionament intern del sistema operatiu i consisteix en una sèrie d’instruccions allotjades a la memòria que, mitjançant cues i un mecanisme de planificació, accedeixen a la CPU per executar-se. Així, doncs, quan s’engega qualsevol aplicació o servei genera un o més processos en el sistema.

Tipus de processos i classificació

Podem fer algunes classificacions dels processos en funció del seu propietari, el seu comportament en concurrència, la forma d’execució i ubicació a la memòria o els recursos del sistema que comparteixin.

Segons del propietari del procés tenim:

  • Processos de sistema: Associats al funcionament del nucli del sistema o dels diferents serveis en funcionament (dimonis). Molts d’aquests processos estan associats a usuaris virtuals del sistema (lp, www, mail, etc.).
  • Processos de superusuari: Associats al compte de l’administrador arrel (root).
  • Processos d’usuari: Associats a l’execució d’aplicacions d’un usuari determinat.

També podem classificar els processos que s’executen concurrentment com a:

  • Independents: No afecten ni són afectats per altres processos.
  • Cooperants: Poden compartir dades i per tant afectar i ser afectats per altres processos.

Segons la forma d’execució i ubicació a la memòria poden ser:

  • Residents: Els processos residents són sempre a la memòria mentre dura l’execució.
  • Intercanviables: Poden ser portats de la memòria principal al disc dur mentre estan bloquejats. Així, la memòria alliberada pot ser utilitzada per altres processos que la necessitin.

Finalment segons els recursos que comparteixen trobem processos:

  • Pesants: Els processos pesants són independents i tenen tots els seus propis recursos.
  • Lleugers: També anomenats fils d’execució o threads, comparteixen entre si espai de memòria i recursos d’entrada i sortida.

Planificació de processos

Tal com hem avançat, una de les obligacions d’un sistema operatiu com a gestor de processos és la planificació de processos: l’execució de múltiples processos optimitzant l’ús del processador.

Així, doncs, les polítiques de planificació de processos sorgeixen com a necessitat d’acomplir dos dels principals objectius funcionals dels sistema operatiu: la multiprogramació i el temps compartit:

  • Multiprogramació: Té com a objectiu maximitzar l’aprofitament de la CPU tenint sempre en execució algun procés en tot moment.
  • Temps compartit: Atès que una CPU només pot realitzar un procés alhora es tracta d’establir un sistema de commutació de la CPU entre els processos amb tal freqüència que l’usuari pugui interactuar-hi i tingui la impressió que s’estan executant en paral·lel.

La planificació de processos es desenvolupa a tres nivells: llarg, mig i curt termini.

Planificació a llarg termini

El planificador a llarg termini és l’encarregat de crear els processos determinant quins treballs s’admeten en el sistema per al seu processament i carregant-los en la memòria disponible. Els sistemes operatius de temps compartit gairebé no tenen algorisme de planificació a llarg termini i es limiten a crear i posar en estat “preparat” qualsevol procés nou. En canvi, té més sentit la planificació a llarg termini en sistemes que admeten processament en lots, ja que és convenient compensar tasques que demanin més temps de processador amb tasques que demanin més operacions d’entrada i sortida, per equilibrar així els recursos del sistema.

Planificació a mig termini

La planificació a mig termini regula el grau de multiprogramació fixat en un principi pel planificador a llarg termini. Si el sistema no té prou recursos, en especial de memòria, per atendre tots els processos en marxa, es poden passar alguns d’ells a l’estat de suspesos i alliberar així recursos i memòria interna.

Grau de multiprogramació

Correspon al nombre de processos actius en un moment determinat, que estan carregats a la memòria principal del sistema.

Per fer això és fa servir la tècnica de l’intercanvi (swapping, en anglès), que s’encarrega de suspendre processos enviant-los a memòria secundària, habitualment el disc dur (swap out), i reactivant-les posteriorment, tornant-los a carregar de la memòria secundària a la memòria interna (swap in).

Planificació a curt termini

El planificador a curt termini o dispatcher té la tasca essencial de decidir quin procés passa a execució d’entre els que estan a la cua dels processos preparats (ready). Per fer aquesta tasca, els planificadors a curt termini implementen una sèrie d’algorismes que tenen com a objectiu optimitzar l’eficiència, la productivitat i el temps de resposta de la CPU.

Aquests algorismes de planificació es poden classificar en algorismes apropiatius i no apropiatius, i també hem de considerar altres tècniques combinades, com ara les cues multinivell.

Algorismes no apropiatius

El sistema operatiu no expulsa mai el procés de la CPU fins que aquest acaba l’execució o en surt voluntàriament, per exemple, quan el procés passa a bloquejat a l’inici d’una operació d’entrada/sortida. Exemples d’aquests tipus d’algorisme poden ser:

Cues FIFO i LIFO

En una cua FIFO (first input first output) els elements de la cua surten en el mateix ordre que han entrat, mentre que en una cua LIFO (last input first output), també anomenada pila o stack, és el darrer element arribat el primer que surt de la cua.

  • FCFS (first come first served). És una cua FIFO que dóna preferència segons l’ordre d’arribada a la cua.
  • SJF (shortest job first). Algorisme no apropiatiu on la prioritat d’accés a l’execució depèn del temps de ràfega de CPU necessari. Així, es beneficien aquells processos més curts d’executar i es maximitza el nombre de processos executats per unitat de temps.
Algorismes apropiatius

El sistema operatiu pot decidir expulsar un procés de la CPU i executar-ne un altre. Alguns exemples d’aquest tipus d’algorisme:

  • Round Robin: Algorisme de roda en el qual el sistema operatiu assigna un temps determinat a cada procés. Aquest temps, anomenat quàntum, pot ser constant o calcular-se dinàmicament. El procés abandona la CPU quan esgota el seu quàntum. L’elecció del valor del quàntum és molt important, ja que un quàntum molt petit produeix massa canvis de context.
  • SRT (shortest remaining time): Algorisme depenent del temps de ràfega com l’SJF, però en aquest cas és apropiatiu. És a dir, si arriba un nou procés a la cua de preparats i el seu temps d’execució és menor que el que li resta al que s’està executant en aquell moment, es pot apropiar de la CPU i expulsar-lo.
Cues multinivell

Consisteixen en diferents cues de processos en estat de preparats. Cada cua té la seva prioritat. Per accedir a l’execució en el processador s’escull el procés de la cua més prioritària que no estigui buida. Dins de cada cua es pot aplicar una política i un algorisme de planificació diferent.

Cues multinivell realimentades

És el mateix cas de les cues multinivell, però els processos poden avançar i retrocedir per les diferents cues de prioritats. Per exemple, un procés de prioritat alta que exhaureixi el seu quàntum podria passar a una cua de preparats de menys prioritat.

El sistema operatiu Unix/Linux fa servir cues multinivell realimentades utilitzen l’algorisme Round Robin a cada cua. Cada segon es recalculen les prioritats dels processos en funció d’unes prioritats dinàmiques i d’unes de fixes, definides d’una banda pel sistema, segons el tipus de procés, i de l’altra pel mateix usuari mitjançant la configuració de la prioritat nice.

A la figura veiem esquemàticament la intervenció dels diferents nivells de planificació en la creació de processos, la regulació del nivell de multiprogramació mitjançant l’intercanvi amb el disc dur i finalment l’assignació òptima dels processos preparats per ser executats en el processador.

Figura Esquema del sistema de planificació de processos

Estats i transicions dels processos

Una característica fonamental d’un procés és l’estat en el qual es troba, que ve definit per la seva incorporació dins de les diferents cues que organitzen la gestió del processador. Una primera aproximació ens dóna fins a cinc estats diferents possibles per a un procés, encara que la incorporació del sistema d’intercanvi (swapping) ens aportarà dos possibles estats addicionals.

Estats d'un procés

Els cinc estats bàsics d’un procés són els següents:

Procés zombi

Podem considerar-ho com una variant de l’estat finalitzat. És un procés que ha finalitzat i ja no fa sevir la CPU, però que ha de mantenir en memòria certa informació d’utilitat per al seu procés pare. A Linux, els processos finalitzats passen directament a estat zombi fins que el procés pare se n’assabenta i els esborra definitivament.

  • Nou (new): El procés s’està creant.
  • Preparat (ready): El procés està a la cua, preparat per a l’assignació d’un processador.
  • En execució (running): Les instruccions del procés estan sent executades pel processador.
  • Bloquejat (waiting): El procés està parat en espera d’un esdeveniment que el desbloquegi (finalització d’una entrada/sortida, recepció d’un senyal, etc.).
  • Finalitzat (terminated): El procés està finalitzat i s’alliberen els recursos que feia servir.

Només un procés pot estar en estat d’execució en un processador i en un moment determinats, però molts processos poden estar preparats o en espera bloquejats.

Transicions d'un procés

Un procés és un element essencialment dinàmic que va canviant entre els diferents estats mitjançant transicions. Partint d’un model de cinc estats com els que hem definit, les possibles transicions entre estats són les següents:

  • Nou → preparat: el sistema està preparat per admetre un nou procés perquè disposa de recursos suficients.
  • Preparat → execució: el planificador a curt termini, tot seguint diferents algorismes de planificació (Round Robin, SFJ, SPN, FCFS, etc.) decideix quin dels processos en cua de preparats passa a execució.
  • Execució → preparat: si l’algorisme de planificació és apropiatiu, el procés en execució pot tornar a la cua de preparats si esgota el seu temps prefixat d’execució (quàntum) o si rep una interrupció per l’arribada d’un procés amb més prioritat.
  • Execució → bloquejat: si un procés en execució necessita una operació d’entrada/sortida o algun altre esdeveniment per continuar, passa a l’estat de bloquejat i allibera la CPU.
  • Bloquejat → preparat: si en un procés bloquejat arriba el succés o finalitza l’operació d’entrada/sortida que esperava, llavors retorna a la cua de processos preparats.
  • Execució → finalitzat: si un procés finalitza l’execució de les seves línies de codi o bé rep una excepció per algun tipus d’error greu, passa a procés finalitzat i allibera els recursos emprats.

Model de cinc estats

Aquest model descrit de cinc estats i les seves transicions descrit anteriorment es pot veure gràficament en el diagrama d’estats i transicions de la figura.

Figura Model de cinc estats dels processos amb les seves transicions

Model de set estats

Si al model de cinc estats li afegim la planificació a mig termini que gestiona l’intercanvi de processos a la memòria secundària, podem considerar dos nous estats:

Figura Model de set estats dels processos amb la inclusió dels estats de suspensió

  • Suspès preparat: Aquells processos que ja estan preparats per ser executats però que, per falta de recursos del sistema, el planificador a mig termini ha decidit passar temporalment a la memòria secundària (disc dur).
  • Suspès bloquejat: Processos que estan en espera d’un esdeveniment o de la finalització d’una operació d’entrada/sortida i que són passats a la memòria secundària per alliberar recursos.

Així, doncs, ens queda un diagrama d’estats i transicions com el de la figura.

Control i estructura dels processos

Controlar i fer operatiu tot aquest sistema de gestió dels processos requereix la definició d’una sèrie d’estructures de dades que continguin tota la informació associada a cada procés, així com les llistes i taules per controlar les diferents cues implicades en la planificació. Dues d’aquestes estructures bàsiques d’informació són el bloc de control de procés (PCB) i el bloc de control de sistema (SCB).

D’altra banda, cal comprendre el mecanisme que permet al processador canviar el procés que està executant per un altre. Aquest mecanisme s’anomena canvi de context. La problemàtica de la penalització en temps de CPU que suposa el canvi de context ens portarà a l’aparició de tècniques més òptimes, com els sistemes multifil basats en fils d’execució o threads.

Bloc de control de procés

Cada procés es representa al sistema operatiu com una estructura de dades anomenada bloc de control de processos (en anglès process control block o PCB) que descriu el procés i conté una sèrie de camps d’informació:

  • Identificador del procés.
  • Estat: estat actual del procés (preparat, bloquejat, en execució, etc.)
  • Comptador del programa: indica l’adreça de la següent instrucció d’aquest procés que s’executarà.
  • Registres de la CPU: acumuladors, punters de pila (stack) i registres generals.
  • Informació de planificació: com la prioritat del procés i el valor del quàntum.
  • Informació de la gestió de la memòria: definició de la finestra de memòria amb el registre base i límit, taula de pàgines o segments.
  • Informació de comptabilitat: temps de CPU, temps consumit, etc.
  • Informació de l’estat de les entrades/sortides: dispositius d’entrada/sortida assignats al procés, llista d’arxius oberts, etc.
  • Punter a la memòria: apunta al node següent de la llista enllaçada de PCB.

Per gestionar els processos el sistema operatiu ha de llegir, tractar i manipular aquestes estructures de dades.

Bloc de control del sistema

Els sistemes operatius disposen també d’una estructura anomenada bloc de control del sistema (de l’anglès system control block o SCB) per controlar i reunir informació de totes les estructures de dades dels processos, les interrupcions i les excepcions. El bloc de control de sistema conté habitualment la informació següent:

  • Un punter cap al descriptor (PCB) del procés que està fent ús del processador (procés actiu)
  • Un punter a una cua de descriptors dels processos preparats (ready)
  • Un punter a una cua de descriptors dels processos bloquejats (waiting)
  • Un punter a una cua de descriptors dels processos suspesos preparats
  • Un punter a una cua de descriptors dels processos suspesos bloquejats
  • Punters als vectors d’interrupcions i d’excepcions que són referències a les rutines necessàries per atendre aquests esdeveniments

Figura Estructures de control de processos: bloc de control de procés i de sistema

Una interrupció, sigui de programari (crides al sistema) o de maquinari (rellotge, dispositius d’entrada/sortida, reinicialització, etc.), és la presència d’un esdeveniment que obliga el sistema operatiu a prendre el control del processador per analitzar i tractar la situació mitjançant rutines específiques.

Una excepció és un tipus d’interrupció generada al sistema per un error (divisió per zero, desbordament de memòria…).

Vector d'interrupcions/excepcions

És una taula de les adreces de memòria on estan situades les rutines a executar pel tractament de la interrupció/excepció generada.

A la figura es mostra un esquema d’aquestes estructures de dades.

Canvi de context

Quan un procés en execució ha d’abandonar la CPU per algun esdeveniment (interrupció, exhauriment del quàntum, operació d’entrada/sortida, etc.) i s’ha de començar o reprendre un altre procés és necessari fer un canvi de context. Per fer això cal guardar el context del procés que surt, és a dir, el seu estat, registres, comptador de programa, etc., que està representat pel seu PCB (bloc de control de procés) i recuperar el context del procés que entra en execució. Vegeu la figura.

Figura Accions a efectuar en un canvi de context

Els canvis de context permeten la commutació de la CPU entre diferents processos, però també suposen una penalització pel temps necessari per efectuar-los. Per intentar reduir aquesta penalització (overhead) es fan servir noves estructures com els fils d’execució (threads).

Fils d'execució

La definició de procés inclou dos conceptes separats i potencialment independents: un de relatiu a la propietat dels recursos, i un altre que fa referència a la assignació de CPU per a l’execució del codi.

  • Recursos del procés: A un procés se l’assigna sempre un espai de memòria i a vegades també altres recursos com dispositius d’entrada/sortida i arxius.
  • Assignació de CPU: Un procés és un flux d’execució, també anomenat traça, quan aquest és assignat a un processador per a l’execució del codi.
    A la majoria de sistemes operatius aquests dos requeriments són l’essència del procés, però poden ser tractats de manera independent. Aquesta distinció ha portat, en els sistemes operatius actuals, a desenvolupar el concepte de fil d’execució, també anomenat procés lleuger o thread, en anglès. Tenint en compte aquesta divisió de característiques, podem definir fil d’execució com la unitat d’assignació de CPU.

Així, doncs, en un procés hi pot haver un o més fils d’execució que disposen dels seus propis:

  • Context, és a dir, el comptador de programa, estat del fil (preparat, bloquejat, etc.) i els registres de CPU, tot definit en una estructura de dades anomenada bloc de control del fil.
  • Pila d’execució per les variables locals.

En canvi, tots els fils d’execució d’un mateix procés comparteixen certs recursos com ara l’espai de memòria, les variables globals i els arxius i dispositius d’entrada i sortida.

Els beneficis clau de la implementació de sistemes multifil rau en la millora del rendiment. És triga menys temps a crear i finalitzar fils d’execució, així com a fer canvis de context entre fils d’un mateix procés. La comunicació entre fils també és més ràpida, ja que comparteixen memòria i recursos als que poden accedir sense invocar el nucli del sistema operatiu. Finalment, en sotmetre un mateix procés a diferents fluxos d’execució es manté una única còpia del codi en memòria i, en sistemes multiprocessador, fins i tot és possible l’execució simultània de diferents fils del mateix procés en diferents processadors. Vegeu la figura.

Figura Model tradicional de procés i model de procés multifil

En un sistema multifil cada fil d’execució és independent i fins i tot por executar-se simultàniament en processadors diferents, però compartint els mateixos recursos de memòria i dispositius d’entrada/sortida.

Prioritats dels processos

Un dels factors fonamentals que intervenen en la planificació a curt termini dels processos és la prioritat, que determina la cua on un procés haurà d’esperar el seu torn. A cada procés se li assigna una prioritat en funció de si és més crític o més urgent i dels recursos que necessita, la qual cosa determinarà finalment la freqüència d’accés al processador.

Tipus de prioritats

Podem establir una classificació de les prioritats en funció de la seva possibilitat de variació al llarg de l’execució del procés. Així, tindrem:

  • Prioritat estàtica: Aquelles que no poden ser modificades mentre s’executa el procés.
  • Prioritat dinàmica: Quan un procés pot modificar la seva prioritat en funció de determinats esdeveniments.
    Cada procés té assignada una prioritat que pot ser estàtica, dinàmica o una combinació de les dues. El problema de la prioritat estàtica és la inanició, és a dir, que un procés mai s’executi per no tenir mai la prioritat suficient. Per solucionar això es fa servir la prioritat dinàmica per envelliment, en la qual els processos van augmentant la seva prioritat en funció del temps que fa que estan en espera.

D’altra banda, la prioritat d’un procés està composta per dos factors:

  • Prioritat assignada pel sistema operatiu en funció del tipus de procés, algorismes de planificació, polítiques per preveure la inanició, etc.
  • Prioritat assignada pel propi usuari. Naturalment només afecta als processos d’usuari i permet tenir en compte els seus interessos i necessitats. Aquesta llibertat comporta un cert risc, com, per exemple, deixar bloquejada la resta del sistema si un programa amb prioritat alta assignada per l’usuari entra en un bucle infinit.

Als sistemes Unix/Linux, la prioritat d’usuari s’anomena prioritat nice i es pot assignar amb les ordres nice i renice.

Ordres per gestionar la prioritat

Més és menys

Nice vol dir ‘amable’ en anglès. Així s’entén millor per què quan més gran és el valor de nice menys prioritat té el procés i per tan és més “amable” amb la resta de processos que competeixen pels recursos.

Tots els processos tenen una prioritat assignada per l’usuari, anomenada prioritat nice. Els processos amb més prioritat tenen valors negatius de nice i fan servir més recursos que els altres. La prioritat màxima assignada a nice és –20 i la prioritat mínima és +19. Si la prioritat no està definida, cada procés s’executarà amb una prioritat nice de 0.

Ordre nice

L’ordre nice permet arrencar un procés assignant-li d’entrada una determinada prioritat i té com a argument el nom de l’ordre que genera el procés sobre el qual volem actuar. Si no especifiquen el nivell de prioritat queda definida per defecte en 10.

  1. $ nice -n 19 987

Aquesta ordre deixa amb prioritat mínima el procés de PID=987.

Ordre renice

Per canviar la prioritat nice d’un procés ja engegat es fa servir l’ordre renice. Per exemple:.

  1. $ renice -n -5 987 -u root

Aquesta ordre donarà prioritat –5 al procés de PID=987 i a tots els processos de l’usuari root.

Qualsevol usuari pot reduir la prioritat del seus processos, però només el superusuari pot augmentar la prioritat d’un procés aplicant un valor de nice negatiu.

També es pot canviar la prioritat nice amb l’ordre interactiva top.

Podem veure un esquema de la prioritat nice i la sintaxi de les ordres nice i renice a la figura:

Figura Canvis de prioritat amb nice i renice

Herència de la prioritat

Els processos fill hereten la prioritat del pare, però si es canvia la prioritat del procés pare, els processos fills ja nascuts no canvien de prioritat.

Comunicació amb els processos

Hi ha diferents mecanismes que permeten la comunicació entre els processos, alguns dels quals veurem en aquest apartat. D’una banda, tot procés té associat uns arxius (stdin, stdout, stderr) que reben la comunicació d’entrada i sortida de dades. Aquests fluxos de dades dels processos poden ser intercomunicats mitjançant canonades.

D’altra banda, tot procés que finalitza torna informació a una variable de retorn. Aquesta variable pot ser llegida per un altre procés i condicionar la seva funcionalitat.

Finalment, un procés pot rebre informació i ordres mentre s’està executant mitjançant l’enviament de determinats senyals.

Canonades

Entre els recursos associats a un procés hi ha la interfície estàndard de comunicació amb l’exterior. Aquesta interfície consta de tres fitxers coneguts com a arxius d’entrada, de sortida i d’errors estàndard. A Unix/Linux, quan un procés obre un arxiu, el nucli del sistema li lliura un número sencer que el procés farà servir per realitzar operacions d’entrada i sortida. Els descriptors associats als arxius estàndard estan indicats a la taula.

Taula Arxius estàndard d’entrada i sortida
Descriptor Denominació Descripció
0 stdin Entrada estàndard, associada per defecte al teclat del terminal.
1 stdout Sortida estàndard, associada per defecte a la pantalla del terminal.
2 stderr Sortida d’errors, associada per defecte a la pantalla del terminal. Mostra els missatges d’error.

Valors de retorn

Tot procés que finalitza torna un número comprès entre 0 o 255 que representa la causa per la qual va finalitzar. A la taula podem veure alguns valors de retorn.

La variable d’entorn ? conté el valor de retorn de la darrera ordre executada i es pot visualitzar amb echo$?.

Taula Valors de retorn d’un procés
retorn Descripció
0 Finalització correcta del procés. Representa un valor lògic vertader si es fa servir en una comparació o iteració. Qualsevol altre valor diferent de 0 es considera fals.
1 Indica error. Finalització anormal del procés
129 … 160 Indica que el procés ha finalitzat com a conseqüència d’un senyal. Restant 128 al valor de retorn s’obté el codi d’aquest senyal.

Senyals

El senyals són interrupcions que rep el procés mentre està en execució per indicar que s’ha produït algun esdeveniment significatiu davant del qual ha de respondre.

El senyals poden ser enviats pel nucli del sistema, per altres processos o pel mateix usuari. Alguns d’aquests senyals poden ser capturats (trap), és a dir, poden ser ignorats o rebre un tractament específic pel procés si així està programat. En canvi, els senyals SIGKILL i SIGSTOP s’han d’atendre obligatòriament i no es poden ignorar.

Hi ha un bon grapat de senyals que podem visualitzar amb l’ordre kill (vegeu la figura).

  1. $ kill -l

Figura Llistat dels senyals amb kill -l

Els senyals més importants s’han resumit a la taula.

Taula Senyals més emprats amb la seva descripció
Núm. Senyal Trap Descripció
1 SIGHUP Finalització per tancament terminal o del procés pare
2 SIGINT Finalització per teclat (Ctrl+C)
9 SIGKILL NO Finalització forçada
15 SIGTERM Finalització ordenada per defecte
18 SIGCONT Continua un procés aturat
19 SIGSTOP NO Atura el procés
20 SIGSTP Atura el procés per teclat (Ctrl+Z)

Hi ha un grup de senyals de finalització que tenen com a objectiu l’acabament del procés i l’alliberament del recursos que feia servir (senyals 1, 2, 9 i 15). D’altres tenen com a objectiu aturar el procés però sense treure’l de memòria per poder engegar-lo de nou en el mateix punt en què es va deixar (senyals 19 i 20).

Per obtenir informació completa dels senyals:

  1. $ man -s7 signal

Ordres relacionades amb senyals

A continuació es detallen una sèrie de combinacions de tecles i ordres de consola relacionades amb l’enviament de senyals als processos.

Senyals de teclat

Hi ha una sèrie de combinacions de tecles que envien senyals directament al procés que s’està executant en primer pla:

  • Ctrl+Z: Envia el senyal 20 (SIGTSTP). Aquest senyal atura el procés, però el deixa a la memòria i es pot reprendre en el punt en el qual va quedar mitjançant un senyal 19 (SIGCONT).
  • Ctrl+C: Envia el senyal 2 (SIGINT). La majoria d’aplicacions està programades per finalitzar quan reben aquest senyal, però cal tenir en compte que es pot programar una aplicació perquè capturi aquest senyal i l’ignori.
  • Ctrl+\: Envia el senyal 3 (SIGQUIT). També depèn de com estigui configurada l’aplicació, però en principi ha de produir una finalització del procés amb un bolcat a un arxiu del seu estat en el moment de la finalització.

Ordre kill

Podem fer servir l’ordre interna kill per enviar senyals a qualsevol procés que haguem creat tant en primer com en segon pla. A més, si som administradors podem enviar senyals a processos d’altres usuaris.

L’ordre kill necessita identificar el procés mitjançant el seu PID (identificador de procés), tot i que si es tracta d’un procés en segon pla del nostre terminal, també pot fer servir el seu número de treball (job) precedit del símbol %.

Per defecte, tant l’ordre kill com killall envien el senyal 15 SIGTERM de finalització ordenada del programa.

Veguem-ne algun exemple:

  1. # kill 2343

En aquest cas s’envia el senyal de finalització ordenada SIGTERM al procés de PID=2343. En alguns casos, els processos no responen al senyal de finalització per defecte i cal enviar el senyal de finalització forçada, que no és pot capturar i s’ha d’obeir. Qualsevol de les sintaxis següents és vàlida:

  1. # kill -9 2343
  2. # kill -SIGKILL 2343

Ordre killall

Amb l’ordre kill podíem enviar senyals a un procés determinat definit pel seu PID. Si volem enviar senyals a un procés a partir del seu nom hem de fer servir killall.

  1. # killall -9 mozilla

Aquesta instrucció tancarà tots els navegadors Mozilla oberts per l’usuari que executa l’ordre.

Ordre nohup

Quan tanquem una sessió, tancant la finestra del terminal si estem en l’entorn gràfic o mitjançant l’ordre exit o Ctrl+D si estem en l’entorn de línia d’ordres, el procés que gestiona el terminal (getty, mingetty) intenta tancar tots els processos associats a aquell terminal. Per fer aquest tancament envia el senyal SIGHUP a tots els processos en marxa i també als aturats en segon pla, ja que prèviament els ha activat amb un senyal de SIGCONT.

Si volem que algun dels nostres processos es mantingui actiu després de tancar la sessió, l’hem de protegir d’aquest senyal SIGHUP amb l’ordre nohup. La sintaxi és simple: cridem l’ordre nohup i li donem com a paràmetre l’ordre a protegir:

  1. # nohup ./prova.sh
  2. nohup: es descarta l’entrada i s’afegeix l’eixida a «nohup.out»

En aquest exemple, l’execució de l’script ./prova.sh està protegida contra el senyal SIGHUP, la seva sortida estàndard ja no és la consola (que podria estar tancada), sinó que la sortida és redreçada i afegida a un arxiu específic anomenat nohup.out.

Ordre disown

L’ordre interna disown també ens permet protegir processos del senyal SIGHUP. Les diferències amb nohup són les següents:

  1. L’ordre disown s’aplica a treballs en segon pla que ja existeixen.
  2. A diferència de nohup, no canvia les sortides estàndard i d’error.

Vegem-ne alguns exemples:

  1. # disown -h %3

Protegeix contra SIGHUP el treball 3 de segon pla.

  1. # disown -a

Protegeix contra SIGHUP tots els treballs en segon pla.

  1. # disown -r

Protegeix contra SIGHUP tots els treballs en segon pla que estan en marxa (running).

Ordre trap

És una ordre interna que ens permet capturar un senyal i especificar el que volem fer quan ens arribi. La seva sintaxi és trap [ordres][senyals]:

  1. trap "" SIGTERM

Aquesta ordre dins d’un script capturarà el senyal de finalització SIGTERM i l’ignorarà, ja que com a ordres a seguir li hem posat una cadena buida.

Seqüència d'arrencada del sistema

En el moment que engeguem l’interruptor de l’ordinador, comença una llarga seqüència d’accions i execucions de processos que finalment ens porta fins que a la pantalla ens apareix l’entorn gràfic del sistema operatiu o una consola de text ens convida amb el prompt (indicador d’ordres) a introduir una ordre.

Fem ara un repàs resumit de tota aquesta seqüència i, al llarg dels diferents epígrafs, posarem especial atenció en els darrers esdeveniments que culminen en la creació de l’arbre de jerarquia de processos i en la càrrega de l’intèrpret d’ordres o shell.

GRUB

Acrònim de grand unified bootloader. Carregador d’arrencada múltiple del projecte GNU que es fa servir per engegar un dels sistemes operatius instal·lats en el mateix ordinador.

  1. Després de reiniciar (reset) o d’engegar l’interruptor de l’equip, els components electrònics reben alimentació. El microprocessador comença a executar instruccions des de una posició del mapa de memòria determinada, anomenada vector de reset i comença a executar un programa especial anomenat BIOS (basic input/output system) que està allotjat a la memòria fixa del sistema de tipus ROM (memòria només de lectura).
  2. Aquest programa fix que incorpora cada placa base constitueix l’anomenat firmware i conté rutines de comprovació de memòria, detecció de dispositius de maquinari, rutines POST (power-on self test) per a la verificació del components. També ofereix a l’usuari la interacció opcional amb el sistema de memòria CMOS, que guarda la configuració de diferents característiques del sistema com ara el rellotge de temps real, la memòria secundària, la seqüència d’arrencada, etc.
  3. Un cop executades les instruccions de la BIOS, la darrera acció que realitza és la cerca del sistema operatiu a la memòria secundària, habitualment el disc dur, per carregar-lo a la memòria. Per fer això s’adreça al primer sector del disc dur anomenat MBR (master boot record).
  4. Tradicionalment, l’MBR conté un gestor d’arrencada simple i la taula de particions del disc dur, que indica quina és la partició activa que conté el sistema operatiu a carregar. Tanmateix, gairebé totes les distribucions Linux fan servir programes carregadors d’arrencada múltiple (bootloader) més complexos, com ara GRUB.
  5. Així, doncs, en un sistema Debian, s’inicia a l’MBR la fase 1 de GRUB anomenada primer carregador de l’arrencada (initial program loader o ILP).
  6. Com que gairebé no hi ha espai a l’MBR per a un programa complex, cal l’execució d’una fase anomenada fase 1.5, que conté codi addicional i està situada als primers sectors després de l’MBR, sempre a la primera pista del disc dur per motius de compatibilitat.
  7. La resta del codi de GRUB s’executa en la fase 2 i normalment s’instal·la al sector d’arrencada de la partició on hi ha instal·lat el sistema Linux. Aquest codi interpreta la configuració de l’arxiu /boot/grub/grub.cfg, dóna suport a diferents sistemes d’arxius i permet el pas de paràmetres al nucli del sistema, a més d’interaccionar amb l’usuari mostrant el menú de selecció a pantalla.
  8. Una vegada escollida la partició d’arrencada a partir del menú de GRUB es comença la càrrega del nucli del sistema operatiu pròpiament dit. En el cas de Linux, una vegada carregat el nucli del sistema operatiu comença la creació de processos que s’executen en un ordre determinat i culmina en la creació de tota una estructura jeràrquica de processos i serveis.

Jerarquia de processos (PID, PPID)

A Unix/Linux tots els processos s’identifiquen amb un número sencer de 16 bits que s’assigna seqüencialment a cada nou procés que es crea. Aquest número és únic per a cada procés i s’anomena identificador de procés o PID (de l’anglès proces identifier). A més, tot procés, a excepció del procés arrel init amb PID=1, ha estat creat per un procés pare. Així, doncs, un procés pare pot tenir molts processos fills, però qualsevol procés només té un procés pare, identificat pel seu PPID (parent procés identifier). Això crea una estructura jeràrquica de processos en forma d’arbre amb el procés init com a arrel.

Procés pare i procés fill poden o no compartir recursos i espai de memòria, i estar o no sincronitzats, és a dir, es poden executar concurrentment o bé el procés pare pot restar en espera fins a la finalització del procés fill.

Creació i finalització de processos. Crides al sistema

A Unix/Linux els processos en creen mitjançant crides al sistema que fan primer una duplicació del procés pare i després un recobriment del codi carregant i executant les noves instruccions. Tot això es fa mitjançant les crides a les funcions de sistema següents:

  • Funció fork(): aquesta funció crea un procés fill que és una còpia pràcticament exacta del procés pare (clonació) i hereta el context del pare. Tots dos processos continuen executant-se després del punt en el qual s’ha fet la crida fork(), amb l’única diferència del seu PID.
  • Funció exec(): després de la clonació, el procés pare o bé el mateix fill han de cridar la funció exec, que carrega al segment de dades (recobriment) el nou codi a executar.
  • Funció exit(): s’invoca després de la darrera instrucció del codi per efectuar la finalització del procés i alliberar els recursos que feia servir.
  • Funció wait(): si el procés pare vol esperar que el procés fill finalitzi, haurà de cridar la funció wait(), que aturarà l’execució i el passarà a la cua de bloquejats (waiting) fins que el procés fill finalizi.

A la figura es resumeixen les crides al sistema anteriors.

Figura Esquema de les crides al sistema implicades en la creació d’un procés fill

A més de la finalització voluntària del procés mitjançant la crida a la funció exit(), un procés també pot finalitzar involuntàriament per:

  • Excepció: error fatal motivat per diverses causes, instrucció privilegiada, excepció de coma flotant, violació de segment…
  • Funció kill(): un procés por ser finalitzat per un altre mitjançant la crida al sistema kill() i l’enviament del senyal de finalització corresponent.

Treballs en segon pla d'execució

Quan un procés pare crea un procés fill hi ha dues possibilitats en termes d’execució:

  1. El procés pare espera la finalització del procés fill.
  2. Pare i fill s’executen concurrentment.

D’aquesta manera en l’entorn del procés de shell, quan fem una crida a una ordre de sistema aquesta pot generar un procés o processos fills del shell que es poden executar en:

  • Primer pla (foreground): quan el shell queda a l’espera de la finalització de l’ordre executada i per tant el terminal no accepta noves ordres fins a la finalització del procés fill.
  • Segon pla (background): si els procés o processos fills s’executen concurrentment al procés shell pare, que continua acceptant noves ordres.

Directiva &

Per poder enviar l’execució d’una ordre a segon pla només cal afegir el símbol & al final de la línia d’ordres. Per exemple:

  1. # find / -name "*.txt" &
  2. #

En aquest exemple, mentre el sistema cerca en tot l’arbre de directoris els arxius amb extensió txt, tornem de seguida a tenir l’indicador de sistema (prompt), que ens acceptarà noves ordres.

El problema és que els missatges de l’ordre find en segon pla en apareixen a la consola i dificulten el treball, però sempre podem redreçar la sortida principal i la d’errors cap a un arxiu:

  1. # find / -name "*.txt" >Llistat 2>Errors &
  2. [1] 1544
  3. #

Se’ns mostra el número de treball [1] i el PID associat al procés, 1544. Després apareix de nou l’indicador que ens convida a introduir noves ordres, com per exemple:

  1. # yes

L’ordre yes genera contínuament el caràcter “y” i bloqueja el terminal. Podem fer servir la combinació de tecles Ctrl+Z, que enviarà aquest procés a segon pla i el deixarà aturat.

  1. # ^Z
  2. [2]+ Aturat yes

Ara tornem a fer la mateixa ordre, però amb més cura, enviant l’ordre directament a segon pla i la seva sortida al dispositiu null perquè no ens faci nosa:

  1. # yes >/dev/null &
  2. [3] 1711

Ja tenim un tercer treball en segon pla amb PID=1711.

Ordre jobs

L’ordre jobs ens permet visualitzar els treballs que tenim en segon pla i veure l’estat en el qual es troben. Si hem efectuat les anteriors ordres veurem alguna cosa semblant a:

  1. # jobs
  2. [2]+ Aturat yes
  3. [3]- S'est? executant yes > /dev/null &

Com podeu veure, la primera ordre find ja no apareix, doncs ha finalitzat. Tenim el segon treball yes que hem aturat a segon pla amb la combinació Ctrl+Z i un tercer treball en marxa executant-se en segon pla, però amb la seva sortida redreçada al dispositiu null.

Ordres fg i bg

Aquestes ordres permeten reprendre una tasca aturada a segon pla en el punt on es va aturar. Aquesta tasca es pot reprendre en primer pla amb fg o en segon pla amb bg. Per indicar quina de les tasques aturades en segon pla volem reprendre cal indicar el nombre de treball precedit del símbol %.

  1. # fg %2

Amb aquesta ordre reprendrem a primer pla el treball [2] que estava aturat. Començarà a sortir lletres “y” a la pantalla. Podem tornar a aturar el procés i enviar-lo a segon pla amb la combinació Ctrl+Z o parar el procés definitivament amb Ctrl+C i podrem tornar a cridar jobs:

  1. ^C
  2. # jobs
  3. [3]+ S'est? executant yes > /dev/null

Ara només ens queda un treball en execució en segon pla. Per finalitzar definitivament un procés que s’està executant al background podem fer servir l’ordre kill tot indicant el número de PID o bé el número de treball precedit del símbol %.

  1. kill %3

A la figura podeu veure un resum d’aquestes ordres i de la seva funcionalitat.

Figura Ordres principals per gestionar el processos a primer i segon pla

Dimonis

Un dimoni (de l’anglès daemon) és un procés no interactiu en segon pla que generalment tenim carregat a la memòria en espera d’algun senyal provinent d’un dispositiu o del mateix nucli del sistema per a despertar-se i realitzar les accions i funcions necessàries i oferir un determinat servei.

Daemon és l’acrònim de disk and execution monitor.

Els dimonis no disposen d’interfície amb l’usuari, per tant, no utilitzen les entrades i sortides estàndard per comunicar errors o enregistrar el seu funcionament, sinó arxius de registre (log), situats habitualment al directori /var/log.

Encara que un dimoni sigui un procés com qualsevol altre, que s’executa en segon pla (background), la manera de gestionar-lo i invocar-lo és diferent a la resta d’ordres i programes del sistema. Generalment, els dimonis tenen un guió de shell (shell script) situat al directori /etc/init.d/ que permet iniciar-los, parar-los o veure el seu estat d’execució segons la sintaxi:

  1. # /etc/init.d/NomDimoni Accio

Els paràmetres d’acció bàsics que ha d’acceptar el guió del dimoni són:

  • start: per iniciar el dimoni. Si aquest ja s’executa es mostra un missatge d’error.
  • stop: per parar el dimoni. Si no s’executa es mostra un missatge d’error.
  • restart: reinicia el dimoni i serveix perquè es tornin a llegir els seus arxius de configuració.
  • reload: encara que no tots els dimonis ho permeten, aquesta acció permet recarregar els arxius de configuració sense haver de parar el dimoni.

Per exemple:

  1. # /etc/init.d/cupsd start
  2. # /etc/init.d/networking restart

La primera línia posa en marxa el servei d’administració d’impressores CUPS i la segona reinicia la xarxa llegint els seus arxius de configuració.

Algunes distribucions, entre elles Debian, disposen de l’ordre service que permet fer el mateix sense especificar la ruta completa:

  1. # service cupsd stop

Nivells d'execució

Els dimonis que estan en execució en un moment determinat ens marquen els serveis que un sistema operatiu ofereix com a servidor i que rep com a client. Per organitzar adequadament la quantitat i interacció dels serveis que necessitem en un entorn o circumstància determinats disposem del nivells d’execució (runlevels, en anglès). Així, doncs, un nivell d’execució no és més que l’agrupació d’una sèrie de dimonis en execució que té com a finalitat crear un entorn de serveis ajustat a unes necessitats concretes.

Generalment, els sistemes Unix/Linux ens proporcionen diferents nivells d’execució, amb la funcionalitat indicada a la taula.

Taula Nivells d’execució (runlevels) i la seva funcionalitat
Nivel Funcionalitat
0 El nivell d’execució 0 està configurat per aturar el sistema.
1 Nivell per a un usuari únic (single user). Es posen en marxa els dimonis mínims per fer tasques de manteniment i només permet l’entrada a l’arrel (root).
2 a 5 Nivells destinats a ser configurats segons les necessitats de cada instal·lació encara que habitualment tots són multiusuari.
En algunes distribucions el nivell 2 està configurat per defecte com a multiusuari sense servei de xarxa, el nivell 3 com a multiusuari amb servei de xarxa, i el nivell 5 per engegar el sistema amb l’entorn gràfic.
6 Aquest nivell està preparat per reiniciar el sistema.

El nivell d’execució de la vostra màquina es pot consultar des de consola amb l’ordre runlevel, que requereix privilegis de superadministrador (root)

Cada nivell d’execució té un directori associat a /etc/rcX.d (on X és el número del nivell). En aquests directoris hi trobem enllaços simbòlics als guions de shell que controlen als dimonis i que ja hem vist que estan situats al directori /etc/init.d.

A més dels subdirectoris dels diferents nivells, n’hi ha un altre, /etc/rcS.d, que conté les referències als serveis bàsics que s’executen prèviament a qualsevol altre nivell.

Vegem per exemple el contingut del directori associat al nivell d’execució 0:

  1. # ls /etc/rc0.d
  2.  
  3. K09apache2 K70vboxadd S15wpa-ifupdown S40umountfs
  4. K10monit K70vboxadd-x11 S20sendsigs S60umountroot
  5. K20netdiag K74bluetooth S30urandom S90halt
  6. K20ntop S35networking

La primera lletra del nom d’aquestos enllaços simbòlics porta informació sobre l’acció que han de fer:

  • K: si l’enllaç comença per K (kill) indiquem que volem aturar el dimoni.
  • S: si l’enllaç comença per S (start) indiquem que volem activar el dimoni.

Després d’aquesta lletra es posa un número de dues xifres, entre 00 i 99, que indica l’ordre en la seqüència d’inici i aturada de serveis. Aquest ordre és important, ja que alguns dimonis tenen dependències, és a dir, necessiten que altres estiguin en execució abans de ser iniciats. Finalment trobem el nom del dimoni en qüestió que ens interessa parar o activar. Vegeu la figura:

Figura Sintaxi dels enllaços simbòlics als scripts de control dels serveis

L’ordre per canviar de nivell d’execució és init i li passem com a paràmetre el nivell d’execució que volem engegar. Així, per reinicialitzar el sistema:

  1. # init 6

El procés de canvi de nivell és el següent: el sistema inspecciona el directori corresponent al nivell que volem habilitar i començarà primer a detenir els dimonis corresponents a les entrades que comencen per K passant el paràmetre stop i després iniciarà els corresponents a les entrades que comencen per S mitjançant el paràmetre start.

La modificació de la configuració d’un nivell d’execució es pot fer manualment:

  1. Incloure el script de tractament del servei en el directori /etc/init.d.
  2. Crear els enllaços simbòlics en cada directori de nivell d’execució (/etc/rcX.d) donant en el mateix nom la informació de ordre seqüencial d’execució i comançant per K o S si el procés s’ha d’aturar o engegar respectivament.

També es pot fer de manera més còmoda amb l’ordre update-rc.d.

Ordre update-rc.d

A Debian disposem de l’ordre update-rc.d per crear automàticament els enllaços simbòlics necessaris per a cada nivell d’execució. Vegem-ne alguns exemples:

  1. # update-rc.d cups defaults

Inscriu el servei d’impressió CUPS amb els paràmetres per defecte, és a dir, que s’engegui en els nivells del 2 al 5 i que s’aturi en els nivells 0, 1 i 6. L’ordre d’aturada/engegada serà el 20 per defecte. L’script de servei ha d’estar a /etc/init.d/cups.

  1. # update-rc.d cups start 10 3 . stop 05 0 1 6

En aquest cas només s’engegarà en l’ordre de posició 10 en el nivell 3 i s’aturarà en els nivells 0, 1 i 6 en la posició 05.

  1. # update-rc.d -f cups remove

El paràmetre remove suprimeix els vincles dels diferents directoris, però l’script de servei associat (/etc/init.d/cups) ja no ha d’existir. En cas contrari s’ha de fer servir l’opció -f per forçar la supressió dels vincles.

chkconfig

Altres distribucions com Fedora/Red hat i openSUSE fan servir l’ordre chkconfig per configurar els serveis en els diferents nivells d’execució.

Directori /etc/default

Molt sovint cal configurar algunes variables per controlar el comportament dels scripts dels serveis que es troben al directori /etc/init.d.

Si aquestes variables es defineixen dins de l’script del servei s’haurien de reconfigurar cada vegada que actualitzem el paquet. Per facilitar la tasca d’administració i garantir que les variables de configuració estan sempre disponibles es poden guardar en arxius específics i independents situats al directori /etc/default.

Aquests arxius només han de contenir la declaració de variables i, en tot cas, comentaris explicatius. A continuació posem un exemple del contingut d’un d’aquest arxius:

  1. $ cat /etc/default/cups
  2. # Cups configure options
  3. # LOAD_LP_MODULE: enable/disable to load "lp" parallel printer driver module
  4. LOAD_LP_MODULE=yes

Sistema d'arrencada

La jerarquia de l’arbre de processos, el seu mecanisme de creació i finalització, el concepte de dimoni i servei i l’agrupació de serveis en diferents nivells d’execució configurables, són part fonamental de la seqüència final d’arrencada del sistema operatiu Linux i la creació del seu entorn de processos i serveis.

El nucli del sistema operatiu finalment està carregat ja a la memòria i activa dos processos previs a la generació de tot l’arbre jeràrquic de processos:

  • El planificador (scheduler): procés amb PID=0 que gestiona l’assignació de processos a la CPU per a la seva execució.
  • El procés d’inici init amb PID=1. El pare de tots els processos. Tot l’arbre de processos de Linux és fill d’aquest procés.

Per generar l’arbre de processos tenim dos enfocaments: un de seqüencial, en el qual els diferents serveis s’engeguen seguint un ordre prefixat i configurat prèviament en els nivells d’execució, i un enfocament basat en esdeveniments, en el qual els serveis s’inicien depenent de l’ocurrència de determinats successos.

Sistema seqüencial: procés init

Tradicionalment, els sistemes Linux han fet servir un sistema d’arrencada heretat d’Unix System V i que està basat en el procés init. Aquest procés l’inicia el nucli del sistema i és l’encarregat de posar en marxa tots els serveis necessaris definits en el nivell d’execució configurat per defecte.

Per realitzar la seva tasca, el procés init fa servir la informació continguda en l’arxiu de configuració /etc/inittab, que conté, habitualment:

  • El nivell d’execució per defecte en arrencar.
  • Els scripts que s’han d’executar previs al nivell d’execució per defecte (continguts a /etc/rcS.d).
  • La configuració dels diferents nivells d’execució disponibles al sistema.
  • L’acció que s’ha de realitzar en prémer Ctrl+Alt+Del o amb altres combinacions de tecles.
  • La definició de consoles obertes en cada nivell d’execució.

Vegem un exemple de l’arxiu /etc/inittab amb alguns comentaris:

  1. $ cat /etc/inittab
  2.  
  3. # Es defineix el nivell d'execució per defecte.
  4.  
  5. id:2:initdefault:
  6.  
  7. # Aquest és el primer script que s'executa previ a qualsevol # nivell d'execució
  8.  
  9. si::sysinit:/etc/init.d/rcS
  10.  
  11. # Engega el script /etc/init.d/rc i li passa com paràmetre el nivell d'execució. Aquest script rc és el que recorre el directori /etc/rcN.d corresponent i executa en l'ordre adequat els inicis i finalitzacions dels serveis indicats.
  12.  
  13. l0:0:wait:/etc/init.d/rc 0
  14. l1:1:wait:/etc/init.d/rc 1
  15. l2:2:wait:/etc/init.d/rc 2
  16. l3:3:wait:/etc/init.d/rc 3
  17. l4:4:wait:/etc/init.d/rc 4
  18. l5:5:wait:/etc/init.d/rc 5
  19. l6:6:wait:/etc/init.d/rc 6
  20.  
  21. # Ordre a executar en cas de CTRL-ALT-DEL
  22.  
  23. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
  24.  
  25. # Indicacions del terminals tty engegats en cada nivell d'execució. Es veu que en els nivells 2 i 3 tenim les sis consoles activades. L'acció respawn vol dir que si el procés finalitza, torna a arrencar automàticament.
  26.  
  27. 1:2345:respawn:/sbin/getty 38400 tty1
  28. 2:23:respawn:/sbin/getty 38400 tty2
  29. 3:23:respawn:/sbin/getty 38400 tty3
  30. 4:23:respawn:/sbin/getty 38400 tty4
  31. 5:23:respawn:/sbin/getty 38400 tty5
  32. 6:23:respawn:/sbin/getty 38400 tty6

Un cop s’han acabat d’executar tots aquests scripts, s’executa finalment l’script d’execució local /etc/rc.local.

Sistema basat en esdeveniments: procés upstart

El sistema d’arrencada de System V basat en init és un procés síncron que executa seqüencialment una sèrie de tasques definides amb antelació i que no activa un procés fins a haver finalitzat l’anterior. A més, aquest sistema només executa aquestes tasques quan init canvia d’estat, cosa que només passa quan la màquina s’encén, s’apaga o s’està reiniciant. Aquest fet fa que init no gestioni adequadament altres serveis que és necessari executar no quan es canvia de nivell, sinó en funció de determinats esdeveniments.

Per això, algunes distribucions de Linux estan començant a substituir el tradicional init de System V per un sistema basat en esdeveniments anomenat upstart, però intentant sempre mantenir la compatibilitat enrere fent transparent el canvi a l’usuari. De fet, l’arxiu binari que gestiona upstart es diu igualment /sbin/init, encara que la seva manera de funcionar és molt diferent.

El model basat en esdeveniments d’upstart permet respondre de manera específica a determinats successos i no a seqüències predeterminades. Aquest asincronia fa que es puguin posar en marxa en paral·lel diferents tasques amb l’objectiu de minimitzar el temps d’arrencada.

En el sistema upstart l’arxiu de configuració /etc/inittab desapareix i es fan servir uns arxius de definició de treballs (jobs, en la terminologia upstart) situats al directori /etc/init.

  1. ls /etc/init
  2. acpid.conf mountall.conf rcS.conf anacron.conf mountall-net.conf rc-sysinit.conf apport.conf mountall-shell.conf rsyslog.conf atd.conf mounted-dev.conf tty1.conf
  3. avahi-daemon.conf mounted-tmp.conf tty2.conf
  4. ...

Aquests arxius d’extensió conf defineixen les condicions i els esdeveniments que s’han de produir per engegar o parar els serveis. Vegem un exemple resumit d’un d’aquest arxius:

  1. $ cat /etc/init/mysql.conf
  2. # MySQL Service
  3.  
  4. description "MySQL Server"
  5. author "Mario Limonciello <superm1@ubuntu.com>"
  6.  
  7. start on (net-device-up
  8. and local-filesystems
  9. and runlevel [2345])
  10. stop on runlevel [016]
  11. respawn
  12.  
  13. env HOME=/etc/mysql
  14. umask 007
  15. ...
  16. exec /usr/sbin/mysqld
  17. end script

Veiem que l’arxiu mysql.conf defineix que el dimoni mysqld es posarà en marxa (exec /usr/sbin/mysqld) quan es detecti que hi ha xarxa (esdeveniment net-device-up), el sistema d’arxius ha estat muntat (esdeveniment local-filesystems) i el nivell d’execució sigui multiusuari (entre el 2 i el 5). Si es detecta un esdeveniment de nivell d’execució 0, 1 o 6 el dimoni s’aturarà.

També es configura amb un d’aquests arxius (control-alt-delete.conf) l’acció associada amb l’esdeveniment de teclat Ctrl+Alt+Supr:

  1. $ cat /etc/init/control-alt-delete.conf
  2.  
  3. # control-alt-delete - emergency keypress handling
  4. #
  5. # This task is run whenever the Control-Alt-Delete key combination is pressed, and performs a safe reboot of the machine.
  6.  
  7. description"emergency keypress handling"
  8. author"Scott James Remnant <scott@netsplit.com>"
  9.  
  10. start on control-alt-delete
  11.  
  12. task
  13. exec shutdown -r now "Control-Alt-Delete pressed"

Adopció d'upstart

Les primeres distribucions en fer servir upstart com a sistema d’arrencada han estat Ubuntu i Fedora.

Upstart té com un dels seus objectius clau ser compatible amb el sistema Unix System V. Per això:

  • Conserva el directori /etc/init.d per als scripts de control dels serveis que encara no s’hagin migrat al sistema d’esdeveniments d’upstart.
  • Implementa un treball (job) específic /etc/init/rc-sysinit.conf que simula els canvis de nivell d’execució, gestiona els scripts de /etc/init.d i permet definir el nivell d’execució per defecte.
  • Manté l’ús del directori /etc/default per als arxius de configuració de variables que permetran ara el control del comportament tant dels scripts tradicionals de /etc/init.d com els arxius de definició de treballs d’upstart de /etc/init.
  • Per engegar un servei manualment també podrem fer servir la instrucció service.

Seqüència de processos getty, login i shell

Sigui quin sigui el procediment de posada en marxa dels serveis del sistema s’arriba finalment, dins de l’arbre de processos, a activar els terminals o consoles tty mitjançant el procés getty o bé mingetty. Aquests terminals es defineixen a l’arxiu /etc/inittab (als arxius /etc/init/ttyN.conf, en el cas d’upstart) i fan servir els dispositius /dev/ttyN, on N és el número de la consola. En aquest moment es visualitza el contingut de l’arxiu /etc/issue i la creació de processos s’atura en espera que l’usuari iniciï una sessió.

PAM

Acrònim de pluggable authentication modules. Consisteix en un mecanisme d’autenticació flexible que permet abstraure les aplicacions del procés d’identificació.

Per iniciar una sessió, l’usuari ha d’identificar-se amb un nom i una contrasenya mitjançant el procés de login. Aquestes credencials són verificades a /etc/passwd i /etc/shadow o bé fent servir mòduls PAM.

Una vegada identificat l’usuari, es presenta el contingut de l’arxiu /etc/motd (de l’anglès message of the day), i es llegeixen diferents arxius de configuració de perfil tan generals com particulars de l’usuari concret, entre ells:

  • /etc/profile
  • /etc/bash.bashrc
  • ~/.bashrc
  • ~/.profile

Finalment es carrega l’intèrpret d’ordres o shell que s’hagi configurat a l’arxiu /etc/passwd per a aquell usuari concret. Hi ha tota una sèrie d’alternatives de shells que es poden veure llistades a /etc/shells. Un dels intèrprets d’ordres més emprats és el Bash, evolució de l’original intèrpret sh.

La càrrega del shellBash dóna per finalitzat el sistema d’arrencada de Linux i la posada en marxa de l’entorn de serveis, i el sistema operatiu queda en espera de la introducció d’ordres per part de l’usuari.

Aturada del sistema

Ja hem vist que init gestiona les aturades del sistema amb els nivells 0 i 6:

  • Nivell d’execució 0: Para el sistema aturant els diferents processos configurats.
  • Nivell d’execució 6: Atura el sistema i el reinicia.

Tanmateix, disposem d’una ordre específica, shutdown, que ens proporciona funcionalitats addicionals.

Senyals d'aturada

En la seqüència de parada del sistema s’envia primer un senyal SIGTERM a tots els processos actius i, passats uns segons, un senyal d’aturada forçada SIGKILL.

Ordre shutdown

En definitiva, shutdown crida a init 0 o init 6, però accepta paràmetres com ara el temps de termini per a l’apagada o reinicialització del sistema i la possibilitat d’enviar missatges d’advertiment. La seva sintaxi és:

  1. shutdown <paràmetres><termini><missatge>

Vegeu les opcions de l’ordre en la taula.

Taula Opcions de l’ordre shutdown
opció Significat
-kNo atura el sistema sinó que envia un missatge d’advertiment a tots els usuaris.
-rReinicialització del sistema (reboot).
-hAturada del sistema (halt).
-fImpedeix l’execució de la utilitat d’anàlisi i correcció del sistema d’arxius (fsck) en l’arrencada.
-FForça l’execució d’fsck en l’arrencada.
-cCancel·la l’execució de shutdown.

Es pot especificar el termini de tancament del sistema de diferents maneres:

  • Una hora i un minut concret amb hh:mm
  • Passat un nombre de minuts concret amb +m
  • De manera immediata amb now (àlies de +0)
    En l’exemple es programa una represa per d’aquí a 10 minuts amb un missatge d’avís:
  1. # shutdown -r +10 "Represa del sistema en 10 minuts"
  2.  
  3. Broadcast message from root@ioc-Server (pts/1) (Sun Mar 1 17:58:54 2012):
  4. Reinicialització del sistema per manteniment en 10 minuts
  5. The system is going DOWN for reboot in 10 minutes!

Aquesta represa es pot cancel·lar des d’una altra consola d’arrel amb l’opció -c.

  1. # shutdown -c "represa cancel·lada"
  2.  
  3. Broadcast message from root@ioc-Server (pts/3) (Sun Mar 4 18:03:34 2012):
  4. reinicialització cancel·lada

Altres ordres de tancament del sistema que encara es conserven per garantir la compatibilitat cap enrere:

  • halt és equivalent a # shutdown -h now.
  • reboot és equivalent a # shutdown -r now.

Monitorització de processos a Unix/Linux

Per administrar i gestionar processos en Linux es poden fer servir directament ordres de consola, tot i que també és pot treballar des de l’entorn gràfic amb la utilitat de monitorització del sistema.

El directori virtual /proc

En arrencar, el nucli del sistema (kernel) posa en marxa un sistema d’arxius virtual /proc que emmagatzema informació que recull del sistema. El directori /proc està implementat a la memòria i no es guarda al disc dur. Les dades que conté són tant de naturalesa estàtica com dinàmica, és a dir, que varien al llarg de l’execució.

Directori virtual

Definim el directori /proc com a virtual perquè no està realment al disc dur, sinó que el nucli del sistema operatiu el crea dins de la memòria RAM.

Una de les característiques interessants del directori /proc és que hi podem trobar les imatges dels processos en execució amb tota la informació gestionada pel nucli del sistema. Cada procés es pot trobar en un directori etiquetat amb el seu identificador de procés /proc/PID_proces. Aquesta informació és útil per als programes de depuració o per a les mateixes ordres del sistema com ara ps o top, que la fan servir per veure l’estat en el qual es troben els processos.

D’altra banda, a /proc hi podem trobar també arxius amb informació sobre l’estat global del sistema com ara:

  • /proc/cpuinfo: informació sobre el processador. Per exemple, el tipus, fabricació, model i rendiment.
  • /proc/devices: llista de controladors de dispositiu configurats en el nucli que està funcionant actualment.
  • /proc/diskstats: conté informació estadística de les operacions d’entrada/sortida per cada dispositiu de disc.
  • /proc/dma: mostra quins canals de DMA (accés directe a memòria) s’estan utilitzant.
  • /proc/filesystems: llista dels sistemes d’arxius configurats dins del nucli.
  • /proc/ide: directori d’informació del bus IDE, característiques dels discos.
  • /proc/interrupts: mostra quines línies d’interrupció s’estan utilitzant i, per a cadascuna, un comptador de quantes n’hi ha hagut.
  • /proc/ioports: mostra quins ports d’entrada/sortida s’estan utilitzant.
  • /proc/loadavg: la mitjana de la càrrega del sistema expressada en tres indicadors que representen la mitjana de processos en marxa en el darrer minut, cinc minuts i quinze minuts.
  • /proc/meminfo: informació sobre la utilització de la memòria, tant la física com la d’intercanvi.
  • /proc/net: directori amb arxius d’informació d’estat sobre protocols de xarxa. Els fa servir l’ordre netstat.
  • /proc/partitions: conté el noms de les particions del sistema i la seva mida en blocs.
  • /proc/pci: dispositius PCI del sistema.
  • /proc/stat: diverses estadístiques sobre el nucli del sistema, com el temps que la CPU ha dedicat a diferents tasques, el nombre d’interrupcions ateses o el temps transcorregut des de l’arrencada del sistema.
  • /proc/version: la versió de nucli del sistema operatiu.

Tot i que els fitxers que es poden consultar a /proc acostumen a ser arxius de text de lectura fàcil amb l’ordre cat o amb qualsevol processador de textos, de vegades el format en dificulta la interpretació. És per això que hi ha altres ordres del mateix sistema que agafen aquesta informació i la presenten a l’usuari d’una manera més elaborada perquè l’entengui millor. Per exemple, l’ordre free llegeix el fitxer /proc/meminfo, i l’ordre uptime accedeix i presenta la informació de l’arxiu /proc/loadavg.

Línia d'ordres

El sistema operatiu Linux disposa de diferents ordres en l’entorn de consola de text per a la gestió i monitoratge de processos. Les podríem classificar en diferents apartats funcionals:

  • Monitorització de processos: ordres ps, pstree, pidof, time i top.
  • Prioritat dels processos: ordres nice i renice.
  • Ordres relacionades amb senyals: ordres kill, killall, nohup, disown, trap.
  • Execució diferida: ordres at, crontab.
  • Tasques en segon pla: directiva & i ordres jobs, fg i bg.
  • Altres ordres: wait, sleep.

A continuació detallarem les ordres de monitorització de processos.

Ordre ps

A la majoria de sistemes operatius de la família Unix, l’ordre ps (process status) permet visualitzar els processos en execució. Aquesta ordre està basada en la informació continguda en el directori virtual /proc i admet un gran nombre d’opcions que fins i tot varien en funció dels diferents formats de sintaxi:

  • Estil Unix: les opcions són lletres majúscules o minúscules precedides d’un guionet. Per exemple: ps -A.
  • Estil BSD: les opcions no porten guionet. Per exemple: ps r.
  • Estil GNU: les opcions fan servir noms llargs i porten doble guionet. Per exemple: ps – user.

Les opcions completes de ps es troben a les pàgines del manual.

  1. # man ps

Però per veure un resum de les opcions més comuns podem fer servir l’opció help en estil GNU:

  1. # ps –-help

El resultat es mostra a la figura:

Figura Resum de les principals opcions de l’ordre ps

Sigui quin sigui l’estil d’ordre utilitzat, depenent de les opcions invocades apareixeran diferents columnes amb informació sobre els processos. Les dades principals que apareixen en aquests camps estan resumides en la taula:

Taula Descripció dels camps més habituals de l’ordre ps
Camp Significat
PID Identificador del procés
PPID Identificador del pare del procés
UID Identificador de l’usuari propietari del procés
USER Nom de l’usuari propietari del procés
TTY Terminal associada al procés. Sense terminal associat apareix un ?
TIME Temps de CPU acumulat pel procés
CMD El nom de l’ordre que va iniciar el procés
SIZE Mida virtual de la imatge del procés
NI Prioritat nice assignada per l’usuari
%CPU Percentatge de CPU usat pel procés
%MEM Percentatge de memòria usat pel procés en relació a la memòria física
START Hora d’inici del procés
VSZ Memòria virtual en quilobytes
RSS Memòria resident en quilobytes que fa servir el procés
STAT Estat del procés com per exemple:
* R (running): en execució
* S (sleeping): procés bloquejat en espera d’un succés
* T (stopped): procés detingut però que es pot reiniciar
* Z (zombie): procés finalitzat però que roman a la memòria

Si no hi posem cap argument, només es mostraran aquells processos iniciats per l’usuari actual i que fan referència al terminal que aquest està utilitzant.

  1. # ps
  2. PID TTY TIME CMD
  3. 1532 pts/0 00:00:00 bash
  4. 1842 pts/0 00:00:00 ps

La primera columna mostra l’identificador del procés, la terminal associada al procés que en aquest cas es tracta del primer pseudoterminal (pts/0), atès que hem fet servir un terminal de l’entorn gràfic, el temps acumulat d’ús de CPU i finalment l’ordre que ha generat el procés.

Afegint algunes opcions (aux) en format BSD podem obtenir més informació (vegeu la figura).

  1. # ps aux

Figura Llistat de processos i informació obtinguda amb l’ordre ps aux

Per veure més informació, com per exemple els valors de prioritat (vegeu la figura):

  1. # ps -l

Figura Visualització dels valors de prioritat amb ps

Ordre pstree

L’ordre pstree mostra una llista de processos en forma d’arbre que segueix la jerarquia de processos Unix i que permet identificar fàcilment quin és el procés pare d’un altre.

  1. $ pstree
  2. init----NetworkManager
  3. |--3*[VBoxClient---{VBoxClient}]
  4. |--VBoxService---6*[{VBoxService}]
  5. |--acpid
  6. |--apache2---5*[apache2]
  7. |--atd
  8. |--avahi-daemon---avahi-daemon
  9. |--cron
  10. |--cupsd
  11. |--6*[getty]
  12. |--gnome-keyring-d---2*[{gnome-keyring-}]
  13. |--gnome-screensav
  14. |--gnome-settings-
  15. |--gnome-terminal----bash---pstree
  16. | |--bash--man-pager
  17. | |--gnome-pty-helpe
  18. | |--{gnome-terminal}

Analitzem la informació mostrada en aquest exemple. Podem veure que init és el pare de tots els processos, que hi han alguns dimonis coneguts en marxa (Apache, cron, CUPS, etc.), que tenim sis terminals en espera de login (6*[getty]). Al terminal gràfic (gnome-terminal) trobem que hi ha un parell de processos Bash en funcionament, i en un d’ells, la mateixa ordre pstree que genera l’arbre.

Ordre pidof

L’ordre pidof permet trobar els identificadors dels processos associats a una determinada ordre:

  1. # pidof init
  2. 1
  3. # pidof getty
  4. 1110 785 782 780 773 770

En l’exemple veiem que el procés init té PID=1 i també podem veure tots els PID de les sis consoles obertes.

Ordre time

Aquesta ordre permet executar qualsevol altra aplicació i enregistrar els recursos que ha emprat. Per defecte només presenta el temps real (estimat amb el rellotge del sistema) i el temps de CPU emprat tant en mode usuari com en mode sistema. Tanmateix, aquesta mateixa ordre executada amb privilegis de superadministrador i fent servir diferents modificadors pot subministrar més paràmetres d’informació.

  1. # time gedit
  2. real 0m13.289s
  3. user 0m1.380s
  4. sys 0m2.016s

Ordre sleep

Suspèn l’execució durant els segons especificats com a paràmetre.

  1. # sleep 20;echo "Han passat 10 segons"
  2. Han passat 10 segons

Ordre uptime

L’ordre uptime dóna l’hora del sistema, el temps que porta encès, la quantitat d’usuaris connectats i la càrrega mitjana del sistema durant l’últim minut, els últims cinc minuts i els últims quinze minuts.

  1. # uptime
  2. 11:51:25 up 58 min,3 users, load average: 1.38, 1.35, 0.96

Ordre vmstat

L’ordre vmstat dóna informació de l’estat de la memòria física, de la memòria virtual, de l’intercanvi entre memòria interna i disc (swapping), de les transferències de disc, les interrupcions i ús del processador. Admet l’ús de modificadors i permet monitoratge continuat (vegeu la figura).

Figura Resultat de l’ordre vmstat

La informació que mostra aquesta ordre és resumeix a la taula.

Taula Camps d’informació de l’ordre vmstat
Secció Descripció
Procs Processos en espera de ser executats ® i en estat d’espera (b)
Memory Memòria virtual (swpd), memòria lliure (free), memòria intermèdia (buff) i memòria cau (cache)
IO Blocs enviats i rebuts des de dispositius d’entrada/sortida
System Nombre d’interrupccions per segon (in) i nombre de canvis de context (cs)
CPU Percentatges de distribució de temps entre el mode usuari (us), mode sistema (sy) i temps ociós (id)

Ordre top

L’ordre top presenta la informació dels processos de manera dinàmica i interactiva, en temps real, amb una actualització per defecte cada tres segons, i ordenats pel percentatge d’ús de CPU (vegeu la figura).

  1. # top

Figura Visualització de la ordre de gestió de processos interactiva top

Com es veu al llistat, la primera línia d’informació és la mateixa que dóna l’ordre uptime. A continuació mostra informació dels processos en execució amb una sèrie de camps d’informació, semblants als obtinguts amb l’ordre ps però amb petites variacions, com podem veure a la taula.

Taula Descripció dels camps més habituals de l’ordre top
Camp Significat
PIDIdentificador del procés
USERNom de l’usuari propietari del procés
PRPrioritat del procés
NIPrioritat nice assignada per l’usuari
VIRTMemòria virtual en quilobytes
RESMemòria resident en quilobytes que fa servir el procés
SHRMemòria compartida
SEstat del procés
%CPUPercentatge de CPU usat pel procés
%MEMPercentatge de memòria usat en relació a la memòria física
TIMEHora d’inici del procés
COMMANDEl nom de l’ordre que va iniciar el procés

L’ordre top no només mostra la informació actualitzant les dades dinàmicament, també pot interactuar amb l’usuari, que pot actualitzar la informació, ordenar els processos per qualsevol camp d’informació o, el que és més important, finalitzar el procés enviant un senyal de kill o fins i tot canviar-li la prioritat.

La llista de les principals ordres de top es mostra a continuació, a la taula:

Taula Descripció de les ordres interactives de l’ordre top
Ordre Descripció
h o ?Mostra l’ajuda.
fPermet marcar com a visibles/ocults els diferents camps d’informació.
oConfigura l’ordre en el qual es presenten els camps d’informació.
FDefineix el camp d’ordenació del llistat de processos.
kFinalització d’un procés amb el senyal de kill.
rCanvia la prioritat d’usuari d’un procés (renice).
qSortir de l’entorn top.

Per a un llistat exhaustiu de les opcions i ordres de top, cal fer servir l’opció h o ? i s’obté la informació de la figura.

Figura Llistat de les principals opcions de top

Eines sysstat

El paquet sysstat és una col·lecció d’eines de monitorització de rendiment per a sistemes Linux. Proporciona dades instantànies de rendiment, que es poden emmagatzemar en arxius històrics. En entorns de servidor, aquestes dades proporcionen informació valuosa per detectar carències i colls d’ampolla del sistema.

L’ordre d’instal·lació és la següent:

  1. # apt-get install sysstat

Algunes de les eines que inclou aquest paquet són:

  • mpstat: recull informació del rendiment de cadascun dels processadors del sistema. Permet fer un monitoratge continuat i admet modificadors.
  • iostat: és una eina més completa que l’anterior, ja que a més de presentar estadístiques de la CPU, dóna informació dels dispositius d’entrada i sortida, les particions i els sistemes d’arxius.
  • pidstat: informació estadística dels processos de Linux.
  • SAR (system activity report): recull, enregistra i presenta informació sobre l’estat dels components principals del sistema (CPU, memòria, discs, interrupcions, interfícies de xarxa, consoles, kernel, etc.) i de la seva càrrega en temps real i de manera continuada. Emmagatzema les dades en els fitxers /var/log/saXX on XX és el dia del mes del monitoratge. Aquest fitxers permeten l’anàlisi a posteriori de la informació. SAR admet modificadors molt interessants com:
    • -P : dóna informació per a cada processador.
    • -r : dóna informació del rendiment de la memòria.
    • -B : dóna informació relativa a la paginació de la memòria.
    • -W : dóna informació relativa al swapping.
    • -d : dóna informació del rendiment de disc.
    • -n : dóna informació relativa a la xarxa.

Totes les ordres accepten com a paràmetre el nombre de mostres que volem capturar i l’interval entre mostres expressat en segons.

Aquest conjunt d’utilitats ens donen eines en l’àmbit de la monitorització de l’ús del processador i del seguiment de l’activitat dels processos. Vegem-ne un parell d’exemples:

Veure l'ús dels diferents processadors del sistema:

  1. # mpstat -P ALL
  2.  
  3. Linux 2.6.32-28-generic (desktop) 20/02/12 _i686_ (1 CPU)
  4.  
  5. 12:56:13 CPU usr %nice %sys %iowait %irq %soft %steal %guest %idle
  6. 12:56:13 all 2,51 1,19 14,45 0,42 0,27 0,10 0,00 0,00 81,05

Veure el percentatge d'ús dels processos més actius:

  1. # pidstat 1 2
  2.  
  3. Linux 2.6.32-28-generic (desktop) 26/04/11 _i686_ (1 CPU)
  4.  
  5. 13:00:09 PID %usr %system %guest %CPU CPU Command
  6. 13:00:10 984 0,00 1,72 0,00 1,72 0 Xorg
  7. 13:00:10 1357 0,00 0,86 0,00 0,86 0 wnck-applet
  8. 13:00:10 1868 0,00 3,45 0,00 3,45 0 firefox-bin
  9. 13:00:10 2508 2,59 5,17 0,00 7,76 0 pidstat
  10.  
  11. 13:00:10 PID %usr %system %guest %CPU CPU Command
  12. 13:00:11 984 1,01 5,05 0,00 6,06 0 Xorg
  13. 13:00:11 1868 0,00 3,03 0,00 3,03 0 firefox-bin
  14. 13:00:11 2323 0,00 1,01 0,00 1,01 0 gnome-terminal
  15. 13:00:11 2508 0,00 9,09 0,00 9,09 0 pidstat
  16.  
  17. Average: PID %usr %system %guest %CPU CPU Command
  18. Average: 984 0,47 3,26 0,00 3,72 - Xorg
  19. Average: 1357 0,00 0,47 0,00 0,47 - wnck-applet
  20. Average: 1868 0,00 3,26 0,00 3,26 - firefox-bin
  21. Average: 2323 0,00 0,47 0,00 0,47 - gnome-terminal
  22. Average: 2508 1,40 6,98 0,00 8,37 - pidstat

Entorn gràfic (monitor del sistema)

La mateixa eina gràfica del monitor del sistema, a més de la visualització en temps real dels recursos, disposa d’una pestanya on podem controlar els processos que s’estan executant i el consum de recursos del sistema que fan (vegeu la figura).

Figura Finestra de gestió de processos al monitor de sistema

Per a cada procés actiu en el sistema mostra la informació següent:

  • Nom del procés.
  • L’estat en què es troba el procés (adormit, parat, en execució).
  • El seu identificador (PID).
  • El percentatge d’ocupació de processador que està utilitzant.
  • La prioritat d’execució.
  • La quantitat de memòria que fa servir.

Seleccionant un d’aquests processos podem efectuar diferents accions:

  • Posar el procés en espera i rellançar-lo.
  • Aturar-lo de manera ordenada o immediata.
  • Canviar la seva prioritat d’execució.
  • Visualitzar el seu mapa de memòria.
  • Visualitzar els arxius oberts amb els quals treballa.

El monitor del sistema es pot configurar canviant l’interval de recollida de dades, els paràmetres de monitorització i el tipus de gràfic de presentació.

Anar a la pàgina anterior:
Més informació
Anar a la pàgina següent:
Activitats