Como o systemd usa os scripts /etc/init.d?

Navegue suas respostas
94

Eu apenas mudei para debian jessie e a maioria das coisas correu bem, incluindo o meu gerenciador de exibição gráfico wdm .

O problema é que eu não entendo como isso funciona. Obviamente, meu script /etc/init.d/wdm é chamado, porque quando eu coloco um exit inicial lá, o wdm não é iniciado. Mas quando eu alternativamente renomear o diretório /etc/rc3.d (meu nível de execução padrão costumava ser 3), então o wdm ainda é iniciado.

Eu não consegui descobrir como o systemd encontra esse script e não entendo o que ele faz com todos os outros scripts init.d.

  • Quando e como o systemd executa os scripts init.d?
  • A longo prazo, devo me livrar de todos os scripts init.d?
por Martin Drautzburg 02.10.2015 / 12:46

3 respostas

135

resposta do caos é o que algumas documentações dizem. Mas não é o que realmente faz. (Não é o que o System V rc fez. O Sistema Linux V rc definitivamente não ignorou os cabeçalhos LSB, que insserv usou para calcular ordenações estáticas, para iniciantes.) O Freedesktop documentação, como a página "Incompatibilities", está errada, sobre esses e outros pontos. (A variável de ambiente HOME na verdade é frequentemente definida, por exemplo. Isso foi totalmente não documentado em qualquer lugar por um longo tempo. Agora está documentado no manual, mas a página WWW da Freedesktop ainda tem foi corrigido.)

O formato de serviço nativo do systemd é a unidade de serviço . O gerenciamento de serviço do systemd opera apenas somente em termos daqueles, que ele lê em um dos nove diretórios onde (em todo o sistema) .service arquivos podem viver. /etc/systemd/system , /run/systemd/system , /usr/local/lib/systemd/system e /usr/lib/systemd/system são quatro desses diretórios.

A compatibilidade com os scripts System V rc é obtida com um programa de conversão denominado systemd-sysv-generator . Este programa é listado no diretório /usr/lib/systemd/system-generators/ e, portanto, é executado automaticamente pelo systemd no início do processo de autoinicialização a cada inicialização e, novamente, toda vez que o systemd for instruído a recarregar sua configuração posteriormente.

Este programa é um gerador , um tipo de utilitário auxiliar cujo trabalho é criar arquivos de unidade de serviço em tempo real, em um tmpfs onde mais três desses nove diretórios (que são destinados a serem usados apenas por geradores) estão localizados. systemd-sysv-generator gera as unidades de serviço que executam os scripts System V rc de /etc/init.d , caso não encontre uma unidade de serviço systemd nativa com esse nome já existente nos outros seis locais.

O gerenciamento de serviços do systemd só conhece as unidades de serviço. Essas unidades de serviço (re- geradas automaticamente) são gravadas para invocar o sistema 5 rc scripts. Eles têm, entre outras coisas: 

[Unit]
SourcePath=/etc/init.d/wibble
[Service]
ExecStart=/etc/init.d/wibble start
ExecStop=/etc/init.d/wibble stop

A sabedoria recebida é que os scripts System V rc devem ter um cabeçalho LSB e serem executados em paralelo sem honrar as prioridades impostas pelo sistema /etc/rc?.d/ . Isso está incorreto em todos os pontos.

Na verdade, eles não precisam ter um cabeçalho LSB e, se não forem, systemd-sysv-generator poderão reconhecer os cabeçalhos de comentários antigos RedHat mais limitados ( description: , pidfile: e assim por diante). Além disso, na ausência de um cabeçalho LSB, ele retornará ao conteúdo dos farms de link simbólico /etc/rc?.d , lendo as prioridades codificadas nos nomes dos links e construindo uma ordem antes / depois deles, serializando os serviços. Não apenas os cabeçalhos LSB não são um requisito, e não apenas eles mesmos codificam as ordenações antes / depois que serializam as coisas até certo ponto, o comportamento de fallback em sua completa ausência é, na verdade, uma operação significativamente não paralelizada.

O motivo pelo qual /etc/rc3.d não pareceu importar é que você provavelmente tinha esse script ativado por meio de outro diretório /etc/rc?.d/ . systemd-sysv-generator traduz a listagem em qualquer uma das /etc/rc2.d/ , /etc/rc3.d/ e /etc/rc4.d/ em uma relação Wanted-By nativa para multi-user.target do systemd. Os níveis de execução são "obsoletos" no mundo do systemd e você pode esquecê-los.

Leitura adicional

por 02.10.2015 / 22:31
2

FYI: O que fazer quando o SysD silenciosamente falha ao iniciar o processo SysV?

Sim, isso acontece. SysD mostra que o processo do System V foi iniciado com o código de saída 0 (sucesso), ainda assim, o processo falhou ao iniciar corretamente e o serviço está realmente inativo. O serviço será iniciado corretamente se você testar a execução na linha de comando, ou seja, nenhum problema com a configuração desse serviço. O systemd-sysv-generator cria um arquivo on the fly ao iniciar algo com o SysV init. Você pode encontrar o resultado em 

/run/systemd/generator.late/

Este exemplo está relacionado ao serviço "opendmark" no Ubuntu. Você pode substituir, por exemplo, ExecStart = para corrigir um problema de inicialização. Executar 

sudo systemctl edit opendmarc.service    (<--use the actual service name)

Isso abrirá um editor. Digite lá o que for necessário para consertar a coisa: 

[unit]
# with an override you must "clear" the ExecStart first.
ExecStart=
ExecStart=/usr/sbin/opendmarc -p localhost:54321 -u opendmarc -P /var/run/opendmarc/opendmarc.pid

No exemplo acima, precisei iniciar o opendmarc como um soquete inet no localhost: 54321 (em vez do soquete do Unix).

Créditos e úteis para ler:

link

link

    
por 27.02.2018 / 12:44

Tags

Gerar arquivo de um determinado tamanho? Delete Primeira linha de um arquivo