O systemd pode 'adotar' ou 'herdar' um processo ou cgroup?

Question

Eu tenho um serviço que gostaria de gerenciar através do systemd - vamos chamá-lo de foo . Eu escrevi arquivos de unidade e eles estão funcionando muito bem. Portanto, se eu executar systemctl start foo , o serviço será iniciado corretamente e eu posso ver seu status com systemctl status foo .

No entanto, um programa externo também pode iniciar o serviço e não usa o systemd para iniciar o serviço. Então, o serviço pode estar rodando, mas como não foi iniciado através do systemd, o systemd não sabe disso. Nesse caso, systemctl status foo informa que o serviço falhou, mesmo que esteja sendo executado corretamente.

Existe uma maneira de ter systemd 'herdar' ou 'adotar' este serviço, então systemctl status foo informa corretamente que o serviço está sendo executado, mesmo quando o systemd não o iniciou? Com o SysV, eu escreveria um pequeno script 'status', então eu poderia /etc/init.d/foo status , mas isso não parece se encaixar no modelo systemd.

Para ser claro, quando o programa externo inicia o serviço, os processos do serviço ainda são filhos do PID 1 / systemd. Mas, o systemd não os reconhece como parte do serviço foo , já que o systemd não iniciou e registrou-os.

As tecnologias específicas são:

• Oracle WebLogic (o serviço é uma instância do WebLogic gerenciado)
• Oracle NodeManager (este é o programa externo que também pode iniciar o serviço)
• systemd 219

Answer 1

Não. O processo será executado em um contexto diferente no que diz respeito ao systemd.

Esta é, na verdade, uma das razões pelas quais a ativação do serviço DesktopBus deve ser evitada. Os processos de serviço gerados diretamente pelo broker Desktop Bus fazem parte de seu serviço, no que diz respeito ao systemd.

Pode-se mover processos entre grupos de controle, com privilégios apropriados. Mas isso é apenas metade do trabalho, e a outra metade, a de convencer o sistema de que iniciou uma unidade quando isso não aconteceu e de reescrever as partes necessárias de suas estruturas internas de dados, não é fornecida.

Este não é apenas o modelo do systemd, não é o modelo da maioria dos subsistemas de gerenciamento de serviços.

As unidades de serviço "muito bem" de muitos demais para softwares Oracle, na verdade, não são, a propósito, e estão em território Casa do Horror .

Leitura adicional

• systemctl falha ao relatar com precisão o status dos daemons se eles foram iniciados por meio de mecanismo diferente de systemctl
• configure o daemon java com o systemd
• link
• Jonathan de Boyne Pollard (2016). Evite a ativação do barramento do Desktop Bus (D-Bus) . nosh. Softwares.
• Jonathan de Boyne Pollard (2015). A casa do sistema de terror . Respostas frequentemente dadas.

Answer 2

Em suma, não há como o systemd considerar que um serviço seja iniciado, a menos que tenha sido iniciado pelo próprio systemd. Um dos principais pontos do systemd é a consistência no gerenciamento de serviços e ter formas separadas de iniciar um serviço contraria essa ideia.

Agora, o systemd tem uma provisão para gerenciar processos que são iniciados externamente, o que parece ser um pouco adequado para o caso que você descreve. Na verdade, é um tipo separado de unidade, uma unidade de escopo .

O uso de uma unidade de escopo ainda requer que seu sistema externo interaja com o systemd, já que uma unidade de escopo só pode ser iniciada com uma solicitação D-Bus para systemd, na qual é passado um PID que é usado como o processo inicial no escopo . Além disso, quando uma unidade de escopo é iniciada, o systemd ainda deseja criar o cgroups (ele moverá o PID passado para os cgroups criados). Portanto, isso precisa do suporte do aplicativo para criar novos processos, se quiser que o systemd gerencie os cgroups. como um escopo.

Em suma, evite ter duas maneiras separadas para iniciar um serviço. Se você precisar usar o gerenciador de serviços de terceiros, use apenas isso.

Se o problema que você está tentando resolver é iniciar o serviço durante a inicialização, então:

1. Verifique se o seu gerente de terceiros (no seu caso, o Oracle NodeManager) suporta a configuração de serviços durante a inicialização. Como está gerenciando o serviço, ele deve gerenciar o serviço durante a inicialização também.

2. Se você se envolver no sistema, use uma simples unidade de serviço oneshot que simplesmente solicite ao gerente de terceiros que inicie o serviço. Isso significa entrar em contato com o gerente de terceiros (no seu caso, o Oracle NodeManager) por meio de uma API ou RPC de algum tipo, talvez por meio de HTTP, e avisá-lo para iniciar o serviço.

Se você usar o systemd oneshot para inicialização, nomeie sua unidade apropriadamente (como "start-foo" ou "initial-foo" ou "foo-startup") para deixar claro que não vai ficar "up" ", e mantenha RemainAfterExit= como no (o padrão), então verificar o status nessa unidade apenas terminará com sucesso, então não há nenhuma confusão sobre isso refletindo o status do serviço sendo executado sob o gerenciador de terceiros.