Jak ustawić globalne zmienne środowiskowe podczas uruchamiania za pomocą skryptu i mieć je dostępne dla aplikacji działającej przed zalogowaniem?


17

Mam usługę, która działa podczas rozruchu, i w tej usłudze wywołuje skrypt bash w tle, który eksportuje niektóre zmienne środowiskowe. Problem, który mam, polega na tym, że te zmienne środowiskowe nie są wysyłane do elementu nadrzędnego procesu w tle, więc gdy tylko skrypt zakończy wykonywanie, znikają.

Ponadto po uruchomieniu skryptu usługa wywołuje inny skrypt uruchamiający aplikację, którą mam. Ta aplikacja potrzebuje dostępu do tych zmiennych środowiskowych.

System RHEL, na którym go uruchamiam, nie powinien być nigdy zalogowany przez użytkownika, uruchamia się tylko i uruchamia aplikację. Wiem, że zmienne środowiskowe dla procesu / powłoki nadrzędnej tak naprawdę nie mogą być ustawione przez powłokę procesu potomnego w tle.

Potrzebuję sposobu, aby to zrobić za pomocą skryptu wywoływanego przez moją usługę (choć niekoniecznie w tle), a nie poprzez dodawanie ich do mojej usługi (która nie działała dla mnie) i nie poprzez przechowywanie ich w /etc/environment lub .profilelub cokolwiek takiego.

W mojej usłudze próbowałem dodać zmienne środowiskowe (ale nie to, co chcę zrobić):

    export TEST=192.168.1.1

Próbowałem też tego w mojej usłudze:

    TEST=192.168.1.1
    export TEST=${TEST}

Próbowałem zmienić sposób, w jaki moja usługa wywołuje skrypt bash:

    /bin/asdf/script &

Próbowałem również pozyskać skrypt, aby działał w tej samej powłoce (którą otrzymałem z tego ):

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

Znalazłem też to, co wyglądało interesująco, ale tak naprawdę nie ułożyło się w moim przypadku.

Odpowiedzi:


12

Możesz spróbować umieścić skrypt do gromadzenia zmiennych /etc/profile.d/

Przykład:

/etc/profile.d/somescript.sh

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

/etc/profilewykonuje wywołanie, które uruchomi dowolny skrypt /etc/profile.d/, i dotyczy to wszystkich użytkowników w systemie, w tym użytkownika root.


Być może coś tu masz. Nie chcę tego jednak robić, ponieważ skryptu nie można znaleźć w katalogu / etc z powodów IA. Ale myślę, że mogę utworzyć tam dowiązanie symboliczne, które wskazuje mój skrypt. Ale dla uproszczenia niektóre zmienne środowiskowe ustawione przez skrypt pochodzą ze zmiennych środowiskowych ustawionych przez usługę. Może to nie zadziałać, ponieważ zmienne muszą być ustawione, zanim skrypt usługi dobiegnie końca, ale nie za wcześnie lub potrzebne zmienne środowiskowe nie zostaną jeszcze utworzone przez usługę.
sqenixs,

Chyba mogę pozbyć się zależności od zmiennych ustawionych w usłudze. W takim przypadku myślę, że będzie działać, dopóki skrypt zostanie uruchomiony przed uruchomieniem usługi. Czy wiesz, kiedy powłoka logowania jest uruchamiana? Czy mogę kontrolować, kiedy powłoka logowania się uruchamia? Nie mam usługi w katalogu rcX.d dla mojego poziomu uruchamiania.
sqenixs,

1

Proces nie ma wpływu na środowisko innego istniejącego procesu. Procesy wpływają tylko na środowisko ich procesów potomnych.

Musisz więc ustawić te zmienne środowiskowe w przodku aplikacji, która ich potrzebuje. Zamiast oddzielnego wywoływania przez usługę skryptu bash konfigurującego środowisko i aplikacji, usługa powinna wywoływać skrypt bash, który ustawia zmienne środowiskowe, a następnie uruchamia aplikację.

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

Z tego, co przeczytałem online, są hacki (coś związane z eval na skrypcie źródłowym lub używanie gdb), aby go uruchomić. Nie interesuje mnie to zbytnio w tle, jeśli mogę uruchomić polecenia w bieżącej „powłoce” (czy jesteś w powłoce podczas uruchamiania, gdy usługa jest uruchomiona?), To też byłoby w porządku.
sqenixs,

Niestety nie mogę uruchomić aplikacji z usługi, ponieważ uruchamianych jest wiele różnych procesów oraz elementy skonfigurowane ze skryptu uruchamiania aplikacji, które muszą być oddzielone od usługi dla IA.
sqenixs,

@sqenixs Powłoka to proces jak każdy inny. Nie ma czegoś takiego jak „bycie w skorupce”. Kiedy mówimy o „eval na skrypcie źródłowym”, jest to protokół, w którym program (który może nie być skryptem powłoki) drukuje definicje w składni powłoki, a skrypt powłoki interpretuje je. Ustawienie zmiennych środowiskowych za pomocą gdb może działać, może nie mieć żadnego efektu lub może spowodować awarię aplikacji; jak można sobie wyobrazić, korzystanie z debugera w środowisku produkcyjnym nie jest zalecane (i znowu z ważnego powodu).
Gilles „SO- przestań być zły”

Prawdopodobnie istnieje rozwiązanie twojego problemu, ale musisz być bardziej precyzyjny w stosunku do swoich wymagań. W swoim pytaniu piszesz „po uruchomieniu skryptu usługa wywołuje inny skrypt uruchamiający aplikację”. Wydaje się, że masz rozwiązanie: ustaw zmienne środowiskowe w tym drugim skrypcie. Ale w komentarzu piszesz, że „nie możesz uruchomić aplikacji z usługi”. Więc co to jest?
Gilles „SO- przestań być zły”

być może, stwórz lub skonfiguruj środowisko / sbin / init w czasie uruchamiania. Ponieważ i tak każdy proces jest potomkiem init, proces potomny może uzyskać środowisko. Tylko myśl / zgadnij.
Nikhil Mulley,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.