Qual é o caminho padrão que o systemd usa para localizar scripts do System V?

Question

/etc/init.d é o caminho de pesquisa padrão que o gerador systemd usa para converter o script SysV nativo em arquivos de unidade e retorna para /etc/rc?.d ou vice-versa?

Desta resposta por @JdeBP:

This program is a generator, a type of ancillary utility whose job is to create service unit files on the fly, in a tmpfs where three more of those nine directories (which are intended to be used only by generators) are located. systemd-sysv-generator generates the service units that run the System V rc scripts from /etc/init.d, if it doesn't find a native systemd service unit by that name already existing in the other six locations.

Mas o livro Como o Linux funciona menciona algo diferente:

1. First, systemd activates runlevel<N>.target, where N is the runlevel.
2. For each symbolic link in /etc/rc<N>.d, systemd identifies the script in /etc/init.d.
3. systemd associates the script name with a service unit (for example, /etc/init.d/foo would be foo.service).
4. systemd activates the service unit and runs the script with either a start or stop argument, based on its name in rc<N>.d.
5. systemd attempts to associate any processes from the script with the service unit.

Tanto quanto eu posso dizer, o procedimento vai da seguinte maneira: systemd encontra scripts SysV em /etc/init.d e dependendo do runlevel, systemd decide iniciar ou parar os scripts de acordo com o nome do link simbólico ( K* ou S* ) de /etc/rc?.d . Isso faz sentido, porque uma vez que o script SysV é convertido em um arquivo unitário do systemd nativo, a decisão de iniciar ou parar o processo deve ser obtida em /etc/rc?.d . Por exemplo, estou executando o Ubuntu 17.04:

$ ls -l /etc/rc5.d
lrwxrwxrwx 1 root root 15 Aug  4 00:10 S01acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 17 Aug  4 00:10 S01anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root 16 Aug  4 00:10 S01apport -> ../init.d/apport
lrwxrwxrwx 1 root root 22 Aug  4 00:10 S01avahi-daemon -> ../init.d/avahi-daemon
...many more...

Eu posso ver que todos os links simbólicos para os scripts têm a mesma ordem de execução 01, e isso é feito intencionalmente para explorar o paralelismo no systemd, então systemd-sysv-generator usa /etc/rc?.d para determinar também a ordem das dependências ( por exemplo, Before , After ).

Como o cabeçalho do LSB dentro dos scripts determina o nível de execução no qual os scripts são executados, estou mais inclinado a pensar que systemd-sysv-generator usa /etc/init.d para decidir quais scripts devem ser iniciados em qual nível de execução em vez de /etc/rc?.d , exceto se isso não puder ser determinado a partir do cabeçalho do LSB dentro do script. As minhas suposições estão certas?

systemd-sysv-generator(8)

LSB headers[2] in SysV init scripts are interpreted, and the ordering specified in the header is turned into dependencies between the generated unit and other units. The LSB facilities "$remote_fs", "$network", "$named", "$portmap", "$time" are supported and will be turned into dependencies on specific native systemd targets.

Mas a página man não menciona nada relacionado ao caso em que não há cabeçalho LSB. Muito mais complicado:

    

Answer 1

Marquei sua pergunta como duplicata.

Leia a excelente resposta do JdeBP aqui: Como o systemd usa / scripts etc / init.d?

Received wisdom is that the System V rc scripts must have an LSB header, and are run in parallel without honouring the priorities imposed by the /etc/rc?.d/ system. This is incorrect on all points.

In fact, they don't need to have an LSB header, and if they do not systemd-sysv-generator can recognize the more limited old RedHat comment headers (description:, pidfile:, and so forth). Moreover, in the absence of an LSB header it will fall back to the contents of the /etc/rc?.d symbolic link farms, reading the priorities encoded into the link names and constructing a before/after ordering from them, serializing the services. Not only are LSB headers not a requirement, and not only do they themselves encode before/after orderings that serialize things to an extent, the fallback behaviour in their complete absence is actually significantly non-parallelized operation.

The reason that /etc/rc3.d didn't appear to matter is that you probably had that script enabled via another /etc/rc?.d/ directory. systemd-sysv-generator translates being listed in any of /etc/rc2.d/, /etc/rc3.d/, and /etc/rc4.d/ into a native Wanted-By relationship to systemd's multi-user.target. Run levels are "obsolete" in the systemd world, and you can forget about them.

A questão de qual é o caminho da pesquisa, na verdade, é abordada pelo que você citou em sua pergunta:

systemd-sysv-generator generates the service units that run the System V rc scripts from /etc/init.d, if it doesn't find a native systemd service unit by that name already existing in the other six locations.

Mais detalhadamente:

• Para os próprios scripts:
  • systemd-sysv-generator procura por uma variável de ambiente chamada SYSTEMD_SYSVINIT_PATH .
    • Se existir, espera-se que seja um caminho de pesquisa convencional separado por dois-pontos dos diretórios que systemd-sysv-generator varre um por um.
    • Se não existir, ou se tiver um valor vazio, systemd-sysv-generator recai sobre um padrão compilado, que no systemd vanilla é o diretório único /etc/init.d/ .
  • Cada diretório é verificado quanto a arquivos regulares que possuem o bit de permissão de execução do proprietário configurado, com diretórios anteriores no caminho substituindo os posteriores (um mecanismo não realmente exercido no caso padrão de apenas um diretório no caminho de pesquisa) e a existência de unidades de serviço com os mesmos nomes, inibindo a geração destes nonce.
• Para os "farms de link simbólico":
  • Existe uma variável de ambiente semelhante denominada SYSTEMD_SYSVRCND_PATH .
    • Se existir, espera-se que seja um caminho de pesquisa convencional separado por dois-pontos dos diretórios que systemd-sysv-generator varre um por um.
    • Se ele não existir, ou se tiver um valor vazio, systemd-sysv-generator voltará a um padrão compilado, que no systemd vanilla é o diretório único /etc/rc.d/ .
  • Cada diretório é varrido para os subdiretórios denominados rc[2345].d , que são por sua vez varridos para entradas de diretório que começam com S e dois dígitos decimais e que têm pelo menos 4 caracteres. As entradas do diretório não são desreferenciadas.

Observe que systemd-sysv-generator …

• … não parece no K* stuff;
• … não verifica que os farms de link simbólico estão realmente preenchidos com links simbólicos (Eles podem ser arquivos especiais de caracteres ou FIFOs para tudo que importa, já que somente olha para os nomes .); e
• … não processa as informações de nível de execução dos comentários do LSB (por exemplo, os comentários Default-Start: e Default-Stop: ).

Lembre-se, em relação ao terceiro ponto, que em baunilha van Smoorenburg rc as informações de nível de execução dos comentários do LSB não controlam diretamente o comportamento de inicialização / desligamento. Essa é a missão dos diretórios de farm de links simbólicos. Descrevendo van Smoorenburg rc na terminologia systemd: os farms de link simbólico são os controles enable do serviço, que determinam quais serviços são iniciados automaticamente no bootstrap; Considerando que os comentários Default-Start: e Default-Stop: são (muito aproximadamente) controles pré-definidos , que são transformados nos controles de ativação.