O sistema 5 initlhe dirá apenas uma pequena parte da história.
Há uma espécie de miopia que afeta o mundo do Linux. As pessoas pensam que usam algo chamado "Sistema 5 init", e é isso que é tradicional e o melhor lugar para começar. Nem é de fato o caso.
A tradição não é de fato o que essas pessoas dizem que é, para começar. O Sistema 5 inite o Sistema 5 rcdatam do Sistema 5 da AT&T UNIX, que foi quase tão longe após o primeiro UNIX quanto agora (digamos) após a primeira versão do Linux-Mandrake.
1ª edição UNIX só tinha init. Não tinha rc. A linguagem assembly da 1ª edição init( cujo código foi restaurado e disponibilizado por Warren Toomey et al. ) Gerou e reapareceu diretamente 12 gettyprocessos, montou 3 sistemas de arquivos conectados a partir de uma tabela embutida e executou diretamente um programa no diretório inicial de um usuário nomeado mel. A gettytabela também estava diretamente na imagem do programa.
Foi mais uma década depois do UNIX System 5 que surgiu o chamado sistema "Linux" tradicional "init". Em 1992, Miquel van Smoorenburg (re) escreveu um Linux init+ rce suas ferramentas associadas, que as pessoas agora chamam de "Sistema 5 init", mesmo que não seja realmente o software do UNIX System 5 (e não é apenas init)
O Sistema 5 init/ rcnão é o melhor lugar para começar, e mesmo que se acrescente um conhecimento do systemd que não cubra metade do que há para saber. Tem havido muito trabalho na área de design de sistemas init (para Linux e BSDs) que aconteceu apenas nas últimas duas décadas. Todo tipo de decisão de engenharia foi discutida, tomada, projetada, implementada e praticada. Os Unices comerciais também fizeram muito.
Sistemas existentes para estudar e aprender com
Aqui está uma lista incompleta de alguns dos principais sistemas init, além daqueles dois e um ou dois de seus (vários) pontos salientes:
- O finito de Joachim Nilsson seguiu o caminho de usar um arquivo de configuração mais legível por humanos.
- O minit de Felix von Leitner foi para um sistema de configuração de sistema de arquivos é o banco de dados, pequenas áreas de memória e dependências de iniciar / parar entre as coisas que
initcomeçam.
- A runit de Gerrit Pape foi para o que eu descrevi anteriormente como a abordagem de apenas quatro scripts shell .
- O InitNG visava ter dependências, destinos nomeados, vários arquivos de configuração e uma sintaxe de configuração mais flexível, com uma carga completa de mais configurações para processos filhos.
- o iniciante foi reformulado, modelando o sistema não como serviços e interdependências, mas como eventos e tarefas acionados por eles.
- O design do nosh inclui transferir todo o gerenciamento de serviços (incluindo até a
gettycriação de zumbis e os zumbis) para um gerenciador de serviços separado, e apenas manipular dispositivos / APIs / links simbólicos / diretórios específicos de sistemas operacionais "API" do sistema operacional.
- Sinit é um init muito simples. Ele executa
/bin/rc.initcujo trabalho é iniciar programas, montar o sistema de arquivos, etc. Para isso, você pode usar algo como minirc .
Além disso, há cerca de 10 anos, houve uma discussão entre os usuários do daemontools e outros sobre o uso do svscanprocesso nº 1, o que levou a projetos como o svscan de Paul Jarc como estudo do processo 1 , as idéias de Gerrit Pape e o svscan de Laurent Bercot como o processo 1 .
O que nos leva ao processo nº 1 dos programas.
Que programas do processo nº 1 fazem
As noções sobre o que o processo nº 1 "deve" fazer são, por natureza, subjetivas. Um critério de design objetivo significativo é o que o processo nº 1, no mínimo, deve fazer. O kernel impõe vários requisitos a ele. E sempre há algumas coisas específicas de sistema operacional de vários tipos que ele precisa fazer. Quando se trata do processo nº 1 tradicionalmente realizado, não estamos no mínimo e nunca estivemos realmente.
Há várias coisas que vários kernels do sistema operacional e outros programas exigem do processo nº 1, dos quais simplesmente não podemos escapar.
As pessoas lhe dirão que fork()agir e agir como pai de processos órfãos é a principal função do processo nº 1. Ironicamente, isso é falso. Lidar com processos órfãos é (com os kernels recentes do Linux, conforme explicado em https://unix.stackexchange.com/a/177361/5132 ) uma parte do sistema que pode ser amplamente fatorado fora do processo nº 1 em outros processos, como um gerente de serviço dedicado . Todos esses são gerentes de serviço, que são executados no processo 1:
- o
srcmstrprograma IBM AIX , o System Resource Controller
- Gerrit Pape's
runsvdirde runit
- Daniel J. Bernstein é
svscande daemontools, de Adam Sampson svscande freedt , de Bruce Guenter svscande daemontools-bis, e Laurent Bercot de s6-svscanpartir S6
- Wayne Marshall's
perpdde perp
- o Service Management Facility no Solaris 10
- o
service-managerde nosh
Da mesma forma, conforme explicado em https://superuser.com/a/888936/38062 , toda a /dev/initctlideia não precisa estar nem perto do processo nº 1. Ironicamente, é o sistema altamente centralizado que demonstra que pode ser movido para fora do processo nº 1.
Por outro lado, as coisas obrigatórias para init, que as pessoas costumam esquecer em seus desenhos off-the-top-of-the-cabeça, são coisas como a manipulação SIGINT, SIGPWR, SIGWINCH, e assim por diante enviados do kernel e articulado dos vários pedidos de mudança de estado do sistema enviados de programas que "sabem" que certos sinais para processar o número 1 significam certas coisas. (Por exemplo: Conforme explicado em https://unix.stackexchange.com/a/196471/5132 , os conjuntos de ferramentas BSD "sabem" que SIGUSR1têm um significado específico.)
Também existem tarefas únicas de inicialização e finalização, das quais não se pode escapar, ou sofrerá muito com isso, como montar sistemas de arquivos "API" ou liberar o cache do sistema de arquivos.
Os princípios básicos para lidar com sistemas de arquivos "API" são um pouco diferentes da operação do initrom 1st Edition UNIX: Um possui uma lista de informações conectadas ao programa e simplesmente mount()todas as entradas da lista. Você encontrará esse mecanismo em sistemas tão diversos quanto o BSD (sic!) init, Através do nariz system-manager, para o systemd.
"configure o sistema para um shell simples"
Como você observou, init=/bin/shnão monta sistemas de arquivos "API", trava de maneira desajeitada, sem descarga de cache quando se digita exit( https://unix.stackexchange.com/a/195978/5132 ), e geralmente deixa ao (super) usuário executar manualmente as ações que tornam o sistema minimamente utilizável.
Para ver o que realmente não tem escolha a não ser fazer nos programas nº 1 do processo e, assim, definir um bom caminho para seu objetivo de projeto declarado, sua melhor opção é observar as sobreposições na operação do runit de Gerrit Pape, Felix von Minit de Leitner e o system-managerprograma do pacote nosh. Os dois primeiros mostram duas tentativas de serem minimalistas, mas ainda lidam com o que é impossível evitar.
O último é útil, sugiro, por sua extensa entrada manual para o system-managerprograma, que detalha exatamente quais sistemas de arquivos "API" são montados, quais tarefas de inicialização são executadas e quais sinais são manipulados; em um sistema que, por padrão , o gerente do sistema gera apenas três outras coisas (o gerente de serviço, um criador de logs acompanhante e o programa para executar as alterações de estado) e só faz o inevitável no processo # 1.