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
eSIGPWR
paraSIGRTMIN + 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.
- Ele responde a um subconjunto razoavelmente grande dos sinais reconhecidos por
- 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 .
- Ele lê as mensagens de comando do
- 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.
- Ele lê as mensagens de comando do
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
eSIGPWR
, além de vários programas utilitários de sistema amplamente difundidos.- O
systemd
e o noshsystem-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, incluindoSIGSTOP
eSIGCONT
.
- O
- 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 Vinit
, 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 mecanismoinitctl
não está bem documentado. Mesmo as pessoas do System Vinit
andam por aí dizendo às pessoas que apenas as coisas no pacote System Vinit
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 parainit
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.