Início / unix / Perguntas / 461454
Accepted
WoJ
Asked: 2018-08-09 23:39:03 +0800 CST

Como se pode verificar no programa se é um processo de serviço que foi iniciado pelo systemd? [duplicado]

  • 772

Existe uma maneira documentada de verificar, de dentro do código do programa em execução como o próprio serviço , que ele foi iniciado systemd(em vez de ser iniciado de dentro de uma sessão de login interativa, do cron, etc.)?

Minha solução atual é definir uma variável de ambiente na .serviceunidade ( Environment=...) e verificar sua existência no meu código. Mas pode haver algo diretamente disponível.

systemd services

2 respostas

  1. Best Answer

    Um não pode.

    Tudo o que o systemd fornece a um processo chamado para um serviço – seus argumentos, seu ambiente, o(s) grupo(s) de controle que o contém, seus limites de recursos, seus descritores de arquivos abertos – pode ser e é feito por outros gerenciadores de serviço também. Além disso, não há convenção compartilhada para identificar qual gerente de serviço está gerenciando serviços; sem variáveis ​​de ambiente convencionais, nem outros marcadores.

    Mecanismos errôneos

    Você pode estar pensando em verificar o nome executável do processo pai. Este é um não inicial, pelos motivos expostos em https://unix.stackexchange.com/a/196252/5132 . O nome da imagem do programa executável do processo pai (para serviços de todo o sistema) estará /sbin/initnos sistemas operacionais Debian Linux, porque o Debian tem a convenção de ser um link simbólico de estilo alternativo para o arquivo de imagem do programa do processo 1 real, e o /initprograma no initramfs precisando apenas saber esse nome.

    Você pode estar pensando que, apesar do que acabei de escrever, os grupos de controle são um marcador do systemd. Eles não são. Aqui está a árvore do grupo de controle de um processo de serviço sendo gerenciado por um gerenciador de serviço completamente diferente, service-managerdo conjunto de ferramentas nosh:

    % systemd-cgls /system.slice/service-manager.service/[email protected]
Grupo de controle /system.slice/service-manager.service/[email protected]:
└─[email protected]
  └─1433 tinydns
%

    O tinydnsprograma, encontrando um grupo de controle em /proc/self/cgroup, não tem justificativa para supor que o systemd configurou esse grupo de controle. Na verdade, foi configurado pelo move-to-control-grouputilitário:

    % cat /var/local/sv/[email protected]/service/run
#!/bin/nosh
#Executar arquivo gerado a partir de ./[email protected]
Soquete #DNS/UDP em 127.53.0.1
udp-socket-listen --systemd-compatibility --combine4and6 127.53.0.1 domínio
move-to-control-group "../[email protected]/[email protected]"
envdir env
envuidgid -- tinydns-d
setlogin -- tinydns-d
hardlimit -d 3000000
softlimit -d hard
./serviço
%

    Nenhuma outra alteração de estado do processo é exclusiva do systemd. As variáveis ​​de ambiente podem ser definidas com setenv(a ferramenta de carregamento de cadeia) userenv, machineenv, ou export(a ferramenta de carregamento de cadeia), limites de recursos com softlimit, ulimit(a ferramenta de carregamento de cadeia) ou s6-softlimit, descritores de arquivos abertos com redirfdou fdredir, namespaces com unshare, prioridades de agendamento com rtprioou chrt, política NUMA com numactl; e assim por diante.

    systemd não é o único falante do LISTEN_FDSprotocolo, como pode ser visto a partir do acima. INVOCATION_IDtambém é apenas um exercício de preenchimento env/INVOCATION_IDno início de um runprograma e encadeamento através de envdir. Nenhum deles é confiável como marcadores.

    Erros conceituais

    Há também a falha que você deseja excluir processos iniciados por cron. A falha conceitual aqui é que croné um serviço, e os processos que ele gera estão sendo executados no contexto desse serviço . Não há distinção mágica entre um processo gerado pelo cronprocesso no cronserviço e um processo gerado por algum outro processo de serviço em algum outro serviço, o que torna o primeiro de alguma forma distinguível do segundo.

    Livre-se desse erro conceitual e uma resposta aparecerá. A única coisa que distingue os daemons é que as sessões (POSIX) às quais eles pertencem não possuem terminais de controle, e eles não têm outras associações (do nome definido por setlogin, através do mecanismo de sessão de login do espaço do usuário do systemd, para vários contextos de segurança) com qualquer sessão de login. Não há uma maneira direta portátil de consultar qual é o terminal de controle de uma sessão, mas observar que a abertura /dev/ttyfalha é uma rota indireta disponível. Observe que algumas funções da biblioteca C superficialmente promissoras não são realmente confiáveis ​​na prática.

    Leitura adicional

    • 2

  2. Eu acho que você pode usar o seguinte comando:

    #> systemctl list-unit-files --state=enabled
cups.path                                  enabled        
accounts-daemon.service                    enabled        
anacron.service                            enabled        
apparmor.service                           enabled        
atd.service                                enabled        
[email protected]                            enabled        
avahi-daemon.service                       enabled        
...

    Por si só systemctl list-unit-fileslista todos os arquivos de unidade instalados que podem iniciar um serviço. Os rotulados como enabledsão aqueles iniciados no momento em que você digita o comando.

    • 0

relate perguntas