If you upgraded from Fedora 16 to Fedora 17, you may get an error when shutting down the system.
This happens because the kernel is the same, and grub2.cfg does not get the Fedora 17 kernel, but it is installed, although not recognized.
To fix this just run the following command:
# grub2-mkconfig > /etc/grub2.cfg && grub2-install /dev/sda
Notice that you should change /dev/sda for your partition
This will generate a new grub2.cfg with the new Fedora 17 kernel.
Un proceso consiste de un espacio de dirección y un conjunto de estructuras de datos en el kernel. La dirección es un conjunto de páginas de la memoria que el kernel ha marcado para el uso de ese proceso. Contiene el código y las librerías que el proceso utiliza, sus variables, sus pilas e información extra utiliza por el kernel mientras el proceso se está ejecutando. Dado que Unix y Linux son sistemas de memorias virtuales, no hay ninguna correlación entre la localización de las páginas en el espacio de direcciones del proceso y su localización dentro de la memoria física o swap.
Las estructuras de datos internas del kernel registran información sobre cada proceso. Algunas de las más importantes son:
Un hilo de ejecución, normalmente conocido simplemente como hilo (thread) es el resultado de un fork (bifurcación) del proceso. Un thread hereda muchos de los atributos del proceso que lo contiene, y múltiples threads pueden ejecutarse concurremente en un único proceso bajo un modelo llamado multithreading.
La ejecución concurrente es simulada por el kernel en un sistema de un único procesador, pero en los sistemas de varios núcleos o procesadores (multicore o multi-cpu) la concurrencia se reparte entre los diferentes núcleos. Las aplicaciones multithread como pueden ser Apache o BIND obtienen su máximo rendimiento en sistemas multicore.
PID: Process ID Number
El kernel asigna un ID único a cada proceso. Es asignado a la vez que el proceso es creado.
PPID: Parent PID
Ni Unix ni Linux tienen una llamada al sistema que inicie un nuevo proceso ejecutando un programa en particular. En vez de eso, un proceso existente debe clonarse a si mismo para crear un nuevo proceso. Luego el clon, puede intercambiar el proceso que está ejecutando por otro diferente. El PPID identifica el proceso del que se clonó (proceso padre)
UID and EUID
La UID de un proceso es la identificación del usuario que lo ha creado.
La EUID es la identificación del usuario “efectiva”, es una UID extra usada para determinar que recursos y archivos puede acceder el proceso. Para la mayoría de los procesos, la UID y EUID son idénticos.
Niceness
La prioridad del proceso determina cuánto tiempo de CPU recibe. El kernel utiliza un algoritmo dinámico para computar las prioridades. El kernel también presta atención a un valor que puede ser establecido por el administrador llamado ‘nice value’ o ‘niceness’. Llamado así del inglés nice porque nos dice como de nice (buenos) vamos a ser con el resto de usuarios del sistema.
El administrador de sistemas añade cuentas para los nuevos usuarios, elimina las cuentas de los usuarios que ya no están activos y gestiona todos los problemas posibles en relación a las cuentas, como por ejemplo contraseñas olvidadas. El proceso de añadir y eliminar puede ser automatizado, pero algunas decisiones (donde poner el home del usuario, en que máquina, etc) deben hacerse antes de añadir el usuario.
Cuando un usuario deje de pertenecer al sistema, su cuenta debe ser deshabilitada. Se debe hacer una copia de seguridad de sus archivos y sacarlos fuera del sistema para no acumular basura.
Cuando se compra nuevo hardware o cuando el hardware es movido de una máquina a otra, el sistema debe ser configurado para que reconozca y utilice ese hardware. La dificultad de esta tarea puede variar por ejemplo, desde instalar una impresora, hasta configurar un array de discos.
Ahora con la virtualización, las configuraciones de hardware se complican todavía más.
Quizás sea la tarea más importante del administrador de sistemas, y también es la tarea más ignorada y que da más pereza realizar. Hacer backups es aburrido y consume tiempo, pero son increíblemente necesarias. Se pueden automatizar o delegar, pero sigue siendo responsabilidad del administrador de sistemas cerciorarse de que se ejectuan correctamente y en el tiempo planeado.
Cuando se adquiere nuevo software, debe instalarse y probarse, a menudo bajo diferentes sistemas operativos y diferente hardware. Cuando el software funciona correctamente, los usuarios deben ser informados de su disponibilidad y localización. Si se trata de parches y actualizaciones de seguridad, deben implementarse gentilmente en el entorno local.
El software local y los scripts administrativos deberían ser gestionados de manera que sean compatibles con los procedimientos de actualización utilizados.
Las instalaciones grandes requieren de supervisión. No esperes que los usuarios reporten sus problemas a no ser que sean graves. Regularmente comprueba que el correo y servicio web funcionan correctamente, revisa los ficheros log en busca de fallos o problemas, cerciórate de que las redes locales están conectadas correctamente y mantén un ojo a la disponibilidad de recursos en el sistema, como el espacio en disco. Todo esto, se puede automatizar.
Los fallos en el sistema son inevitables. Es el trabajo de un administrador diagnosticar estos problemas y llamar a expertos si es necesario. Normalmente es más difícil encontrar el problema que solucionarlo.
Un sistema suele variar con las necesidades de la organización, y comienza a diferir de lo que inicialmente se documentó. Como el administrador de sistemas es responsable de estos cambios, también lo es documentar los cambios.
El administrador es responsable de implementar una política de seguridad y comprobar periódicamente que la seguridad no ha sido violada.
Proveen un entorno de ejecución donde las aplicaciones se ejecutan. Luego, el kernel debe implementar un conjunto de servicios y sus correspondientes interfaces. Las aplicaciones utilizan esas interfaces y normalmente no interactuan directamente con los recursos hardware.
Una CPU puede ejecutarse en modo Usuario o en modo Kernel. En realidad, algunas CPUs pueden tener más de dos modos de ejecución, pero todos los kernel estándar de Unix utilizan los dos modos mencionados anteriormente.
Cuando un programa es ejecutado en modo usuario, no puede acceder directamente a las estructuras del kernel o a los programas de éste. Cuando se ejecuta en modo Kernel, sin embargo, esas restricciones desaparecen. Cada modelo de CPU provee instrucciones especiales para cambiar de modo Usuario a modo Kernel y vice versa. Un programa normalmente se ejecuta en modo Usuario y cambia a modo Kernel sólo cuando requiere de un servicio que provee el kernel. Cuando el kernel ha completado la petición del programa, vuelve a modo Usuario.
Los procesos son entidades dinámicas que normalmente tienen una vida limitada en el sistema. La tarea de crear, eliminar y sincronizar los procesos existentes se delega a un grupo de rutinas del kernel.
El kernel como tal, no es un proceso si no un gestor de procesos. El modelo proceso/kernel asume que los procesos que requieren un servicio kernel utilizan lo que se conoce como llamadas al sistema. Cada llamada al sistema establece el grupo de parámetros que identifican la petición del proceso y después ejecuta la instrucción CPU independiente del hardware para cambiar de modo Usuario a modo Kernel.
Además de los procesos de usuario, los sistemas Unix incluyen unos pocos procesos privilegiados llamados hilos kernel (kernel threads) con las siguientes características: