Linux - IPC com init

Question

O processo init existe como um ancestral de todos os processos em um sistema linux. Esse processo tem algum tipo de ponto de entrada do IPC? Outros processos já fazem o IPC com o init por algum motivo?

    

Answer 1

Não confunda processos e programas. Existe um processo # 1, mas ele pode estar executando um de vários programas diferentes.

• Se estiver executando o programa systemd do pacote systemd:
  • Existe uma API interna do systemd acessível via D-Bus, que não é garantida como estável e não se destina a ser usado por coisas fora do pacote systemd.
  • Ele responde a um grande conjunto de sinais , variando de SIGWINCH e SIGPWR para SIGRTMIN + 4 .
• Se estiver executando o programa system-manager de o pacote nosh :
  • Ele responde a um subconjunto razoavelmente grande dos sinais reconhecidos por systemd , com os mesmos significados quando aplicável.
• Se estiver executando o programa init do upstart:
  • Existe uma API interna de upstart , acessível via D-Bus.
  • Ele lê as mensagens de comando do initctl FIFO.
  • Responde a pequenos conjuntos de sinais.
• Se estiver executando finit de Joachim Nilsson:
  • Ele lê as mensagens de comando do initctl FIFO.
  • Ele responde a um pequeno conjunto de sinais .
• Se estiver executando o sistema 5 init , então:
  • Ele lê as mensagens de comando do initctl FIFO.
  • Ele responde a um conjunto muito pequeno de sinais.

Algumas notas:

• A API de sinal é obrigatória pelas coisas que enviam os sinais para processar # 1. Isso inclui o kernel do sistema operacional, que envia itens como SIGWINCH , SIGINT e SIGPWR , além de vários programas utilitários de sistema amplamente difundidos.
  • O systemd e o nosh system-manager estendem isso com sinais de que o estado do sistema de comando é alterado (como desligar e desligar o sistema).
  • Nem todos os documentos do programa suportam o conjunto completo de sinais obrigatórios do sistema. O upstart não faz menção de responder a SIGPWR , por exemplo.
  • finit reconhece um conjunto diferente de sinais estendidos não obrigatórios pelo sistema, incluindo SIGSTOP e SIGCONT .
• Embora o pacote systemd não implemente a API initctl FIFO no programa que é executado como o processo nº 1, ele fornece um shim de compatibilidade no outro processo , executando outro programa, que traduz esse mecanismo em mecanismos nativos do systemd.
  • initctl não é nativo de nada, exceto do System V init , já que os outros (se o fizerem) implementam apenas a noção de níveis de execução como um mecanismo limitado de compatibilidade com versões anteriores.
  • Como diz a página man upstart do seu programa init , o mecanismo initctl não está bem documentado. Mesmo as pessoas do System V init andam por aí dizendo às pessoas que apenas as coisas no pacote System V init devem usá-lo. Não ajuda, além disso, que os mantenedores do Sistema V do Debian tenham mudado de /dev para /run .

Então, sim, os programas fazem IPC com o processo # 1. Suas razões para isso variam.

• O programa systemd é um gerenciador de combinação de sistemas, gerenciador de serviços e gerenciador de grupos de controle e, portanto, há muitas finalidades para as quais os programas empregam IPC para processar # 1. O mesmo para init do upstart.
• Para os system-manager de nosh, por outro lado, o gerenciamento serviço é feito por outro programa ( service-manager ) em outro processo com suas próprias APIs (compatíveis com daemontools). Portanto, a única razão para fazer o IPC com o processo nº 1 é para o gerenciamento do estado do sistema , como (digamos) reinicializar a máquina.

Para muitos (não todos) propósitos, é melhor ficar com outras APIs, usando utilitários de sistema convencionais para fazer coisas como desligar e reinicializar o sistema, em vez de enviar os sinais compreendidos pelos programas system-manager e systemd quando eles estão executando como processo # 1.

Leitura adicional

• link