Como definir variáveis de ambiente global na inicialização por meio de um script e disponibilizá-las para um aplicativo que é executado antes do login?

Eu tenho um serviço que é executado na inicialização e, nesse serviço, chama um script bash em segundo plano que exporta algumas variáveis de ambiente. O problema que estou tendo é que essas variáveis de ambiente não estão sendo enviadas para o pai do processo em segundo plano, e assim que meu script é executado, elas desaparecem.

Além disso, após a execução do script, o serviço chama outro script que inicia um aplicativo que eu tenho. Este aplicativo precisa acessar essas variáveis de ambiente.

O sistema RHEL em que eu o executo deve nunca ser logado pelo usuário, ele apenas inicializa e inicia o aplicativo. Eu sei que as variáveis de ambiente para um processo / shell pai não podem realmente ser definidas por um shell de processo em segundo plano filho.

Eu preciso de uma maneira de fazer isso por meio de um script chamado pelo meu serviço (não necessariamente em segundo plano), não adicionando-os no meu serviço (que não funcionou para mim) e não armazenando-os em um /etc/environmentou .profileou algo assim.

No meu serviço, tentei adicionar as variáveis de ambiente (não o que eu quero fazer):

    export TEST=192.168.1.1

Eu também tentei isso no meu serviço:

    TEST=192.168.1.1
    export TEST=${TEST}

Tentei alterar como meu serviço chama o script bash:

    /bin/asdf/script &

Eu também tentei fornecer o script para que ele seja executado no mesmo shell (que obtive disso ):

    . ./bin/asdf/script
    #I'm very confused why this didn't work

Também achei isso interessante, mas não deu certo no meu caso.

— sqenixs
fonte

Respostas:

Você pode tentar colocar um script para reunir as variáveis em /etc/profile.d/

Exemplo:

/etc/profile.d/somescript.sh

#!/bin/bash
TEST=$(cat /var/somefile)
export $TEST

/etc/profilefaz uma chamada que executará qualquer script /etc/profile.d/e isso se aplica a todos os usuários do sistema, incluindo o root.

— madflojo
fonte

Você pode estar interessado em algo aqui. Eu não quero fazer exatamente isso, pois o script não pode ser localizado no diretório / etc por razões de IA. Mas acho que posso criar um link simbólico que aponte para o meu script. Mas, para complicar as coisas, algumas das variáveis de ambiente definidas pelo script são provenientes de variáveis de ambiente definidas pelo serviço. Portanto, isso pode não funcionar, pois as variáveis já devem estar definidas antes do script de serviço chegar ao fim, mas não muito cedo ou as variáveis de ambiente necessárias ainda não foram criadas pelo serviço.

— sqenixs

Acho que posso me livrar da dependência das variáveis definidas no serviço. Nesse caso, acho que funcionará, desde que o script seja executado antes da inicialização do serviço. Você sabe quando o shell de login é iniciado? Ou posso controlar quando o shell de login é iniciado? Não tenho um serviço no diretório rcX.d para o meu nível de execução.

— sqenixs

Não há como um processo influenciar o ambiente de outro processo existente. Os processos influenciam apenas o ambiente dos processos filhos.

Portanto, você precisa definir essas variáveis de ambiente em um ancestral do aplicativo que precisa delas. Em vez de fazer com que seu serviço chame separadamente o script bash de configuração do ambiente e o aplicativo, faça com que o serviço chame um script bash que defina as variáveis de ambiente e inicie o aplicativo.

#!/bin/bash
. /path/to/environment/variable/setter.bash
exec /path/to/application

— Gilles 'SO- parar de ser mau'
fonte

Pelo que li online, existem hacks (algo relacionado a eval em um script de origem ou usando gdb) para fazê-lo funcionar. Eu não estou muito interessado em estar em segundo plano, se eu puder executar os comandos no "shell" atual (você está em um shell durante a inicialização quando o serviço está sendo executado?), Isso também seria bom.

— sqenixs

Infelizmente, não consigo iniciar o aplicativo pelo serviço, pois existem muitos processos diferentes iniciados e coisas configuradas no script de início do aplicativo, e eles devem ser mantidos separados do serviço para IA.

— sqenixs

@sqenixs Um shell é um processo como qualquer outro. Não existe algo como "estar em uma concha". Quando você fala de "eval em um script de origem", é um protocolo em que um programa (que pode não ser um script de shell) imprime definições na sintaxe do shell, e um script de shell as interpreta. Definir variáveis de ambiente com o gdb pode funcionar, ou não tem efeito, ou pode travar seu aplicativo; como você pode imaginar, não é recomendável usar um depurador na produção (e, novamente, por um bom motivo).

— Gilles 'SO- stop be evil'

Provavelmente existe uma solução para o seu problema, mas você precisa ser mais preciso com seus requisitos. Na sua pergunta, você escreve "depois que o script é executado, o serviço chama outro script que inicia um aplicativo". Então você parece ter uma solução: defina as variáveis de ambiente dentro desse outro script. Mas, em um comentário, você escreve que "não pode iniciar o aplicativo a partir do serviço". Então, qual é?

— Gilles 'SO- stop be evil'

talvez, crie ou configure o ambiente de / sbin / init no momento da inicialização. Como todo processo é filho do init, o processo filho pode adquirir o ambiente. Apenas um pensamento / palpite.

— Nikhil Mulley

Como definir variáveis ​​de ambiente global na inicialização por meio de um script e disponibilizá-las para um aplicativo que é executado antes do login?

Como definir variáveis de ambiente global na inicialização por meio de um script e disponibilizá-las para um aplicativo que é executado antes do login?