ASO02 - Administración de Procesos Del Sistema - Contenidos

13/11/2016 ASO02_Contenidos
Administración de procesos del sistema.
Caso práctico

Ya se instauró el sistema en la empresa y ahora llega el momento de exprimir al máximo todas las prestaciones que nos
ofrece.
También hay que controlar que el uso que se haga de los equipos sea el correcto y que funcionen de la forma más eficaz
posible así que nos planteamos qué podemos hacer para que el sistema vaya bien.
Como primera medida vamos a proponer una administración de cada sistema desde el punto de vista de la gestión de sus
procesos. Atenderemos tanto a los sistemas Windows como a los Linux, ya que en nuestra empresa existen equipos con
ambas opciones.
La gestión de los procesos es uno de los roles asignados al sistema operativo. De todos los que desempeña, éste será quizás el más importante ya que los procesos se
encargan realmente de dar vida al sistema operativo.
Tras averiguar qué es un proceso y qué función desempeña en un sistema operativo hablaremos sobre los diferentes estados en los que podemos encontrarlo y qué
fases puede alcanzar.
Por otro lado, hablaremos de una de las claves en la eficiencia de un sistema operativo como es la planificación de los procesos y los principales mecanismos que
pueden adoptarse.
Como punto fuerte de la unidad trataremos aspectos interesantes sobre la gestión de procesos en el sistema operativo, desde el interfaz gráfico y desde la línea de
comandos, para sistemas Windows y para sistemas Linux.
http://fpadistancia.caib.es/pluginfile.php/150092/mod_resource/content/2/ASO02/ASO02_Web/index.html 1/24
Procesos.
Caso práctico

La administración de los procesos no es simplemente iniciar programas o detenerlos, sino que hay que tener una buena base
de cómo funciona el sistema operativo al nivel de los procesos, qué información se recoge en un proceso, qué estados
puede adoptar y cómo cambia entre ellos. Carlos, que no es ajeno a todo esto, identificará todo lo anterior y lo interpretará
adecuadamente para llevar a cabo una buena administración.
Un proceso es un programa o un fragmento de programa en ejecución.
Cada proceso necesita una serie de recursos, siendo el sistema operativo el encargado de proporcionárselos. En función del tipo de
proceso, los recursos necesarios pueden ser diferentes pero, por regla general, todos necesitan un espacio en memoria y un tiempo de
uso del microprocesador (CPU).
Cuando se crea un proceso, se le asocia un paquete de información sobre el denominado Bloque de Control de Proceso (BCP), que le
acompaña durante toda su vida. En este BCP se recogen datos del proceso como son:
Su estado actual.
Su PID (número identificador de proceso).
Valores de registros asociados a él, como el contador de programa, los punteros, acumuladores, etc.
Valores de los recursos asignados: espacio en memoria, archivos, E/S, etc.
Todos los procesos, desde su creación, tendrán la capacidad de comunicarse y sincronizarse con otros procesos y con recursos del
sistema. Este hecho da lugar a diferentes tipos de procesos:
Independientes: no se comunican con otros procesos. Estos tipos de procesos apenas existen.
Cooperativos: se comunican y sincronizan para realizar una actividad común.
Competitivos: necesitan hacer uso del mismo recurso y, por consiguiente, competirán por él.
En cualquier caso, la ejecución de los procesos exigirá concurrencia, cualidad que deberá gestionar el sistema operativo gracias a técnica denominada
multiprogramación, que permite que dos o más procesos puedan ejecutarse "a la vez".
De todos los procesos que se están ejecutando a la vez sólo uno tiene la "atención del usuario"; Este proceso se dice que está en primer plano y del resto se dice que
están en segundo plano. Es posible pasar un proceso de primer plano a segundo plano y viceversa.
Autoevaluación

¿Cuál de las siguientes afirmaciones es CORRECTA?

No todos los procesos que se crean en el sistema deben comunicarse entre sí.
Todos los procesos del sistema se recogen en el BCP.
Los procesos pueden estar en varios planos: primero, segundo, tercero, …
Todos los procesos del sistema son competitivos.
Estados de un proceso.
Un proceso, a lo largo de su vida, cambia de estado. En concreto, un proceso puede estar en uno de los siguientes estados:
Nuevo (new): Momento en el que se está creando el proceso.
Preparado (ready): Está esperando a que se le asigne la CPU (un procesador).
En ejecución (running): Se está ejecutando en la CPU.
Bloqueado o en espera (waiting): Está a la espera de que suceda un evento.
Terminado (terminated): Finaliza su ejecución. Muere.
Además de estos estados, en algunos sistemas también existe un estado denominado suspendido (suspend), que se produce
cuando un proceso se suspende y es desplazado a memoria secundaria. En esta situación, el proceso puede quedar a la espera de
un evento (waiting suspend) o suspendido temporalmente pero listo para ejecutarse (ready suspend).
El proceso puede cambiar de estado cuantas veces sea necesario, pero nunca puede estar en más de un estado a la vez.
El objetivo final de un proceso es procesarse, es decir, estar en ejecución durante el tiempo que sea necesario para ser procesado. Sin embargo, un procesador sólo
puede ejecutar un proceso a la vez. Este hecho es el que marca el paradigma de la gestión de procesos en el sistema operativo, mediante el cual se establecen los
mecanismos necesarios para que los diferentes procesos que compiten por la CPU puedan hacerlo de la forma más eficiente y beneficiosa para el sistema.
Autoevaluación

Señala la afirmación CORRECTA.

Un mismo proceso no puede encontrarse en más de un estado a la vez.
Un proceso no puede cambiar de estado tantas veces como necesite.
El proceso que está utilizando la CPU se dice que está en estado preparado.
El estado suspendido siempre deja al proceso a la espera de que suceda un evento.
Creación de procesos.
La creación de un proceso se hace a través de la llamada al sistema "crear proceso" desde otro proceso denominado proceso padre.
El proceso resultante se denomina proceso hijo y es prácticamente una réplica de su padre.
Como se puede deducir, debe existir un proceso inicial con la capacidad de pedir al sistema que se cree un proceso. Este proceso
creador es de vital importancia en los sistemas operativos y constituye la raíz del árbol de procesos.
Los procesos se marcan en su creación con un número único llamado identificador de proceso (PID). Salvo el proceso raíz, todos los
procesos llevan dos números:
El PID que lo identifica a él.
El PPID que identifica a su padre.
Después de que un proceso genera un hijo, ambos continúan ejecutándose desde el punto en el que se hizo la creación.
Autoevaluación

¿Cuántos números identificadores lleva un proceso?

Todos llevan uno: el PID.
Todos llevan uno: el PPID.
Todos llevan dos: el PID y el PPID.
El proceso padre lleva uno y el resto dos.
Terminación de procesos.
Generalmente un proceso finaliza su ejecución cuando pasa al estado terminado y le pide al sistema que lo elimine utilizando la
llamada al sistema "exit".
Los procesos hijo pueden ser eliminados cuando el proceso padre quiera. Esto se denomina matar un proceso y es habitual cuando:
El hijo se excede en el uso de los recursos asignados.
La tarea que se asignó al hijo ya no se necesita.
El proceso padre quiere terminar y el sistema operativo no permite que los hijos continúen sin el padre.
Hay que prestar especial atención al hecho de que un proceso no debería terminar hasta que todos sus hijos lo hagan. Sin embargo,
las operaciones sobre procesos no son fiables al 100% y se pueden dar anomalías en la gestión de los procesos:
Procesos huérfanos.
Se denominan así a los procesos que quedan en el sistema cuando su padre ha finalizado. Cuando esto sucede, el PPID del proceso (para sistemas UNIX)
pasa a ser el PID del proceso inicial.
Procesos zombies.
Son procesos que han finalizado pero su padre los mantiene como vivos. Este tipo de procesos suelen ser fruto de errores de programación o de fallos del
sistema. Al contrario que los procesos huérfanos, los zombies no son adoptados por el proceso inicial sino que tienden a eliminarse para evitar el consumo de
recursos.
Autoevaluación


Un proceso no puede matarse si está en estado de ejecución.
Si un proceso tiene hijos no puede matarse sin que mueran también sus hijos.
Al contrario que un proceso huérfano, un proceso zombie no es adoptado por el proceso padre.
El proceso zombie no suele ser fruto de errores de programación o fallos del sistema.
Modelos de proceso.
La forma en que un sistema se organiza para gestionar sus procesos da lugar al modelo de proceso. Los sistemas operativos actuales pueden seguir los siguientes
modelos:
Modelo de 2 estados.
Es el modelo más simple. El proceso, tras crearse pasa al estado noejecutado, a la espera de entrar en ejecución. Cuando entra en ejecución, puede ejecutarse
por completo (y morir) o hacerlo por partes.
El modelo anterior es ideal para procesos sin prioridades y que siempre estén listos para ejecutarse. Sin embargo, esto no siempre sucede y algunos pueden
necesitar esperar por un suceso (que esté listo un archivo, que esté disponible un dispositivo de E/S,..). Para ello, en este nuevo modelo se divide el estado no
ejecutado en dos: preparado y bloqueado, cada uno con su propia cola de procesos.
Para mejorar la gestión de los procesos, al modelo anterior se le añaden dos estados extremos: nuevo y terminado, encargados de controlar los procesos
existentes en el sistema (en nuevo se dan de alta y en terminado se dan de baja).
Los procesos a la espera de ser ejecutados residen en memoria principal (en las colas de preparado y bloqueado). Para evitar que la RAM se colapse se hace una
variación en el modelo anterior, creando unas colas similares a las ya existentes pero en memoria secundaria. Esto da lugar a los estados suspendidobloqueado y
suspendidopreparado. Entre las correspondientes colas se produce una operación de intercambio cada vez que se pasa un proceso de una a otra. Hay que tener
en cuenta que esta operación consume recursos y tiempo de CPU.
Cambio de contexto.
Como hemos visto, un proceso, a lo largo de su vida, puede pasar por diferentes estados. El cambio de un estado a otro no es trivial y tanto la forma como el tiempo para
hacerlo marcarán la eficiencia del sistema.
El proceso pasa gran parte de su vida esperando ser ejecutado. Cuando sale de ese estado sin haber finalizado su ejecución (porque es expropiado a otro estado,
suspendido o bloqueado) se espera que la próxima vez que alcance el estado de ejecución continúe donde lo había dejado.
Para que esto sea posible se aplica una operación conocida como cambio de contexto.
El cambio de contexto consiste en interrumpir la ejecución de un proceso para comenzar o seguir con otro.
De forma un poco esquemática, en el cambio de contexto:
El proceso saliente guarda todos sus valores asociados en el BCP.
Se guardan los valores de los registros y direcciones de memoria implicados en el proceso en ese momento.
Se cambia de estado el proceso.
Se cambia de estado al proceso entrante.
Se cargan los valores de los registros y direcciones de memoria asociados al proceso.
Todas estas operaciones son gestionadas y supervisadas por el procesador, lo cual quiere decir que en el tiempo que dura el
cambio de contexto no se puede ejecutar ningún otro proceso.
Cuando el cambio de contexto se hace sin salir de memoria principal, el tiempo y los recursos empleados no son excesivos; pero en los cambios de contexto entre
memoria principal y secundaria la situación cambia, siendo más lenta y costosa.
La técnica de cambiar de contexto es útil cuando se quiere dar tiempo de ejecución a todos los procesos, pero un uso excesivo del cambio de contexto puede ser
contraproducente ya que el procesador estaría más tiempo ocupándose de las acciones asociadas a los cambios de contexto que a la ejecución de los procesos que se
intercambian.
Autoevaluación

Señala la afirmación que sea CORRECTA referente al cambio de contexto.

No se basa en el concepto de concurrencia.
Puede llevarse a cabo con un único proceso, aunque no es recomendable.
Se puede hacer sólo en memoria principal.
Se puede hacer sólo en memoria secundaria, aunque es muy costoso.
Planificación de procesos.
Caso práctico

Trabajar con procesos no es una tarea fácil porque, entre otras cosas, no son objetos que puedan visualizarse simplemente.
La forma en que trabajan no es trivial y Carlos se pregunta qué mecanismos seguirán para coordinarse de forma tan
armoniosa. Investigando descubre que el sistema tiene una especie de plan para organizarlos y que todos participen.
Los procesos no se ejecutan en cualquier orden, sino que siguen un orden establecido por el sistema operativo. La forma en la que el
sistema operativo gestiona los procesos es lo que se conoce como planificación y la herramienta que lo hace recibe el nombre de
planificador (en inglés, scheduler).
La misión del planificador es:
Garantizar que cada proceso tiene acceso al recurso en su justa medida.
Explotar el recurso, manteniéndolo ocupado el máximo tiempo posible.
Reducir todo lo posible los tiempos de espera de los diferentes procesos.
La dificultad de la planificación radica en que no se puede saber, a priori, qué procesos estarán compitiendo por un recurso ni
tampoco el contexto que se generaría en caso de concedérselo. Por ello, para controlar el acceso de los procesos a los recursos, el planificador puede seguir dos tipos
de política:
Política no expropiativa: Una vez que el proceso accede al recurso, se permite que haga uso de él hasta que ya no lo necesite.
Política expropiativa: Se proporciona acceso al recurso para un proceso pero, en un determinado momento, se puede ceder el recurso a otro proceso diferente,
para lo cual se le retirará el acceso al primero (pasando a estado suspendido, bloqueado o preparado, según corresponda).
La política expropiativa es mucho más justa cuando existen procesos muy diferentes, ya que permite, por regla general, que ningún proceso acapare el recurso. Por otro
lado, es más compleja y consume más recursos (en las expropiaciones), por lo que habrá que sopesar cuál es más adecuada en cada situación concreta.
Autoevaluación

Señala la afirmación que sea CORRECTA.

La política expropiativa es más eficiente que la no expropiativa.
La expropiación de un proceso conllevará obligatoriamente un cambio de contexto.
El planificador no se encarga de que la CPU esté ocupada el mayor tiempo posible.
El planificador de procesos se instala como un complemento del sistema operativo.
Niveles de planificación.
La planificación es demasiado compleja como para realizarse en una única fase. Los sistemas operativos, en general, disponen
de tres niveles de planificación, cada uno con su planificador:
Planificación a largo plazo (nivel alto): Llamada también "planificación de admisión", ya que es la que determina qué
trabajos se admiten para su procesamiento y, por consiguiente, se cargan en memoria.
Planificación a medio plazo (nivel medio): Gestiona el estado de suspensión de los procesos. Esta operación recibe
el nombre de intercambio (o swapping). Es muy típica en sistemas Linux, donde incluso existe una partición específica para este fin.
Planificación a corto plazo (nivel bajo): También llamada despachador (dispatcher). Estipula qué procesos en estado preparado pasarán a ejecución. Debe ser
una planificación sencilla y breve, ya que se ejecutará muchas veces.
Algoritmos de planificación.
Los planificadores funcionan aplicando algoritmos de gestión. De entre todos los existentes, destacamos estos:
Algoritmo por prioridades.
A cada proceso se le asigna una prioridad según la cual se ejecutan.
Este algoritmo tiene el inconveniente de que los procesos con prioridad baja pueden relegarse en el tiempo.
Algoritmo FCFS (Fisrt Come First Served).
Utiliza una estructura de cola en la que los procesos se ejecutan según entran en ella.
Aquí, los procesos demasiado largos harían esperar al resto de procesos hasta que termine de ejecutarse.
Algoritmo SJF (Shortest Job First).
Intenta reparar el problema de FCFS pero, en este caso, los procesos largos se ven desfavorecidos y pueden retrasarse en su ejecución continuamente.
Una vez que el proceso entra en ejecución, se ejecuta por completo, aunque haya en cola procesos más cortos.
Algoritmo SRT (Shortest Remaining Time).
Es una versión expropiativa de SJF, donde se tiene en cuenta también los procesos de la cola.
En el caso de que existan procesos en cola más cortos, se expropia el proceso en ejecución y se ejecutaría el de la cola.
Algoritmo RR (Round Robin).
Utiliza una organización en cola circular: Los procesos se ejecutan en cola y cuando acaba el último se sigue con el primero. A cada proceso se le asigna un
tiempo de uso de CPU denominado cuanto.
El problema de este algoritmo está en la fijación del cuanto, ya que cuantos demasiado largos degeneran en FCFS y cuantos demasiado cortos disminuirían el
rendimiento por los continuos cambios de contexto de los procesos.
Como se puede observar, cada algoritmo tiene sus ventajas y sus inconvenientes. En la práctica se utiliza un sistema híbrido de varias colas en las que se aplican
diferentes algoritmos según las necesidades y el momento concreto con la finalidad de optimizar los recursos y los tiempos de respuesta del sistema.
Hilos de ejecución.
Caso práctico

La realidad es que ahora, con equipos tan modernos y con procesadores potentes y de varios núcleos eso de trabajar con
procesos queda un poco obsoleto y se impone el uso de unos mecanismos llamados hilos. Carlos había oído en alguna
ocasión hablar de los hilos pero no había trabajado con ellos, así que va a investigar cómo los hilos pueden ayudarle en la
administración de los procesos del sistema.
El manejo de los procesos, como se ha podido ver, es bastante complejo. Como alternativa a la visión general del proceso como ente básico surgió hace relativamente
poco tiempo el concepto de hilo (thread).
Un hilo es la parte de un proceso que puede ser ejecutada de forma independiente.
De esta manera, un proceso estará constituido por al menos, un hilo, existiendo la posibilidad de que tenga varios.
La capacidad (del sistema operativo) de mantener varios hilos de ejecución dentro del mismo proceso se conoce con el nombre
de multihilo. Si no existe, entonces se habla de monohilo.
En general, todos los sistemas operativos modernos son multihilo.
Trabajar a nivel de hilos tiene grandes ventajas sobre hacerlo a nivel de procesos:
Al tratarse de entidades mucho más ligeras, los tiempos empleados para su manejo (creación, terminación, cambio de estado y de contexto) son mucho menores
respecto a los procesos.
El tiempo para crear un hilo es mucho menor que para crear un proceso.
Autoevaluación

¿Cuál de las siguientes afirmaciones sobre sistemas operativos modernos es CORRECTA?

Un proceso no puede tener más de un hilo de ejecución.
Un mismo hilo puede abarcar más de un proceso.
Dos hilos de un mismo proceso no pueden estar en diferente estado.
Un proceso puede estar constituido por un único hilo de ejecución aunque el sistema sea multihilo.
Estructura de un hilo.
De forma muy simple podemos decir que un hilo sigue la siguiente estructura:
Bloque de control del hilo: Similar al BCP pero específico para el hilo.
Pila de ejecución: Estructura que contiene la información de estado del hilo (punteros, registros, etc.).
Teniendo esto en cuenta y aplicándolo a los diferentes tipos de procesos:
Procesos monohilo.
En este tipo de procesos no existe el concepto de hilo como tal y la representación del proceso es similar a la explicada al comienzo de la unidad.
Procesos multihilo.
Sólo existe un BCP y un espacio de direcciones asociadas al proceso pero, para cada hilo, hay un bloque de control y una pila de ejecución separados.
Dentro de un mismo proceso los hilos comparten código, datos y recursos del sistema.
Los hilos están pensados para que no sean independientes entre sí. De este modo, es posible que un hilo pueda acceder a la pila de otro hilo y modificarla. En esta
interacción y en el tiempo que se emplea en ella (mucho menor que la comunicación entre procesos) reside, fundamentalmente, su potencialidad.
Estados de un hilo.
Los hilos siguen el diagrama de 3 estados que se explicó para los procesos.
Sobre los hilos se pueden realizar las siguientes operaciones:
Crear: en general, al crear un proceso se crea también un hilo para ese proceso que se colocará en la cola de
preparados. De ese hilo pueden salir nuevos hilos (hilos hijos).
Terminar: cuando se termina un hilo, se libera todo lo asociado a él (el bloque y su pila).
Bloquear: sucede cuando un hilo necesita esperar a que suceda un evento. Se comporta como si fuera un proceso,
pasando al estado bloqueado y cediendo el procesador a otro hilo. Puede darse el caso de que el bloqueo de un hilo conlleve el bloqueo de todo el proceso, es
decir, de todos los hilos que componen el proceso.
Desbloquear: ocurre cuando el evento por el que se esperaba sucede y el hilo pasa a la cola de preparados. Al igual que antes, si un hilo bloqueaba todo su
proceso, el desbloqueo de un hilo puede conllevar el desbloqueo de todo el proceso, es decir, de todos los hilos que componen el proceso.
Como se ve, los hilos tienen un comportamiento estacional similar a los procesos. Este hecho unido a que los hilos son mucho más ligeros que los procesos, hace que
los tiempos de creación, terminación y cambios de estado (y de contexto) sean mucho más reducidos, con lo que se gana en eficiencia.
Autoevaluación

¿Cuál de los siguientes cambios de estado de un hilo es CORRECTO?

De preparado a ejecución.
De preparado a bloqueado.
De bloqueado a ejecución.
Interrupciones y excepciones.
Caso práctico

Todo va bien hasta que llegan los problemas, y resulta que ahora aparecen tareas que se paran a medias y errores en
ejecuciones de procesos. Para tratarlos habrá que conocerlos antes, así que Carlos va a identificar estas incidencias y a
adoptar los mecanismos que sean necesarios para cada caso.
Durante el transcurso ordinario de la ejecución de procesos pueden darse dos situaciones especiales:
Interrupción.
Se produce cuando se quiere que la CPU deje de ejecutar el proceso en curso y pase a realizar otra función de quien hace la
interrupción. Cuando la CPU realiza esa función se dice que está atendiendo la interrupción.
Las interrupciones pueden darse a dos niveles:
Nivel de software: El usuario realiza una llamada al sistema (para hacer uso de un recurso del núcleo).
Nivel de hardware: Un dispositivo (hardware) requiere la atención de la CPU para ejecutar su driver.
Cuando se produce una interrupción se pasa el control al sistema operativo, quien salva el contexto del proceso que se estaba
ejecutando y se analiza la interrupción. Las interrupciones están catalogadas y el sistema operativo dispone de rutinas especiales para manipular cada tipo de
interrupción. Una vez se ha atendido la interrupción la CPU continúa con su anterior tarea.
Excepción.
La excepción es un tipo de interrupción provocada por la propia CPU a causa de un error en la ejecución del proceso en activo como puede ser la realización de
operaciones no permitidas, códigos de operación mal expresados, direcciones de memoria fuera de rango, etc.
El tratamiento de una excepción es similar al de la interrupción, con la salvedad de que las excepciones, a menudo, no continúan el proceso con fallo sino que lo
abortan.
Autoevaluación

¿Cuál de las situaciones puede generar más fácilmente pérdida de datos?

Interrupción.
Excepción.
Demonios.
Caso práctico

La primera vez que Carlos oyó hablar de demonios haciendo referencia a sistemas operativos, pensó en cualquier cosa
menos en su relación con los procesos. Ahora resulta que un sistema operativo tiene demonios y que son importantes para
su funcionamiento. Consciente de esto, Carlos inicia la búsqueda de los demonios del sistema para su administración.
Existe un tipo muy particular de proceso que recibe el nombre de demonio.
Un demonio es un proceso que se ejecuta en segundo plano sin necesidad alguna de interacción con el usuario para llevar a cabo su tarea.
En sistemas Windows los demonios se les conocen más comúnmente como servicios, pues su finalidad es ofrecer un servicio al
usuario.
Los demonios no disponen de interfaz, ni gráfica ni textual, ya que no necesitan comunicarse con el usuario. Tampoco hacen uso de
los dispositivos de E/S comunes para notificar resultados o errores. En su lugar, vuelcan toda esta información en un archivo LOG
o la comunican a otros demonios encargados de recopilar este tipo de datos.
Los demonios pueden iniciarse, detenerse y reiniciarse:
Iniciar un demonio: # <ruta del demonio> start
Parar un demonio: # <ruta del demonio> stop
Reiniciar un demonio: # <ruta del demonio> restart
Los servicios (demonios Windows) permiten, además, ser pausados y reanudados.
Debes conocer

En el siguiente documento se explica cómo realizar las diferentes operaciones sobre los servicios tanto desde interfaz como desde línea de comandos.
Operaciones básicas sobre servicios Windows.
Autoevaluación

¿Qué orden utilizarías en Windows para iniciar el servicio "remoteregistry" que habilita el registro remoto?

# remoteregistry start
sudo remoteregistry start
net start remoteregistry
Service remoteregistry start
Gestión de procesos en Windows.
Caso práctico

La tarea diaria del administrador de sistemas no es otra cosa que eso, administrar sistemas. Carlos debe hacerlo a diario
con todos los equipos que tiene a su cargo. Ahora toca trabajar con los equipos que tienen un sistema operativo Windows,
así que los reconocerá y hará una gestión eficiente de los procesos.
La gran parte de las operaciones de gestión de procesos en Windows se hace desde el Administrador de tareas. Recordemos que esta
herramienta es accesible desde la combinación de teclas [Ctrl]+[Alt]+[Esc].
Para nuestro propósito, nos vamos a centrar en las pestañas Procesos y Servicios.
Procesos.
A través de esta pestaña podemos gestionar los procesos que están activos en el sistema. Por defecto sólo se muestran los
procesos iniciados por el usuario pero podemos visualizar todos activando la opción "Mostrar procesos de todos los
usuarios".
También es interesante señalar que la información que se ofrece sobre los procesos es mucho más de la que aparece en la
pestaña por defecto. Para incluir o modificar las columnas de datos de cada proceso iremos a Ver > Seleccionar columnas y
escogeremos los campos que nos convengan.
Para cada proceso podemos realizar, entre otras, las siguientes acciones (haciendo clic derecho sobre él):
Terminar el proceso: pasa el proceso a estado terminado.
Finalizar el árbol de procesos: pasa a estado terminado el proceso y todos los procesos relacionados con él.
Establecer su prioridad: permite cambiar la prioridad del proceso, existiendo varios niveles a elegir.
Establecer afinidad: da la opción de asociar el proceso a una CPU (en el caso de equipos con varias CPUs).
Ir al servicio: nos lleva a la pestaña Servicios y resalta aquellos que están asociados a este proceso.
Servicios.
Mediante esta pestaña podemos administrar los servicios del sistema. En el listado aparecen todos los servicios, tanto si están
en activo como si no. No es posible cambiar la información que se muestra sobre el servicio, como sucedía con los procesos.
Sobre cada servicio se pueden realizar estas acciones (clic derecho sobre él):
Iniciar el servicio: pasa el servicio a estado "En ejecución".
Detener el servicio: pasa el servicio a estado "Detenido".
Ir al proceso: nos lleva a la pestaña Procesos y resalta aquel al que está asociado.
Windows también permite terminar procesos a través del comando taskkill (ver la sintaxis con la orden taskkill /?). Un usuario

estándar puede eliminar procesos asociados a él. Para eliminar procesos del sistema o de otros usuarios es necesario tener
privilegios de administrador.
Para saber más

En el siguiente vídeo se resume lo más importante de lo explicado en este apartado.
Gestión de procesos en Windows 7.
ASO02_01_Gestión de ...
Gestión de procesos en Linux.
Caso práctico

La empresa tiene equipos Windows y también equipos Linux, así que ahora toca administrar los procesos de los equipos
Linux. Carlos sabe que dispondrá de herramientas gráficas pero también debe ser consciente de que existe un buen número
de comandos para utilizar desde la consola que le ayudarán en muchas de las tareas típicas de gestión de procesos.
Linux no hace una distinción tan clara como Windows entre procesos y demonios. De hecho, la gestión de procesos y la de demonios
sigue las mismas directrices.
Los sistemas Linux siempre se han destacado por la permisividad de manipulación de los objetos del sistema, por lo que disponemos de
un gran abanico de herramientas (sobre todo a nivel de consola) para gestionar los procesos.
Antes de abordar la gestión de los procesos en sistemas Linux conviene tratar un concepto bastante interesante: El plano de un proceso.
Cuando el usuario está interactuando con un proceso, se dice que este proceso está en primer plano. Cuando el proceso se ejecuta "en
silencio", sin necesidad de que el usuario interactúe con él se dice que el proceso está en segundo plano. Un ejemplo típico de
procesos en segundo plano son los demonios.
Sólo un proceso puede estar en primer plano en un momento dado. Por el contrario, en segundo plano pueden existir varios procesos a la vez.
Por otro lado, un proceso puede pasarse de primer plano a segundo plano, y viceversa, cuantas veces se desee.
A continuación hablaremos de los mecanismos que podemos aplicar para gestionar procesos en Linux utilizando su interfaz gráfico y posteriormente profundizaremos un
poco más hablando de las operaciones disponibles por línea de comandos.
Autoevaluación


Un proceso puede estar a la vez en primer y en segundo plano.
En primer plano puede haber más de un proceso.
En segundo plano puede haber más de un proceso.
Un proceso puede pasar de primer a segundo plano, pero no al revés.
Gestión de procesos por interfaz gráfico.
Recordamos que Linux proporciona una herramienta similar al Administrador del sistema de Windows llamada Monitor del
sistema. De esta herramienta nos detendremos en la pestaña Procesos.
Esta pestaña muestra, por defecto, todos los procesos (incluidos los demonios) que están asociados al usuario. A través de la
opción Ver del Monitor del sistema podemos seleccionar otro criterio de visualización, pudiendo mostrar todos los procesos del
sistema o solamente aquellos que están en estado activo.
Para cada proceso, como sucedía en Windows, se pueden aplicar una serie de operaciones (con clic derecho sobre el proceso
en cuestión), de entre las que destacamos estas:
Detener el proceso: pasa el proceso a estado suspendido.
Continuar el proceso: reanuda un proceso que estaba detenido.
Finalizar el proceso: pasa el proceso a estado terminado.
Matar el proceso: pasa el proceso a estado terminado de forma inmediata.
Cambiar la prioridad: permite variar la prioridad del proceso siendo 0 la prioridad normal y pudiendo oscilar entre los valores 20 (máxima prioridad) y 20 (mínima
prioridad).
En la opción Ver también podemos activar la funcionalidad Dependencias. Al hacerlo, en el listado también se muestran los procesos hijo. Aquellos procesos que tienen
procesos hijo asociados aparecen con un triángulo a su izquierda sobre el que se puede pinchar para mostrarlos/ocultarlos. Sobre los procesos hijo se pueden realizar las
mismas operaciones que sobre los procesos padre.
Gestión de procesos por línea de comandos.
Las principales acciones que pueden realizarse sobre procesos desde la línea de comandos son estas:
Mostrar información sobre los procesos.
El comando ps (abreviatura de Process Status) muestra un listado con el estado de los procesos.
El comando pstree es una variante de ps en la que los procesos se muestran en forma de árbol.
El comando jobs se utiliza para mostrar los procesos que se están ejecutando en primer y en segundo plano.
Debes conocer

En este documento se explica el uso de los comandos para mostrar información de los procesos:
Comandos Linux para información de procesos. (0.68 MB)
Cambiar el estado de los procesos.
El comando kill permite enviar señales a los procesos para cambiar su estado. La señal por defecto de este comando es terminar (matar) el proceso, de ahí su
nombre.
Debes conocer

En este documento se explica el uso de los comandos para cambiar el estado de los procesos:
Comandos Linux para cambiar el estado de procesos. (0.36 MB)
Cambiar la prioridad de los procesos.
El comando nice se emplea para cambiar la prioridad de un proceso cuando se inicia su ejecución. Por defecto el valor de la prioridad es 0. Sólo los usuarios
root tienen privilegios para asignar prioridades negativas.
El comando renice permite cambiar la prioridad de un proceso sin necesidad de detenerlo.
Debes conocer

En este documento se explica el uso de los comandos para cambiar la prioridad de los procesos:
Comandos Linux para cambiar la prioridad de procesos. (0.38 MB)
Cambios de plano de los procesos.
El operador & se utiliza para pasar un proceso a segundo plano.
El comando nohup se usa para pasar un proceso a segundo plano haciéndolo inmune a los hangup (cuelgues).
Cuando un proceso está detenido, se puede utilizar los comandos fg y bg para lanzarlo en primer plano o en segundo plano, respectivamente.
Debes conocer

En este documento se explica el uso de los comandos para cambiar el plano de los procesos.
Comandos Linux para cambiar el plano de procesos. (0.33 MB)
Inicio del sistema. Niveles de ejecución.
Caso práctico

Cuando se está trabajando con sistemas operativos a un nivel como este, es conveniente conocer ciertos mecanismos
como pueden ser aquellos que adopta el propio sistema para iniciarse. Carlos mantiene que es un tema importante porque
conocer cómo funciona una herramienta te ayuda a identificar dónde falla, cuando falla. A nivel de procesos el sistema
operativo sigue una secuencia de inicio que debería ser conocida de cara a poder gestionarse o incluso modificarse.
La puesta en marcha del sistema operativo es una secuencia de operaciones que se varía de unos sistemas operativos a otros. Todos tienen
en común la ejecución de una serie de procesos que constituirán la base del sistema. Estos procesos posteriormente residirán en memoria y
generarán nuevos subprocesos para ofrecer otras funcionalidades.
De entre todos los sistemas operativos disponibles, vamos a estudiar cómo es el proceso de inicio para sistemas Windows y para sistemas
Linux.
Es conveniente resaltar que el proceso de inicio del sistema operativo, incluso tratándose del mismo tipo de sistema operativo, puede variar
de unas versiones a otras e incluso es dependiente del tipo de procesador para el que se instala (x86 o x64).
Inicio del sistema en Windows.
La secuencia de inicio se produce primordialmente en segundo plano, constando de cinco fases:
Secuencia previa al inicio.
Comienza cuando se enciende el equipo, antes de que se inicie el sistema operativo, y en ella tiene lugar el POST y el
paso a la carga y ejecución del MBR.
Secuencia de inicio.
Se ejecuta el gestor de arranque (BOOTMGR) y se seleccionará el sistema operativo para iniciar. Posteriormente se hará
una detección del hardware instalado.
Secuencia de carga del núcleo.
Se invoca al archivo WINLOAD.EXE para que cargue el archivo NTOSKRNL.EXE, que está considerado como el núcleo del sistema operativo. También se carga
el archivo HAL.DLL, capa intermedia entre el núcleo de Windows y el hardware.
Tras la carga de HAL se realiza la carga de la clave del registro HKEY_LOCAL_MACHIME\SYSTEM. El contenedor SELECT determina qué controlador debe
cargar y el contenedor CONTROLSET proporciona los datos de configuración utilizados para controlar el sistema (controladores, servicios,…).
Secuencia de inicio del núcleo.
Coincide con la aparición del logotipo de Windows. Realmente, durante este tiempo se llevan a cabo varias tareas entre las que destacamos la creación de la clave
HARDWARE en el registro con los datos recogidos en la fase de detección de hardware y la inicialización de los servicios y de los controladores de dispositivos.
Esta secuencia finaliza con la inicialización del subsistemas y servicios de orden superior y el lanzamiento del subsistema Win32 (en sistemas x64 el subsistema
es WoW), encargado de habilitar, entre otros, el interfaz de usuario, que comienza con el proceso WINLOGON.
Secuencia de inicio de sesión.
WINLOGON inicia la autoridad de seguridad local (LSASS.EXE), momento en el que aparece la pantalla de identificación de usuario (según esté configurada).
Inicio del sistema en Linux. Niveles de ejecución.
La secuencia de inicio en sistemas Linux sigue un esquema muy similar al explicado para Windows:
Secuencia previa al inicio.
Comienza cuando se enciende el equipo, antes de que se inicie el sistema operativo, y en ella tiene lugar el POST y el
paso a la carga y ejecución del MBR.
Secuencia de inicio.
Se ejecuta el gestor de arranque (GRUB, LILO,…) y se seleccionará el sistema operativo para iniciar. Posteriormente se
hará una detección del hardware instalado.
Secuencia de carga del núcleo.
El gestor de arranque se encargará, al final de su ejecución, de cargar el kernel en memoria.
Secuencia de inicio del núcleo.
Se comienza la ejecución del kernel descomprimiéndose a sí mismo. Tras esta operación se realizan operaciones básicas como pueden ser la detección de la
CPU y otros dispositivos, la inicialización del sistema gestor de memoria, el montaje del sistema de archivos,… Como última operación de esta fase se llama al
proceso padre init (con UID 0).
Secuencia de inicio de sesión.
A partir de ahora todas las operaciones dependerán del proceso init. Este proceso lanza los procesos contenidos en el fichero /etc/inittab, que contiene las
instrucciones para crear lo que se denominan las getty (entradas que especifican la forma en que un usuario debe loguearse). Al menos debe existir una getty que
se encargue de preguntar por el usuario y lance el proceso /bin/login. Posteriormente se ejecuta el comando /etc/rc.sysinit para realizar un inicio básico del
sistema, ejecutando los procesos asociados al nivel de ejecución establecido.
El nivel de ejecución (runlevel), determina qué grupo de procesos se van a ejecutar cuando se inicie el sistema en ese nivel.
Existen varias convenciones en cuanto al número de runlevels, siendo lo más frecuente asumir que existen 7, de los que el 0, el 1 y el 6 están reservados. El resto de
niveles pueden personalizarse.
Todos los servicios del sistema tienen un script en /etc/init.d. Por otro lado, cada runlevel tiene recopilados enlaces simbólicos de los scripts que se ejecutarán cuando el
usuario inicie en ese nivel en el archivo /etc/rcX.d, donde X es el número del runlevel.
Anexo. Licencias de recursos.
Licencias de recursos utilizados en la Unidad de Trabajo.
Recurso (1) Datos del recurso (1) Recurso (2) Datos del recurso (2)
Autoría: Phillie Casablanca.
Autoría: Rock in rolo Onlus.
Licencia: CCBY.
Licencia: CC BYSA.
Procedencia:
Procedencia: http://www.flickr.com/photos/rockinrolo/3546316154/
http://www.flickr.com/photos/philliecasablanca/
sizes/s/in/photostream/
2437181190/
Autoría: Sergio Scotta.
Autoría: José Carlos Gallego.
Licencia: CC BYNCSA.
Procedencia: http://www.flickr.com/photos/sergeen/4909883654
Procedencia: Elaboración propia.
/sizes/m/in/photostream/
Autoría: jamonderana.
Autoría: mrjoro.
Procedencia:
Procedencia: http://www.flickr.com/photos/mrjoro/89187454/
http://www.flickr.com/photos/64380281@N03/
sizes/m/in/photostream/.
5861854646/
Autoría: José Carlos Gallego. Autoría: José Carlos Gallego.
Licencia: CC BYNCSA. Licencia: CC BYNCSA.
Procedencia: Elaboración propia. Procedencia: Elaboración propia.
Licencia: CC BYSA.
Procedencia: http://www.flickr.com/photos/rockinrolo/3545507967
/sizes/s/in/photostream/
Autoría: The lebers.
Licencia: CC BYSA.
Procedencia:
http://www.flickr.com/photos/thelebers/4746433373/ Procedencia: Elaboración propia.
sizes/m/in/photostream/
Licencia: CC BYSA.
Autoría: UTPL VIA Comunicaciones. Autoría: Emeryjl.
Procedencia: Procedencia: http://www.flickr.com/photos/emeryjl/506966918/
http://www.flickr.com/photos/utpl/3197027769/ sizes/m/in/photostream/
Autoría: Rock in rolo Onlus. Autoría: riptheskull.
Licencia: CC BYSA. Licencia: CC BYNCSA.
Procedencia: Procedencia:
http://www.flickr.com/photos/rockinrolo/3546315696/ http://www.flickr.com/photos/vintagehalloweencollector/259425237/
sizes/s/in/photostream/ sizes/m/in/photostream/
Autoría: Microsoft.
Licencia: CC BYSA.
Licencia: Copyright cita.
Procedencia: http://www.flickr.com/photos/rockinrolo/
Procedencia: Captura de pantalla Windows 7.
3545509907/sizes/s/in/photostream/
Autoría: Microsoft.
Licencia: CC BYSA.
Licencia: Copyright cita.
Procedencia: Captura de pantalla Windows 7.
Autoría: Martin Gommel.
Autoría: Debian.
Licencia: CC BYNCND.
Licencia: GNU.
Procedencia:
http://www.flickr.com/photos/kwerfeldein/1934917078/ Procedencia: Captura de pantalla de Debian.
sizes/m/in/photostream/
Autoría: Universidad de Navarra.
Licencia: CC BYND.
Procedencia: http://www.flickr.com/photos/hexmar/
2034486793/
Autoría: Juan Hernando.
Procedencia:
http://www.flickr.com/photos/fraccionirreducible/ Procedencia: Elaboración propia.
5198648290/

ASO02 - Administración de Procesos Del Sistema - Contenidos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ASO02 - Administración de Procesos Del Sistema - Contenidos

Hochgeladen von

Copyright:

Verfügbare Formate

13/11/2016 ASO02_Contenidos

Windows también permite terminar procesos a través del comando taskkill (ver la sintaxis con la orden taskkill /?). Un usuario

Das könnte Ihnen auch gefallen