O sistema está totalmente inativo se inicializar com o parâmetro do kernel INIT = / bin / sh e sair imediatamente do shell?

Question

E se o boot assim:

Transmita o parâmetro INIT=/bin/sh(or /bin/bash) para o kernel, por meio da linha de comando do GRUB ou de formas semelhantes, depois inicialize; Depois que o shell for carregado, saia imediatamente. Em seguida, o computador não responde a nenhuma tecla pressionada.

Estou bastante curioso sobre o STATUS do sistema neste momento. Como eu aprendi que init é o primeiro processo que seria executado assim que o kernel fosse carregado e outros processos fossem todos fork ed, parece que quando executar /bin/sh como descrito acima ao invés de init com normal procedimento de inicialização, então o sistema não tem mais nenhum processo e nada para fazer.

É ocioso como correr

while (1) {
    sleep(1);
}

ou o que mais?

Obrigado a todos por seus conselhos. Talvez mais informações sejam úteis, que eu considerava desnecessárias.

Eu trabalhei em um servidor CentOS 7.2 recentemente, e uma partição de disco XFS não é normal, o que custa um tempo infinito fazendo checagem e recuperação quando o sistema é inicializado. Eu planejei editar /etc/fstab para desativar a montagem automática dessa partição. Como o procedimento de inicialização normal estava travado, usei init=/bin/bash para fazer o boot do sistema no bash. Após editar fstab , executei shell exit descuidadamente, então nenhuma resposta na tela de nenhuma tecla pressionada incluindo Ctrl-Alt-Del , e nenhuma informação solicitou o kernel panic (não consegui saber se a CPU estava difícil trabalhando porque esse quarto era muito barulhento). Eu considerei isso como ocioso como nada para fazer. Esse fenômeno me fez pensar sobre a questão que escrevi no começo.

E fiz alguns testes hoje à noite, no meu próprio notebook com o Debian 8. Pânico do Kernal obviamente .

    

Answer 1

Estou surpreso. No meu entender, o término do PID 1 causa um pânico no kernel . Eu posso te dizer o que aconteceu nesse caso.

Comportamento de pânico é configurável. Com as opções padrão, você alcançará um loop que parece exatamente como você diz.

A função de atraso usada é documentada como sendo uma "espera ocupada". É não esperado para entrar na economia de energia Estados de suspensão da CPU usados quando o sistema operacional está ocioso normalmente.

Se você olhar o backtrace impresso pelo pânico, acho que tudo isso acontece dentro de sys_exit() . Eu acho que, tecnicamente, o PID 1 não é destruído, ele nunca retorna da chamada do sistema. Quaisquer outras CPUs são paradas primeiro.

(Existe algo chamado "thread ocioso de inicialização" Eu não vejo isso envolvido neste processo.AFAICT você nunca pode ver este segmento.E se você quisesse entendê-lo como um thread ocioso, você também teria que perguntar o que fornece o thread ocioso para os outros cpus uma vez que eles são trazidos online).

    

Answer 2

Não é verdade que o sistema não tenha nada a ver se nenhum processo em nível de usuário estiver em execução. O sistema tem um monte de threads do kernel , que o próprio kernel iniciou. Eles estão dormindo principalmente, mas acordam periodicamente para fazer sua tarefa. Os encadeamentos do kernel executam apenas o código de espaço do kernel, ou seja, eles não possuem nenhum mapeamento de memória no nível de usuário. Eles são processos separados, pois são programados de forma independente e possuem IDs de processo exclusivos.

Se você executar ps aux , poderá reconhecer os encadeamentos do kernel pelos colchetes ao redor do nome do encadeamento.

    

Answer 3

O sistema não possui nenhum processo em execução. Portanto, nenhum loop ocupado como você escreveu (que teria 100% de CPU). Interrupções ainda podem ser manipuladas pelo kernel, mas não há processo. A CPU estaria inativa.

Os detalhes podem ser encontrados aqui no fonte de kernel_init () , o programa é executado de forma semelhante a execve() . Isso também significa que a execução não retorna (veja execve(3p) ).