Onde o processo / script init termina?

Question

Meu entendimento é que, pelo menos no espaço inicial do usuário, o init é um script de shell do qual não é possível sair. Está correto?

Então o que acontece quando chega ao fim?

Estou ciente de que, em uma seqüência típica de inicialização, o script de inicialização no início do espaço do usuário montaria o sistema de arquivos raiz e o controle de transição para o init a partir da nova raiz. MAS, supondo que isso não aconteceu - que o root não foi montado e o controle não foi transferido para o novo init raiz - o que aconteceria quando o script init terminasse?

    

Answer 1

My understanding is that, at least in early user space, init is a shell script that cannot be exited from. Is this correct?

Não precisa ser um script de shell. Você certamente pode sair do processo init . Isso causará um pânico no kernel, mas isso pode ser feito.

So what happens when it comes to an end?

O script geralmente tem uma linha como exec switch_root /root "$@" . Como ele usa exec , o mesmo ID do processo é sobreposto com um novo binário a ser executado.

Assim, o programa que é init muda e o kernel nunca vê um exit do processo init.

Por sua vez, switch_root exec s /sbin/init do sistema de arquivos raiz após limpar o initramfs e vincular-montar /root a / . Então, init sempre permanece PID 1.

Você pode ver o código-fonte do switch_root do BusyBox aqui, é bem simples: link Há também um longo comentário no final explicando um pouco do que se passa sob o capô.

    

Answer 2

O processo init, /sbin/init não é um shell script e não sai (sob condições normais).
Do link

In Unix-based computer operating systems, init (short for initialization) is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down.
It is the direct or indirect ancestor of all other processes and automatically adopts all orphaned processes.

É o primeiro processo de espaço do usuário, o kernel fork e o exec, depois que o kernel se inicializou. É por isso que é chamado PID1 (ID do processo 1).

Existem implementações diferentes hoje em dia do processo init, e. upstart ou systemd, com as implementações originais baseadas no systemV init.

O que todos eles basicamente fazem é - na inicialização - ler arquivos de configuração para cada processo que é um candidato a ser lançado. Tradicionalmente, esses arquivos de configuração estão localizados em /etc/init/ . Se o processo for sinalizado para ativação, o processo será iniciado ou, se sua configuração indicar "não iniciar na inicialização", ele não será iniciado, mas poderá ser iniciado manualmente mais tarde.
Se o processo for sinalizado para ser iniciado, o caminho - tradicionalmente - de que ele teria sido iniciado é que o sistema init executaria um script de shell correspondente ao daemon em /etc/init.d/ .

Algumas das diferenças entre os sistemas init mais recentes e o sistema original V init é que o sistema V usa níveis de execução numéricos, 0,1,2, etc para determinar o estado do sistema e o uso do sistema ou upstart chamado identificadores como mulit-user.target .

Além disso, creio, sistemas de inicialização mais novos lançam seus próprios daemons e usam seus próprios arquivos "unit" para definir diretivas de configuração, em vez de chamar um script de shell.

por exemplo, para nginx existe um arquivo de configuração /lib/systemd/system/nginx.service que define diretivas de inicialização como:

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target

Você poderia ativá-lo com um comando como sudo systemctl enable nginx.service . Isso criará um link simbólico em

/etc/systemd/system/multi-user.target.wants/nginx.service

apontando para o arquivo da unidade em:

/lib/systemd/system/nginx.service

sudo systemctl disable nginx.service removeria o link simbólico e o serviço não será iniciado na inicialização.

Os sistemas init mais recentes são compatíveis com os scripts init systemV e lerão as configurações em /etc/init e iniciarão os shell scripts em /etc/init.d