Por que alguns scripts precisam de re-sourcing constante durante o debian init?

Question

Estudando os scripts de inicialização, estou intrigado sobre por que algumas funções auxiliares precisam ser reinseridas repetidas vezes. Especificamente, as funções de log encontradas em /lib/lsb/init-functions . Todos os scripts que querem mensagens de log precisam reclassificar isso, por que não é possível fazer isso uma vez?

É como se cada novo script de inicialização fosse executado em seu próprio shell. Se for esse o caso, por que gosta disso? O mesmo problema aparece com 'vars.sh', que precisa ser re-sourced o tempo todo. Isso é necessário? Suponha que 'init-functions' e 'vars.sh' tenham sido adicionados à lista de scripts a serem executados nos runlevels apropriados?

    

Answer 1

Muitas perguntas ...

A resposta básica para sua pergunta é sim, cada script é executado em seu próprio shell, ou melhor, cada processo que é exec'd contém uma cópia do ambiente base + essas variáveis que são incluídas por essa fonte + quaisquer variáveis de ambiente adicionais que são incluídos quando o serviço é iniciado.

Mover esses includes, como vars.sh , para o nível de runlevel seria uma má ideia, porque então cada shell os teria nesse runlevel. A maior parte do encanamento que esses scripts estão criando é extremamente específica para os serviços que estão sendo executados no shell resultante, que é o subproduto desses arquivos sendo originados.

Lembre-se também de que muito é armazenado em buffer e armazenado em cache, blocos lidos do disco, por exemplo, para que você não esteja necessariamente entrando em contato com o disco todas as vezes para releituras subseqüentes desses arquivos. Isso é parte do que está acontecendo quando você olha para o seu sistema e vê que está consumindo muita memória RAM.

$ free -m
             total       used       free     shared    buffers     cached
Mem:          7782       7086        696          0        218        883
-/+ buffers/cache:       5984       1797
Swap:         7823       1550       6273

A linha -/+ buffers/cache é o armazenamento em cache desses tipos de blocos, relacionados a E / S de disco.

Direções futuras

Grande parte do init deriva do Sistema V (veja o Artigo da Wikipédia sobre init para a história completa). Pelos padrões de hoje, é antiquado, mas tem servido bem por cerca de 20 anos. Mas há definitivamente áreas onde é deficiente.

Então, para tentar abordá-los, 2 recém-chegados, Systemd & Upstart foram desenvolvidos e estão começando a ser adotados por várias distribuições Linux.

A adoção de Upstart tem sido uma pequena montanha-russa. Ele é desenvolvido pela Canonical, então já faz parte do Ubuntu há algum tempo, e fazia parte do Fedora e também do RHEL, CentOS e openSUSE por algum tempo, antes de mudar para o systemd. Na verdade, ainda está no RHEL & CentOS até certo ponto.

Ambos os sistemas fazem melhorias marcadas sobre o init do SysV, especialmente na área de poder iniciar serviços em paralelo. Uma das principais deficiências do init. Mas com esses sistemas, foi a simplicidade de abrir alguns scripts em vim e ajustar suas rotinas de inicialização. Estas são tecnologias completas que exigem tempo para crescer e entender completamente.

    

Answer 2

Até onde eu vi, apenas os scripts em /etc/init.d/ e /etc/network dos arquivos em /lib/lsb/init-functions , eles não são originados de novo e de novo, apenas uma vez para cada script e cada script precisa ser originado uma vez porque cada script pode ser iniciado separadamente.

[Editar # 1]

Importante saber, quando o arquivo foi lido uma vez, será armazenado em cache pelo sistema. Portanto, não leva tempo algum se o arquivo tiver que ser lido novamente. Além disso, os arquivos em /etc/lsb/init-functions contêm apenas a definição de sub-rotinas, eles não serão executados quando originados.

[Editar # 2]

Eu verifiquei isso mais uma vez e queria saber quanto tempo leva para criar um script. Então eu mudei para o init 1 para ter certeza de que nenhum outro processo perturba a medição. Aqui estão os resultados:

find /lib/lsb -type f -ls
9951842    4 -rw-r--r--   1 root     root         1088 Jun  5  2013 /lib/lsb/init-functions.d/20-left-info-blocks  
9952149    4 -rw-r--r--   1 root     root         2408 Dec 31 19:24 /lib/lsb/init-functions.d/40-systemd  
9951841   12 -rw-r--r--   1 root     root        11506 May 15  2013 /lib/lsb/init-functions 

Portanto, estes são 3 scripts e cerca de 15k de armazenamento

O teste é um simples laço bash

time bash -c 'for i in {1..10000}; do source /lib/lsb/init-functions; done'
real   0m27.342s
user   0m17.756s
sys    0m1.328s

Isso significa 27.342 / 10000/3 = 0.0009 segundos em média para fornecer um script em um Core 2 Duo de 3.4Ghz.