• Bienvenido

    Este blog nació la madrugada entre el 10 y el 11 de Septiembre de 2007 mientras instalaba Windows y Debian en una máquina que acababa de formatear para comenzar de nuevo.
    Predendo dejar plasmada mi experiencia con todos los 'experimentos' informáticos que llevo a cabo para que cualquiera haga uso de estos conocimientos que a mi me resultan realmente enriquecedores. Colgaré noticias interesantes e iré redactando artículos sobre materias fundamentales en el mundo de la informática como UNIX o Critografía. Mucho Google y mucha Wikipedia
    Comenta lo que quieras en el articulo que mas te haya interesado, cualquier comentario es totalmente bienvenido.
    Un saludo.
    JxXx
  • RSS Mountain Weekends

    • Vietnam: diario de viaje (XIV) agosto 23, 2015
      29/05/2015 19:27 Aeropuerto de HueEstamos en el aeropuerto de Hue esperando para coger el avión que nos va a llevar a Hanoi. Estos 2 últimos días han sido... especiales, diferentes al resto del viaje. El mejor resumen es que nos han intentado timar todo el rato, casi todo el mundo y en varias ocasiones lo han conseguido. Tomándonos una cervecita (Huda) tampo […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (XIII) agosto 23, 2015
      Voy a resumir muchísimo el día de hoy porque tengo muchísimas fotos y porque ya estoy muy cansado. Hemos desayunado fuerte en el hotel y hemos hecho un día de paseo exhaustivo por la zona centro de Hoi An. Lo hemos visto todo y, siento ser así de sincero, hemos acabado hasta los cojones porque todo el mundo nos ha querido vender algo. Si vienes a Hoi An prep […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (XII) agosto 10, 2015
      27/05/2015 21:52Hoy os escribo desde el Vinh Hung 3 Hotel, un hotel bastante próximo a la ciudad antigua de Hoi An en el que hemos decidido dormir dos noches de capricho, tampoco es que sea excesivamente caro pues nos está costando 40$ la noche, pero dentro de lo que hemos visto estos días es bastante lujoso, dentro del edificio, en el patio central ocupándo […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (XI) agosto 10, 2015
      26/05/2015 10:55Estamos en el aeropuerto de Phu Quoc, ya tenemos más o menos organizados los días que nos quedan de vieje, bueno a grandes rasgos, pero eso os lo cuento después, voy a seguir con la historia.Cuando dejé de escribir recogimos y nos montamos en la moto, siguiendo por el camino de la costa oeste hacia el norte y ya en el norte, tras pasar varios […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (X) agosto 10, 2015
      25/05/2015 Entre las 12 y las 13Tras mucho tiempo en moto por media isla hemos dado con un chiringuito y escribo a pocos metros del mar tomándome una Bia Saigon muy fría. Voy a contaros lo de las inmersiones. Con Cristina y el resto de la tripulación de Flipper, una pareja de rusos y una pareja de americanos, Dave y Rachel, que viven y trabajan de profesores […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (IX) agosto 9, 2015
      25/05/15 20:50Debería hacerle una foto al cuaderno para que lo vierais porque la calidad de la carretera era medio buena pero ha habido un momento en el que nos hemos salido a un camino de tierra y he tenido que dejar de escribir porque era imposible. Me he propuesto dedicarle el tiempo que haga falta hasta poner el diario al día, pero antes de continuar qui […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (VIII) agosto 9, 2015
      24/05/15 08:23Como de costumbre, primero os cuento dónde ando y luego sigo contando cosas. Estamos en un autobús rumbo al sur de Phu Quoc, vamos a hacer submarinismo tres parejas y el staff de Flipper. Ayer dejé de escribir para despegar y luego no me apeteció seguir escribiendo y se me va acumulando el trabajo.Tras ver el templo de la literatura decidimos p […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (VII) junio 24, 2015
      23/5/2015 11:37Ayer dejé de escribir porque ya nos íbamos y no me dio tiempo a contar nuestro día por Hanoi, me quedé en que habíamos quedado para cenar. Salimos y estaba lloviendo, pero nos estaba esperando un taxi al que no le hizo mucha gracia nuestro trayecto de poco más de un kilómetro. Nos dejó en la puerta de un bar en el que estaban Alfonso (que tamb […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (VI) junio 16, 2015
      21/5/2015 8:35Estoy hecho polvo, la noche ha sido movida, ha hecho mucho calor pero el aire acondicionado no ha dejado de sonar en ningún momento. A las cinco menos algo hemos llegado a Hanoi, hemos recogido nuestras cosas, nos hemos despedido de Eric (!mierda, no tengo ni su email ni nos hemos hecho una foto con él!) y hemos salido a la estación. Yo estaba […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (V) junio 13, 2015
      Me acabo de subir a una litera y no sé qué tal voy a poder escribir, ¿por dónde iba? A ver, souvenirs, mujeres albinas con gorros rojos, comida picante con arroz y palillos y niños bañándose... ah! un perro pidiendo comida con ojos tristes.  Después de comer seguimos andando y Tsum nos metió en una casa y nos contó un poco la historia de la familia y otras c […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (IV) junio 10, 2015
      19/05/2015 por la mañana tempranoHoy es el cumpleaños de Ho Chi Minh, nacido en 1890, el que fue gobernante y lider de la resistencia contra los poderosos de Vietnam y Estados Unidos. El guía que está en nuestro camarote en el tren nos está contando un montón de datos histñoricos de Vietnam y de Ho Chi Minh, estudió en Rusia y luego volvió a Vietnam y unió a […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (III) junio 6, 2015
      18/05/2015 12:38Imposible escribir… sigo luego en el tren… 18/05/2015 20:57 Estoy tumbado en la litera de arriba de un camarote de un tren de camino a Sapa. El otro día escribí en un autobús camino a la Bahía de Ha-Long y esta mañana he intentado escribir en el autobús de vuelta pero me ha sido imposible. La excursión a la bahía de Ha-Long ha sido espectacul […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (II) junio 3, 2015
      17-05-2015 - 07:46No voy a adelantar desde donde escribo hoy, de momento solo voy a decir que no es un lugar muy cómodo para escribir porque se mueve todo.Bueno, ayer nos bajamos del avión y llovía como si lo fueran a prohibir. Justo antes de salir por la aduana del aeropuerto de Hanoi entregamos los pasaportes, los papeles con nuestros datos, las fotos y la […]
      Juan Sin Miedo
    • Vietnam: diario de viaje (I) junio 2, 2015
      Hoy comienzo a transcribir mi diario de viaje, bueno, nuestro diario de viaje porque aunque ésta vez casi todo lo he escrito yo todo lo que estos días iré publicando, lo que se cuenta en este diario, nos pertenece a los dos. Así empieza éste relato con nuestras aventuras y desventuras, esperamos que os guste y que toméis nota si alguna vez pensáis en viajar […]
      Juan Sin Miedo
    • Expedición al Matterhorn 2014 julio 16, 2014
      Durante la última semana he trascrito el relato de nuestro viaje, relato que he escrito durante las muchísimas horas de coche que supuso el retorno a casa. El relato ha gustado mucho y he recibido mensajes tando de amigos y familiares como de contactos, amigos de amigos, de Facebook, dándome, dándonos, la enhorabuena por la expedición y diciendo que les esta […]
      Juan Sin Miedo
    • Expedición al Matterhorn 2014. EPÍLOGO julio 16, 2014
      Como atestigua el medio cuaderno escrito durante lo que llevamos de vuelta a casa nos han pasado muchas cosas durante este viaje. Los tres volvemos un poco mas viejos, un poco mas sabios y un poco mas amigos. El alpinismo no es sólo llegar a la cumbre, una de las primeras lecciones que se aprenden, alpinismo es disfrutar de un viaje largo y difícil,  de la s […]
      Juan Sin Miedo
    • Expedición al Matterhorn 2014. ESCALAR SOBRE EL MEDITERRANEO julio 16, 2014
      07/07/2014"El séquito se quitó el saquito sequito."Oigo gente paseando, bicicletas también. Es muy temprano y me duele la cabeza, tengo una resaca cojonuda, creo que me pasé con los gin tonics.El lugar que habíamos elegido para dormir la noche anterior no era el mejor, desde luego, estábamos muy cerca de las casas y llamábamos bastante la atención […]
      Juan Sin Miedo
    • Expedición al Matterhorn 2014. DESTINO INCIERTO julio 16, 2014
      06/07/201406:30 - Sigue lloviendo, ¡vaya tela! Me doy la vuelta en el saco y veo que los tres acabamos de abrir los ojos, nos hemos despertado a la vez. Miramos fuera... ¡Joder, sigue lloviendo! "Casi mejor seguir durmiendo" - Pensé. Ninguno dijimos nada pero los tres pensamos lo mismo... Y a las 10 de la mañana dejó de llover y empezó a salir el s […]
      Juan Sin Miedo
    • Expedición al Matterhorn 2014. LAS FIEBRES DEL MONT BLANC julio 15, 2014
      05/07/2014Amaneció lloviendo (¡jooooooooder!) pero a las 10 despejó un poco y empezamos a preparar los macutos muy tranquilamente y las 12:30 o una salimos hacia el pueblo y allí nos comimos un kebab buenísimo antes de coger el teleférico. La estación intermedia estaba nublada, había nubes justo por encima nuestro y no vimos el sol hasta quedarnos a ras de l […]
      Juan Sin Miedo
    • Expedición al Matterhorn 2014. RUMBO A CHAMONIX julio 13, 2014
      04/07/2014Desayunamos muy tranquilamente y sacamos y ordenamos todo, desmontamos la tienda y volvimos a cargar el coche (tetris mode on), pagamos el camping y cogimos carretera hacia Chamonix.En la frontera con Francia nos volvieron a parar. ¿He dicho ya que el coche de Borja es muy cantoso? Nos sacaron del coche y revolvieron todo de muy malas maneras. Nos […]
      Juan Sin Miedo
  • septiembre 2007
    L M X J V S D
        Oct »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
  • RSS Google: ciencia y tecnología

  • RSS 20 minutos de tecnología

    • Ha ocurrido un error; probablemente el feed está caído. Inténtalo de nuevo más tarde.
  • RSS HISPASEC

    • Ha ocurrido un error; probablemente el feed está caído. Inténtalo de nuevo más tarde.
  • RSS VNUNET

    • Ha ocurrido un error; probablemente el feed está caído. Inténtalo de nuevo más tarde.
  • RSS BarraPunto

Curso de Unix (VI)

6.- PROCESOS

6.1 INTRODUCCIÓN

6.1.1 Evolucion de un proceso

Cuando un usuario está en su cuenta, le atiende el intérprete de comandos (shell), que es un proceso con un cierto identificador que puede averiguarse mediante el comando de usuario ps -f (la opción -f genera un árbol con las dependencias entre procesos).

Cuando el usuario solicita ejecutar un comando, como por ejemplo who para ver cuáles son los otros usuarios conectados al sistema, es necesario que nazca un nuevo proceso que soporte la ejecución de dicho comando. Cuando el shell (proceso padre) recibe la cadena ”who”, ejecuta la llamada al sistema operativo fork(), para crear un proceso hijo que es una copia idéntica a él mismo (shell) en lo que se refiere al ejecutable y a una parte del entorno. Obsérvese que el PPID (Parent PID) del proceso hijo es el PID del proceso padre. Así pues, hay dos procesos disjuntos, shell y who, que ejecutan lo mismo: el intérprete de comandos. A continuación el proceso padre se queda esperando con la llamada al sistema operativo wait() hasta que su hijo se ejecute. Mientras tanto el proceso hijo ejecuta la llamada exec() para cambiarse a si mismo su código ejecutable, con lo que sustituye el código del intérprete de comandos por el ejecutable binario del comando de usuario who , que corresponde al fichero /bin/who. A partir de este momento, el proceso hijo está ejecutando el comando de usuario who , y no el intérprete como había sucedido hasta ahora. Cuando el proceso hijo concluye su ejecución, ejecuta la llamada exit() que envía una señal signal() al proceso padre, la cual le despierta y permite continuar su ejecución mostrando el símbolo de espera de nuevo comando (normalmente: > o $ en la pantalla del terminal).

Llamadas al sistema para la creación y terminación de procesos

Las llamadas al sistema que existen en Unix con respecto a procesos son:

  • fork() permite crear un nuevo proceso que inicialmente es una copia exacta del proceso que ha realizado la llamada.

  • exec() permite ejecutar un bloque de código en el proceso actual, sobrescribiendo todo lo que hubiera en dicho proceso actual.

  • exit() señaliza o notifica el fin de la ejecución de un proceso hijo al proceso padre que deberá estar esperando con wait().

  • wait() bloquea el proceso llamante hasta que se recibe una señal o notificación generada con exit().

6.1.2 Generación de los procesos del sistema

Mediante la descripción dada en el apartado Evolución de un proceso, queda explicada la genealogía de procesos en UNIX. Tan solo falta un pequeño detalle: > cómo ha nacido el intérprete de comandos ?. Cuando el ordenador arranca el sistema operativo, se ejecuta el fichero ejecutable kernel cuya misión es cargar el núcleo del sistema operativo en memoria. El núcleo es el primer proceso del sistema, y es padre de si mismo, puesto que su PID=PPID=0.

La misión del núcleo es controlar los recursos de el ordenador, por lo que delega el nacimiento de nuevos procesos en uno de sus hijos: init. Para cada uno de los terminales datos de alta en el ordenador y que es ese instante están usándose (tienen un usuario pulsando sus teclas) init crea un proceso hijo en el que se ejecuta el programa getty que solicita la conexión. Cuando ésta se obtiene, el mismo proceso se transforma en el programa login que solicita el nombre de usuario y la contraseña (si esta fue establecida). Si ambas informaciones son correctas, este proceso se convierte en el intérprete de comandos.

procesos.png

Mediante el comando ps puede comprobarse la genealogía de los procesos del sistema. Los parámetros cambian dependiendo de la versión de UNIX.

6.1.3 Ejecución de procesos en segundo plano

Cuando ejecuto una orden en línea de órdenes del tipo $orden1&, se ejecutan dos llamadas al sistema fork(): una para poder ejecutar orden1 y otro para crear una copia exacta de la shell para poder introducir otra orden.

6.2 DEFINICION DE PROCESO

Proceso : Instancia de un programa en ejecución. Hay que distinguir entre proceso y orden porque una orden puede dar lugar a la aparición de varios procesos. Un proceso es la suma de tres “cosas”:

Programa + Recursos + Estado

A la suma de estas tres “cosas” también se le llama IMAGEN DE UN PROCESO, y está representado por:

CÓDIGO

ZONA DE DATOS

PILAS

ATRIBUTOS

 

CÓDIGO Programa en forma no dinámica.
ZONA DE DATOS Zona donde almacena los datos.
PILAS Permite utilizar funciones.
ATRIBUTOS Describen todo el proceso. Es el Bloque de Control del Proceso (PCB).

En el PCB está toda la información que necesita el Sistema Operativo para tomar decisiones respecto a los dispositivos, memoria, etc.

Esta imagen normalmente se almacena en memoria virtual (una parte en disco y otra en memoria principal). El PCB siempre está en memoria principal.

6.2.1 CONTENIDO DEL PCB

Consta de varios elementos:

  • MAPA DE ESTADO DE DIRECCIONES: especifica que bloque de memoria está utilizando un determinado proceso.
  • RECURSOS: especifica el conjunto de recursos que tiene asignado un proceso.
  • PRIORIDAD DEL PROCESO: prioridad de ejecución de un proceso. Todos los procesos tienen una prioridad asignada por defecto para efectos de planificación, pero se puede cambiar.
  • ESTADO DEL PROCESO: valor del estado en el que se encuentra el proceso en cada instante.
  • PID (Identificador del Proceso): es un identificador único para cada proceso de un sistema. Es un valor numérico. Además del PID del proceso se registra el PPID (Parent PID) que es el PID del proceso padre. En Unix todo proceso tiene un padre siempre. Esta relación de parentesco no es vinculante: si le pasa algo al proceso padre no le afecta a los procesos hijos.
  • UID: Identificador de usuario propietario. En Unix todos los procesos los ejecuta un usuario, que no tiene por qué ser una persona. Hay usuarios especiales del sistema como adm o sys.
  • GID: grupo principal del usuario.

Hay veces que también se registra el terminal desde el cual el usuario ha sido creado el proceso.

 

 

6.3 ELCONTROL DE PROCESOS EN UNIX . ORDENES BASICAS

Como sabemos, UNIX es un sistema operativo multitarea, por lo que en todo momento es normal que encontremos más de un proceso ejecutándose y por lo tanto residente en memoria principal.

El comando que averigua cuales son los procesos que se están ejecutando en un instante determinado es : ps (Process Status):

Sintaxis: ps [parámetros]

El comando ps genera una lista con información sobre el estado de los procesos. Por defecto (sin opciones) la lista se limita a los procesos creados en el shell actual. La opción -a presenta los procesos de todos los usuarios. La opción -x lista los procesos en background que están corriendo pero que fueron creados en sesiones anteriores. La opción -r restringe la salida a los procesos que están corriendo. La opción -u informa extensamente acerca de todos los procesos que hemos seleccionado con el resto de las opciones. La información presentada es la siguiente:

psopt.png

Dónde el campo STAT toma los siguientes valores en función de si el proceso está:

statopt.png

En el caso de que STAT tenga una de las letras anteriores seguida de la letra N significa que la prioridad actual del proceso ha sido modificada con el comando nice . Si sigue una W, significa que el proceso está “swapped out”. Esto quiere decir que el proceso se está ejecutando, pero sus páginas de código se han escrito en el disco para dejar espacio en la memoria de la computadora para que otro proceso se puede ejecutar.

Existen procesos que no se pueden matar con kill porque cambian su PID dinámicamente.

time

Sintaxis: time orden [argumentos]

time ejecuta la orden especificada y muestra por la salida de errores estándar:

1. tiempo transcurrido en el sistema mientras se ejecutaba la orden.
2. tiempo consumido en la ejecución de la orden.
3. tiempo empleado por el sistema para la ejecución de la orden (llamadas al sistema, …).

$ time who
chan pty/ttys0 Oct 24 16:33
real 0m0.42s
user 0m0.07s
sys 0m0.07s

sleep

Sintaxis: sleep segundos Suspende la ejecución durante los segundos especificados como parámetro. Se usa para ejecutar una orden después de un cierto tiempo.

$ sleep 20; echo Han pasado 20 segundos

6.4 MECANISMOS DE COMUNICACIÓN ENTRE PROCESOS

Aunque en UNIX existe un amplio conjunto de herramientas que permiten intercambiar información entre procesos, a través de la Bourne shell sólo se suministra un conjunto reducido de éstas: tuberías, señales y valores de retorno.

6.4.1 Tuberías o pipelines

Las tuberías o pipelines son una herramienta de comunicación entre procesos que permiten conectar la salida estándar de un proceso con la entrada estándar de otro. Así todo lo que el proceso (productor) envíe a su salida estándar será tomado por el otro proceso (consumidor) como entrada en el mismo orden en que se generó la información.

La forma de indicar que se quiere emplear una tubería para comunicar dos o más procesos es la siguiente:

$ productor | consumidor
$ orden_1 | orden_2 |orden_3 | …

Ejemplo:

$ banner “hola” | write so25
La salida de la orden banner es utilizada para enviar un mensaje al usuario so25

6.4.2 Valores de retorno

Todo proceso que finaliza devuelve un número entero entre 0 y 255 que representa la causa por la que terminó:

0: terminación correcta del proceso. Representa un valor lógico verdadero cuando se usa dentro de una comparación o iteración. Cualquier otro valor distinto de 0 se considera como falso.

 

 

 

  • 1: indica terminación anormal del proceso (fallo).
  • 129 … 160: El proceso terminó como consecuencia de una señal. Restando 128 al valor de retorno se obtiene el código de la señal que terminó el proceso.

La variable de entorno ? mantiene el valor de retorno de la última orden ejecutada.

Ejemplo:
$ date 02251295
date: bad conversion
$echo El valor de retorno de la última orden fue: $?
El valor de retorno de la última orden fue: 2

6.4.3 Señales

Los procesos pueden enviarse interrupciones software, señales. El conjunto de señales lo maneja el gestor de señales. El número y tipo de señales viene impuesto por el sistema operativo y cada una de ellas será empleada en un caso concreto siendo su número la única información que realmente se transmite entre los procesos cuyo significado dependerá de la interpretación del programador.

 

 

 

Como indica la palabra interrupción, este tipo de llamadas son producidas por el kernel o por otro proceso de forma inesperada y tiene como finalidad parar o desviar el curso normal de las instrucciones que se ejecutan. Una señal puede ser recibida por un proceso si este incurre en un error en coma flotante, si se produce un error de acceso a memoria, si se intenta acceder a una dirección de memoria fuera de su segmento de datos, etc.

 

Como anteriormente se dijo, el número y significado de las señales depende del tipo de sistema operativo Unix que se tenga instalado. En el fichero de cabecera signal.h están definidas todas las señales, número y nombre.

 

 

 

Comportamiento.

Cuando un proceso recibe una señal, puede tratarla de tres formas diferentes:

1.- Ignorar la señal, con lo cual no tiene efecto.

2.- Invocar a la rutina de tratamiento correspondiente al número de señal. Esta rutina no la codifica el programador, sino que la aporta el kernel y normalmente tiene como fin el terminar el proceso que recibe la señal. En algunos casos, antes de eliminar al proceso, el kernel se encarga de generar en el directorio de trabajo actual del proceso un fichero llamado core que contiene un volcado de memoria del contexto del proceso. Analizando dicho fichero se podrá saber en qué punto terminó el proceso y por qué motivo se le envió la señal.

3.- Invocar a una rutina que se encarga de tratar la señal y que ha sido creada por el programador. Esta rutina establecerá un mecanismo de comunicación entre procesos o modificará el curso normal del programa. En estos casos, el proceso no va a terminar a menos que la rutina de tratamiento indique lo contrario.

 

Conjunto de señales básicas.

 

Cada señal tiene asociado un número entero positivo, que es lo que se intercambia cuando un proceso envía una señal a otro. Se pueden clasificar las señales en los siguientes grupos:

 

a) Señales relacionadas con la terminación de procesos.

b) Señales relacionadas con las excepciones inducidas por los procesos. Por ejemplo, el intento de acceder fuera del espacio de direcciones virtuales, los errores producidos al utilizar números en coma flotante, etc.

c) Señales relacionadas con los errores irrecuperables originados en el transcurso de una llamada al sistema.

d) Señales originadas desde un proceso que se está ejecutando en modo usuario. Por ejemplo, cuando un proceso envía una señal a otro, etc.

e) Señales relacionadas con la interacción con el terminal. Por ejemplo, pulsar la tecla break.

 

f) Señales para ejecutar un programa paso a paso. Son usadas por los depuradores.

A continuación, se van a describir las 19 señales que toman como base la mayoría de los sistemas operativos Unix.

 

SIGHUP (1) Hangup. Esta señal se envía a todos los procesos de un grupo cuando su líder de grupo termina su ejecución. También se envía cuando un terminal se desconecta de un proceso del que es terminal de control. La acción por defecto de esta señal es terminar la ejecución del proceso que la recibe.

 

SIGINT (2) Interrupción. Es enviada cuando en medio de un proceso se pulsa las teclas de interrupción (Ctrl + c). Por defecto se termina la ejecución del proceso que recibe la señal.

 

SIGQUIT (3) Salir. Similar a SIGINT, pero es generada al pulsar la tecla de salida (Ctrl + \). Su acción por defecto es generar un fichero core y terminar el proceso.

 

SIGILL (4) Instrucción ilegal. Es enviada cuando el hardware detecta una instrucción ilegal. En los programas escritos en C suele producirse este tipo de error cuando se maneja punteros a funciones que no han sido correctamente inicializados. Su acción por defecto es generar un fichero core y terminar el proceso.

SIGTRAP (5) Trace trap. Es enviada después de ejecutar cada instrucción cuando el proceso se está ejecutando paso a paso.

 

SIGIOT (6) I/O trap instruction. Es enviada a los procesos cuando se detecta un fallo hardware.

 

SIGEMT (7) Emulator trap instruction. Advierte de errores detectados por el hardware.

 

SIGFPE (8) Error en coma flotante. Es enviada cuando el hardware detecta un error en coma flotante, como el uso de número en coma flotante con un formato desconocido, errores de overflow o underflow, etc.

 

SIGKILL (9) Kill. Esta señal provoca irremediablemente la terminación del proceso. No puede ser ignorada ni tampoco se puede modificar la rutina por defecto. Siempre que se recibe se ejecuta su acción por defecto, que consiste en terminar el proceso.

 

SIGBUS (10) Bus error. Se produce cuando se intenta acceder de forma errónea a una zona de memoria o a una dirección inexistente. Su acción es terminar el proceso que la recibe.

 

SIGSEGV(11) Violación de segmento. Es enviada a un proceso cuando intenta acceder a datos que se encuentran fuera de su segmento de datos. Su acción por defecto es terminar el proceso.

 

SIGSYS (12) Argumento erróneo en una llamada al sistema. Si uno de los argumentos de una llamada al sistema es erróneo se envía esta señal.

 

SIGPIPE (13) Intento de escritura en una tubería de la que no hay nadie leyendo. Esto suele ocurrir cuando el proceso de lectura termina de una forma anormal. De esta forma se evita perder datos. Su acción es terminar el proceso.

SIGALRM(14) Alarm clock. Cada proceso tiene asignados un conjunto de temporizadores. Si se ha activado alguno de ellos y este llega a cero, se envía esta señal al proceso.

 

SIGTERM(15) Finalización software. Es la señal utilizada para indicarle a un proceso que debe terminar su ejecución. Esta señal no es tajante como SIGKILL y puede ser ignorada. Lo correcto es que la rutina de tratamiento de esta señal se encargue de tomar las acciones necesarias antes de terminar un proceso (como, por ejemplo, borrar los archivos temporales) y llame a la rutina exit. Esta señal es enviada a todos los procesos cuando se produce una para del sistema. Su acción por defecto es terminar el proceso.

 

SIGUSR1(16) Señal número 1 de usuario. Esta señal está reservada para el usuario. Su interpretación dependerá del código desarrollado por el programador. Suelen emplearse para sincronización de procesos. Ninguna aplicación estándar va a utilizarla y su significado es el que le quiera dar el programador en su aplicación. Por defecto termina el proceso que recibe.

 

SIGUSR2(17) Señal número 2 de usuario. Su significado es idéntico al de SIGUSR1.

 

SIGCLD (18) Muerte del proceso hijo. Es enviada al proceso padre cuando alguno de sus procesos hijos termina. Esta señal es ignorada por defecto.

 

SIGPWR (19) Fallo de alimentación. Esta señal tiene diferentes interpretaciones. En algunos sistemas es enviada cuando se detecta un fallo de alimentación y le indica al proceso que dispone tan sólo de unos instantes de tiempo antes de que se produzca una caída del sistema. En otros sistemas, esta señal es enviada, después de recuperarse de un fallo de alimentación, a todos aquellos procesos que estaban en ejecución y que se han podido rearrancar. En estos casos, los procesos deben disponer de mecanismos para restaurar las posibles pérdidas producidas durante la caída de la alimentación.

 

Enviar una señal.

Para enviar una señal desde un proceso a otro o a un grupo de procesos, se emplea la llamada kill (pid, sig). Pid identifica al conjunto de procesos a los que se le desea enviar la señal. Pid es un número entero y algunos de los distintos valores que puede tomar tienen los siguientes significados:

 

Pid > 0 Es el PID del proceso al que se le envía la señal.

Pid = 0 La señal es enviada a todos los procesos que pertenecen al mismo grupo que el proceso que la envía.

 

 

Sig es el entero que representa la señal que se quiere enviar. Si sig vale 0 (no existe una señal con tal identificador (señal nula)), se efectúa una comprobación de la validez del pid, es decir, si ese proceso existe, pero no se envía ninguna señal.

Si el envío se realiza satisfactoriamente, kill (pid, sig) devuelve 0; en caso contrario devuelve -1.

6.5 PRIORIDAD DE EJECUCIÓN Y VALOR “nice”

Cuando hay más de un proceso en el estado “listo para ejecutar”, el kernel le asigna el uso de la CPU al de mayor prioridad en ese momento. En el caso de Unix esta prioridad varía dinámicamente. Las diferentes versiones de Unix utilizan diferentes algoritmos de planificación del uso de la CPU (algoritmos de scheduling), pero en todos los casos tienen características similares:

– procuran ser justos con los diferentes procesos
– procuran dar buena respuesta a programas interactivos

Para eso, los algoritmos consideran parámetros como cuanto uso de CPU ha hecho el proceso recientemente, si pasa mucho tiempo dormido a la espera de un evento de teclado (sería un proceso interactivo), etc..
El administrador del sistema o el usuario dueño de un proceso pueden influir en el algoritmo de scheduling a través del llamado valor nice. Este es un número que se asigna a cada proceso e indica que tan “nice” es el proceso para con los demás.
Este valor es considerado por el algoritmo de scheduling de manera que un proceso con valor nice alto estará en desventaja frente a otro con valor nice menor a la hora de decidir a quien asignar la CPU. Como ejemplo veamos el algoritmo utilizado por alguna versión de unís

P = min + nice + (0.5 x recent)
Donde P indica la prioridad dinámica (a menor P mayor prioridad) y recent es una medida de cuanto ha recibido la CPU el proceso recientemente. Recent se calcula de la siguiente forma:

* Inicialmente vale 0
* Al final de cada time slice (aprox. 10 milisegundos) recent se incrementa en 1 para el proceso que está usando la CPU
* Una vez por segundo se divide por dos el valor recent para todos los procesos
Normalmente el valor nice se hereda del proceso padre. El dueño del proceso o el propio proceso pueden elevar su valor nice (menor prioridad). El superusuario puede modificar el valor nice de todos los procesos a gusto.
El valor del número nice puede variar entre -20 y +20, siendo por defecto 0.
En System V en cambio los valores posibles van de 0 a 39, siendo 20 el valor por defecto.
Se puede modificar el valor nice por defecto en el momento de lanzar un programa , con el comando nice, o posteriormente utilizando el comando renice.

6.5 PLANIFICACION DE TAREAS

 

 

La planificación de la ejecución de los comandos resulta útil para tareas que requieren un uso intensivo de los recursos del sistema cuando la carga de trabajo de éste sea ligera o para ejecutar rutinariamente comandos a horas determinadas. Por ejemplo, puede programar la impresión de un archivo largo para la medianoche o la eliminación diaria de los archivos temporales del directorio inicial.

at(1)

El comando at ejecuta los comandos en el directorio inicial a la hora que usted especifique.

crontab(1)

El comando crontab ejecuta los comandos en el directorio inicial a intervalos especificados regularmente.

batch

 

Para poder utilizar los comandos crontab o at, el administrador del sistema debe configurar antes determinados archivos que permiten que el sistema le conceda permiso para ejecutar dichos comandos.

Hay dos archivos, que se llaman at.allow y at.deny y se ubican en el directorio /usr/lib/cron, que determinan si usted puede utilizar el comando at. Si su nombre aparece en at.allow, puede utilizarlo.

Si el archivo at.allow no existe, el sistema comprueba si su nombre está en el archivo at.deny. En caso afirmativo, se le denegará el acceso al comando at.

Si no existen ni el archivo at.allow ni el archivo at.deny, los únicos que pueden utilizar el comando at son quienes tengan permiso de superusuario. Si sólo existe el archivo at.deny y éste está vacío, todos los usuarios podrán utilizar el comando at.

El permiso para utilizar el comando crontab se determina de la misma forma, con la diferencia de que los archivos se llaman cron.allow y cron.deny.

 

6.5. 1 at

 

 

 

 

 

 

 

 

 

Supongamos que desea imprimir un archivo largo por la noche cuando la carga de trabajo del sistema sea ligera. Con la siguiente secuencia del comando at se imprime el archivo “archivogrande” a las 4:00 de la mañana.

at 4am lp archivogrande

También puede especificar una fecha. Por ejemplo, para imprimir un mensaje el 10 de abril, a las 3:30, utilice los siguientes comandos:

at 3:30am Apr 10
echo “hora de ir a casa” > /dev/console
Ctrl^D

Para obtener una lista de los trabajos programados con at, escriba:

at -l

Obtendrá una salida así:

job 8745156.a at wed Sep 17 11:00:00 1997

6.5.2 batch

También puede utilizar el comando batch para presentar un archivo por lotes. Por ejemplo:

$ batch

nroff nombre_archivo > archivo_salida

 

Ctrl^D

Este comando ejecuta un comando nroff cuando el sistema puede gestionarlo. Para obtener información más pormenorizada, consulte la página de manual at (1).

 

6.5.3 Crontab

 

Puede utilizar el comando crontab para ejecutar comandos a intervalos regulares. Por ejemplo, puede enviar a su buzón un recordatorio semanal de correo electrónico en relación con una reunión o borrar todos los días todos los archivos “tmp”.

El comando crontab crea un archivo con su nombre de usuario en el directorio /var/spool/cron/crontabs. Los comandos del archivo se ejecutan conforme a los intervalos especificados en el directorio inicial.

Cada línea de un archivo crontab contiene seis campos separados por espacios o tabulaciones. Los primeros cinco campos especifican la hora a la que se ejecutará el comando:

minuto (0-59)
hora (0-23)
día del mes (1-31)
mes del año (1-12)
día de la semana (0-6, donde 0=domingo)

El sexto campo es una cadena que se ejecuta a la hora apropiada.

Para crear un archivo de comando crontab, escriba:

$ crontab
A continuación, escriba los comandos que desee programar y presione Ctrl-D.

30 8 * * 4 echo “Reunión de personal hoy a las 10:00 AM”
0 0 * * * rm *.tmp 2 > errfileEl archivo crontab se interpreta del modo siguiente:

El jueves a las 8:30, crontab le envía un recordatorio de la reunión del personal planificada para las 10:00. El primer campo (30) indica 30 minutos después de la hora. El segundo campo especifica la hora (8). Los asteriscos corresponden a los valores legales. El 4 significa jueves.

Todos los días, a medianoche, crontab borra los archivos de su directorio que tengan la extensión *.tmp. Los mensajes de error se desvían a un archivo que se llama errfile y está ubicado en el directorio inicial.

Listado de las entradas de crontab

Para obtener una lista de las entradas actuales del comando crontab, utilice la opción -l.

Para obtener más información, consulte la página de manual crontab(1).

¿Dudas, sugerencias, recomendaciones?


Saludos.

JxXx

 

Una respuesta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: