O que faz com que o comando import falhe ao executar um serviço

Question

Nosso serviço do System V executa um daemon que executa o comando de importação. Executar o serviço por sudo service myservice start parece iniciar o serviço, mas quando se trata de tirar uma captura de tela, a importação não funciona. A única maneira de capturar uma captura de tela é iniciar o serviço com /etc/init.d/myservice start. Depois disso, podemos capturar a captura de tela com o comando import.

Alguma idéia?

    

Answer 1

Não há uma resposta direta à sua pergunta, exceto "depende do ambiente", ou seja, da distribuição GNU / Linux.

Antes de entrar em detalhes semi-relevantes, você deve saber que o motivo pelo qual sudo service import-image-service não funciona é porque o comando import não possui informações suficientes sobre o ambiente para saber onde e como tirar a captura de tela. Leitura homem sudo revela:

 DESCRIPTION
   sudo allows a permitted user to execute a command as the superuser or
   another user, as specified by the security policy.

Isso é um pouco enigmático e aprender sobre essa "política de segurança" é divertido, mas talvez não seja uma de suas atividades favoritas. Eu dou a minha palavra que isso significa que os comandos iniciados com o sudo são executados em um ambiente isolado .

Por outro lado, /etc/init.d/myservice funciona porque o environment-setup-policy toma medidas para configurar alguns padrões normais, como export DISPLAY=:0.0 . Você terá que investigar as complexidades da distribuição em uso para descobrir como informar adequadamente um serviço sobre a presença de um servidor X. Nesse meio tempo, você pode tentar sudo -E service myservice

  -E      The -E (preserve environment) option indicates to the secu‐
       rity policy that the user wishes to preserve their existing
       environment variables.  The security policy may return an
       error if the -E option is specified and the user does not
       have permission to preserve the environment.

Alguns antecedentes

aviso: esta seção é semi-factual e tendenciosa historicamente

Os serviços em um sistema GNU / Linux se comportam de maneira arbitrária de uma distribuição para outra. Principalmente, a diferença está na configuração do ambiente antes que o serviço seja executado. Isso depende de vários fatores, sendo os mais importantes:

• sistema init
  • shell simples do System V init + posix (Slackware, Debian)
  • OpenRC (Gentoo)
  • Upstart (Ubuntu)
  • systemd (muitas distribuições recentes)
• distribuições environment-setup-policy *
• detalhes do script de inicialização específico

Debian, Slackware e Gentoo (OpenRC) usam uma abordagem concebivelmente semelhante, onde /etc/init.d/ services são scripts independentes que opcionalmente obtêm informações adicionais de / etc / default / servicename, / etc /conf.d/servicename e similar. Os scripts podem ou não depender da função init específica da distribuição, como / lib / lsb / init-functions ou /lib64/rc/sh/functions.sh. Essas bibliotecas de shell adicionais podem obter informações (configurar o ambiente) de fontes específicas de distribuição adicionais.

O Ubuntu (Upstart) e o systemd têm uma abordagem "inteiramente" diferente, em que cada serviço tem um arquivo de configuração e o sistema init faz toda a mágica.

Para entender completamente o que está acontecendo, é preciso ler e entender o sistema init e as peculiaridades da distribuição em uso.

* o processo de inicializar variáveis de ambiente e iniciar um serviço.

    

Answer 2

Isso é explicado claramente na página de manual do antigo sistema do Linux V service na primeira sentença :

service runs a System V init script in as predictable environment as possible, removing most environment variables and with current working directory set to /.

Como você acha que o comando image sabe onde encontrar seu servidor X? É a variável de ambiente DISPLAY , é claro.

Não confie na noção de que os serviços são executados em um ambiente de login interativo com terminais de controle, DISPLAY de variáveis de ambiente e assim por diante. Eles não. Se você criou um serviço com base nessas suposições, você o criou de maneira errada e criou algo que nem está funcionando para você agora , e muito menos que funcionará se você use um sistema init diferente, como systemd, upstart, nosh, runit e assim por diante, que asseguram que os serviços não sejam afetados pelos valores arbitrários das variáveis de ambiente de um shell interativo (e outro estado do processo) quando um serviço é ativado / para baixo.