«Сервис» -команда и переменные среды

8

Я пытаюсь запустить службу, которая требует env. переменная для установки на определенный путь. Я установил эту переменную в "/etc/profile.d/". Однако, когда я запускаю этот сервис с помощью serviceкоманды, он не работает.

человек службы:

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

Так что кажется, что serviceудаляет мои переменные. Как мне установить переменные, чтобы они не были удалены. Или это то, что я не должен делать.

Я мог бы запустить службу вручную, используя init-скрипты, или даже жестко указать путь к скрипту, но я хотел бы знать, как использовать его с serviceкомандой.

— Эса Варемо
источник

4

Начиная с Fedora 16, serviceтолько принимает LANGи TERMпеременные окружения, все остальное отбрасывается. Так что, даже если ваш текущий {CentOS, RHEL} каким-то образом принимает переменные, будьте готовы к будущему, где он больше не работает.

Таким образом, жесткое программирование сценария инициализации и / или установка переменных в самом файле настроек демона будет вашим выбором.

— Янне Пиккарайнен
источник

Недостатком является то, что каждый раз, когда я обновляю приложение, мне приходится менять файл, но я думаю, что мне просто нужно ... (... не часто обновлять)

— Esa Varemo

Что ж, «обновление часто» в наши дни является нормой. Живи с этим.

— Янне Пиккарайнен

6

Рекомендуется поместить параметры конфигурации в конфигурацию, в /etc/sysconfig/<servicename>которой они затем читаются сценарием инициализации.

С уважением

Брэм

— Брэм
источник

В качестве другого совета в /etc/sysconfig/<servicename>файле вы можете использовать bash sourceдля загрузки файлов, /etc/profile.dчтобы имитировать среду входа в оболочку.

— Адам Гент

2

От man 5 init:

   Рабочая среда
       Каждое задание запускается со средой из событий или команд, которые его запустили. Кроме того, вы можете определить значения по умолчанию в
       задание, которое может быть переопределено позже и указать, какие переменные среды экспортируются в события, сгенерированные для задания.

       Специальная переменная среды UPSTART_EVENTS содержит список событий, запустивших задание, и не будет присутствовать, если
       Работа была начата вручную.

       Кроме того, сценарии pre-stop и post-stop выполняются в среде событий или команд, которые остановили задание.
       Переменная среды UPSTART_STOP_EVENTS содержит список событий, которые остановили работу, она не будет присутствовать, если работа
       был остановлен вручную.

       Все задания также содержат переменные среды UPSTART_JOB и UPSTART_INSTANCE, содержащие имя задания и экземпляр.
       В основном они используются утилитой initctl (8), чтобы по умолчанию они выполняли задания, из которых вызываются команды.

       КЛЮЧ env [= ЗНАЧЕНИЕ]
              Определяет переменную среды по умолчанию, значение которой может быть переопределено событием или командой, запускающей задание.
              Если указано «KEY = VALUE», переменной KEY присваивается значение VALUE. Если задан только «ключ», значение берется
              из собственного окружения демона init (8).

       ключ экспорта
              Экспортирует значение переменной среды в события старт (7), старт (7), останов (7) и останов (7) для этого
              задание и все последующие события (а не только те, которые относятся к текущему заданию).

Кроме того, вы можете сделать, grep env /etc/init/*чтобы увидеть, как используется

Это мой вывод:

/etc/init/container-detect.conf:env container
/etc/init/container-detect.conf:env LIBVIRT_LXC_UUID
/etc/init/container-detect.conf: # - проверить наличие «контейнера» в среде init.
/etc/init/container-detect.conf: [-d / proc / vz] && [! -d / proc / bc] && container = openvz
/etc/init/mounting-debugfs.conf:env MOUNTPOINT = / sys / kernel / debug
/etc/init/mounting-dev.conf:env MOUNTPOINT = / dev
/etc/init/mounting-proc.conf:env MOUNTPOINT = / proc
/etc/init/mounting-tmp.conf:env MOUNTPOINT = / tmp
/etc/init/munin-node.conf:env DAEMON = / usr / sbin / munin-node
/etc/init/mysql.conf:env HOME = / etc / mysql
/etc/init/nginx.conf:env DAEMON = / usr / local / nginx / sbin / nginx
/etc/init/nginx.conf:env PID = / usr / local / nginx / logs / nginx.pid
/etc/init/procps.conf:env UPSTART_EVENTS =
/etc/init/rc.conf:env INIT_VERBOSE
/etc/init/rc-sysinit.conf:env DEFAULT_RUNLEVEL = 2
/etc/init/rc-sysinit.conf:env RUNLEVEL =
/etc/init/rc-sysinit.conf:env PREVLEVEL =
/etc/init/rc-sysinit.conf:env INIT_VERBOSE
/etc/init/wait-for-state.conf:env TIMEOUT = 30
/etc/init/wait-for-state.conf:env MANUAL_OVERRIDE = "N"
/etc/init/wait-for-state.conf:env WAIT_FOREVER = "N"
/etc/init/wait-for-state.conf:env WAIT_STATE = "начато"
/etc/init/wait-for-state.conf:env TARGET_GOAL = "start"

И для исчерпывающего примера посмотрите некоторые из этих сценариев. Здесь nginx.conf:

# nginx

описание "nginx http daemon"
автор "Филипп Клозе"

начать (файловая система и сетевое устройство IFACE = lo)
остановитесь на уровне выполнения [! 2345]

env DAEMON = / usr / local / nginx / sbin / nginx
env PID = / usr / local / nginx / logs / nginx.pid

ожидать форк
респаун
предел возрождения 10 5
# никогда

предстартовый скрипт
 $ DAEMON -t
 если [$? -не 0]
 затем выйдите из $?
 фи
конец сценария

exec $ DAEMON

— jperelli
источник