E se inicializar assim:
Passe INIT=/bin/sh(or /bin/bash)o parâmetro para o kernel, através da linha de comando do GRUB ou formas similares, e então inicialize;
Assim que o shell for carregado, saia imediatamente. Então o computador não responde a nenhuma tecla pressionada.
Estou bastante curioso sobre oSTATUSdo sistema neste momento. Como aprendi que inité o primeiro processo que seria executado assim que o kernel fosse carregado e todos os outros processos fossem removidos forkdele, parece que quando executado /bin/shconforme descrito acima, em vez de initcom o procedimento de inicialização normal, o sistema não terá mais processos e nada pendência.
É ocioso como correr
while (1) {
sleep(1);
}
ou o que mais?
Obrigado a todos vocês por seus conselhos.Talvez mais informações sejam úteis,que eu costumava considerar desnecessário.
Trabalhei em um servidor CentOS 7.2 recentemente, e uma partição de disco XFS não é normal, pois custa um tempo infinito para verificar e recuperar quando o sistema é inicializado. Planejei editar /etc/fstabpara desativar a montagem automática desta partição. Como o procedimento normal de inicialização estava travado, eu costumava init=/bin/bashinicializar o sistema no bash. Após edit fstab, executei o shell exitdescuidadamente,então nenhuma resposta na tela a qualquer tecla pressionada, incluindo Ctrl-Alt-Del, e nenhuma informação gerou pânico no kernel(Eu não sabia se a CPU estava funcionando muito porque aquela sala era muito barulhenta). Eu considerava isso tão ocioso quanto nada para fazer. Esse fenômeno me fez pensar na pergunta que escrevi no início.
E fiz alguns testes esta noite, no meu próprio notebook com Debian 8.Pânico Kernal obviamente.
Responder1
Estou surpreso. Meu entendimento foi que encerrar o PID 1causa um pânico no kernel. Posso contar o que aconteceu nesse caso.
O comportamento de pânico é configurável. Com as opções padrão, você alcançará umlaçoparece exatamente como você diz.
A função de atraso usada édocumentadocomo sendo uma "espera ocupada". Isso énãoespera-se que entre nos estados de suspensão da CPU com economia de energia usados quando o sistema operacional fica inativo normalmente.
Se você olhar para o backtrace impresso pelo pânico, acho que verá que tudo isso acontece dentro de nós sys_exit(). Acho que tecnicamente o PID 1 não é destruído, apenas nunca retorna ao fazer aquela chamada de sistema. Quaisquer outras CPUs são interrompidas primeiro.
(Existe algo chamado"inicializar thread inativo". Não vejo isso envolvido nesse processo. AFAICT você nunca poderá ver este tópico. E se você quiser entendê-lo como um encadeamento inativo, também terá que perguntar o que fornece o encadeamento inativo para os outros processadores quando eles são colocados on-line).
Responder2
Não é verdade que o sistema não tenha nada a fazer se nenhum processo no nível do usuário estiver em execução. O sistema tem um monte dethreads do kernel, que o próprio kernel iniciou. Eles dormem principalmente, mas acordam periodicamente para realizar suas tarefas. Threads do kernel executam apenas código de espaço do kernel, ou seja, eles não possuem nenhum mapeamento de memória no nível do usuário. Eles são processos separados, pois são agendados de forma independente e possuem IDs de processo exclusivos.
Se você executar ps aux, poderá reconhecer os threads do kernel pelos colchetes ao redor do nome do thread.
Responder3
O sistema não possui nenhum processo em execução. Portanto, nenhum loop ocupado como você escreveu (isso teria 100% de CPU). As interrupções ainda podem ser tratadas pelo kernel, mas não há processo. A CPU ficaria ociosa.
Os detalhes podem ser encontrados aqui nofonte de kernel_init(), o programa é executado de forma semelhante a execve(). Isso também significa que a execução não retorna (consulte Recursos execve(3p)).