¿Qué pasa si arranca así?
Pase INIT=/bin/sh(or /bin/bash)el parámetro al kernel, a través de la línea de comando GRUB o formas similares, luego inicie;
Una vez cargado el shell, salga inmediatamente. Entonces la computadora no responde a ninguna tecla presionada.
Tengo bastante curiosidad sobre elESTADOdel sistema en este momento. Como he aprendido, ese inites el primer proceso que se ejecutará una vez que se cargue el kernel y se forkeliminen todos los demás procesos, parece que cuando se ejecuta /bin/shcomo se describe anteriormente en lugar de initcon el procedimiento de arranque normal, entonces el sistema ya no tiene procesos y nada. hacer.
¿Está inactivo como correr?
while (1) {
sleep(1);
}
o que mas?
Gracias a todos por vuestros consejos.Quizás más información sea útil,que solía considerar innecesario.
Trabajé en un servidor CentOS 7.2 recientemente, y una partición de disco XFS no es normal y me lleva mucho tiempo verificar y recuperar cuando se inicia el sistema. Planeaba editar /etc/fstabpara desactivar el montaje automático de esta partición. Como el procedimiento de arranque normal estaba bloqueado, solía init=/bin/bashhacer que el sistema arrancara en bash. Después de editar fstab, ejecuté Shell exitdescuidadamente,luego no hay respuesta en la pantalla a ninguna tecla presionada, incluido Ctrl-Alt-Del, y no hay información que genere pánico en el kernel(No podía decir si la CPU estaba trabajando duro porque esa habitación era muy ruidosa). Lo consideraba inactivo y no tenía nada que hacer. Este fenómeno me hizo pensar en la pregunta que escribí al principio.
Y esta noche hice algunas pruebas en mi propia computadora portátil con Debian 8.Pánico central obviamente.
Respuesta1
Estoy sorprendido. Tenía entendido que terminar el PID 1provoca un pánico en el núcleo. Puedo contarte lo que pasó en ese caso.
El comportamiento de pánico es configurable. Con las opciones predeterminadas, llegará a unbuclese ve exactamente como dices.
La función de retardo utilizada esdocumentadocomo una "espera ocupada". EsnoSe espera que entre en los estados de suspensión de la CPU para ahorrar energía que se utilizan cuando el sistema operativo está inactivo normalmente.
Si miras el rastro impreso por el pánico, creo que verás que todo esto sucede dentro sys_exit(). Creo que técnicamente el PID 1 no se destruye, simplemente nunca regresa después de realizar esa llamada al sistema. Cualquier otra CPU se detiene primero.
(Hay algo llamado"hilo de arranque inactivo". No lo veo involucrado en este proceso. AFAICT nunca podrás ver este hilo. Y si quisiera entenderlo como un subproceso inactivo, también tendría que preguntar qué proporciona el subproceso inactivo para las otras CPU una vez que se conectan).
Respuesta2
No es cierto que el sistema no tenga nada que hacer si no se está ejecutando ningún proceso a nivel de usuario. El sistema tiene un montón dehilos del núcleo, que el propio kernel ha iniciado. La mayor parte del tiempo duermen, pero periódicamente se despiertan para realizar su tarea. Los subprocesos del kernel ejecutan sólo código de espacio del kernel, es decir, no tienen asignaciones de memoria a nivel de usuario. Son procesos separados porque se programan de forma independiente y tienen identificadores de proceso únicos.
Si ejecuta ps aux, podrá reconocer los subprocesos del núcleo por los corchetes que rodean el nombre del subproceso.
Respuesta3
El sistema no tiene ningún proceso en ejecución. Por lo tanto, no hay bucle ocupado como el que ha escrito (eso tendría 100% de CPU). El kernel aún puede manejar las interrupciones, pero no hay ningún proceso. La CPU estaría inactiva.
Los detalles se pueden encontrar aquí en elfuente de kernel_init(), el programa se ejecuta de forma similar a execve(). Eso también significa que la ejecución no regresa (ver execve(3p)).