У меня есть продукт, предоставленный сторонним поставщиком. Он включает в себя множество служб, для которых они предоставляют сценарии запуска в стиле initd. Для каждой предоставляемой услуги существует один скрипт.
Эти сценарии ссылаются на такие переменные, как JAVA_HOME, THE_PRODUCT_HOME и так далее. Ожидание от поставщика, что я должен отредактировать эти скрипты вручную и жестко закодировать правильные значения. Я бы предпочел, чтобы эти переменные были инициализированы из переменных окружения, полученных из systemd при загрузке системы.
Я знаю, что могу создать файл конфигурации переопределения для каждой из служб, чтобы предоставить необходимые envirables (также известные как переменные среды), используя systemctl edit theService
, но:
До сих пор я пытался использовать systemctl set-environment VAR_NAME=some_value
.
Это работает отлично - пока я не перезапущу систему. Кажется, что установленные таким образом переменные определены глобально, но не сохраняются после перезагрузки. Я также пытался использовать systemctl daemon-reload
на всякий случай, когда это необходимо для «фиксации» настроек (но, похоже, это не сохраняет глобальные envirables).
На данный момент я отредактировал каждый из предоставленных сценариев запуска и source /path/to/theGlobalVariablesINeed.sh
Это отлично работает как обходной путь, но не является моим предпочтительным решением в будущем...
Вот иллюстрация того, что происходит:
[root@dav1-td1 -> ~] # systemctl show-environment
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
[root@dav1-td1 -> ~] #
[root@dav1-td1 -> ~] # systemctl set-environment SYSD_PRODNAME_JAVA_HOME=/usr/java/jdk1.8.0_181-amd64/jre
[root@dav1-td1 -> ~] # systemctl set-environment SYSD_PRODNAME_HOME=/opt/TheProduct-1.2.3
[root@dav1-td1 -> ~] # systemctl daemon-reload # This is optional, if I run the reload, or do not run the reload, the variables are still lost over a reboot.
#### Now some variables are set, If I restart a service, the service will
#### Pick up these environmental variable settings.
[root@dav1-td1 -> ~] # systemctl show-environment
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
SYSD_PRODNAME_HOME=/opt/TheProduct-1.2.3
SYSD_PRODNAME_JAVA_HOME=/usr/java/jdk1.8.0_181-amd64/jre
[root@dav1-td1 -> ~] #
#### After restart, the variables have disappeared !?!?
[root@dav1-td1 -> ~] # systemctl show-environment
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
[root@dav1-td1 -> ~] #
Как упоминалось выше, когда я перезагружаю систему, все настройки, которые я установил с помощью systemctl set-environment VAR=value
, теряются.
Мне нужны эти переменные, чтобы пережить перезапуск (без использования файлов переопределения для каждой службы и без необходимости получать файл, содержащий все переменные)
Есть разные способы подойти к этой проблеме.
Вы можете отредактировать /lib/systemd/system/system.conf
и добавить контент, как показано ниже.
[Manager]
DefaultEnvironment=A=B C=D
[Unit]
Description=Example systemd service init
[Service]
Type=simple
ExecStart=/bin/systemctl set-environment VAR_NAME=some_value
[Install]
WantedBy=sysinit.target
Точка импорта использует WantedBy=sysinit.target
, поэтому она загружается раньше
и теперь мы можем создать простой сервис для проверки этого
[Unit]
Description=Example systemd service.
[Service]
Type=simple
ExecStart=/usr/bin/env
[Install]
WantedBy=multi-user.target
и результат
root@vagrant:/lib/systemd/system# systemctl status tarun
● tarun.service - Example systemd service.
Loaded: loaded (/lib/systemd/system/tarun.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sat 2019-06-15 11:31:17 UTC; 5s ago
Process: 1712 ExecStart=/usr/bin/env (code=exited, status=0/SUCCESS)
Main PID: 1712 (code=exited, status=0/SUCCESS)
Jun 15 11:31:17 vagrant systemd[1]: Started Example systemd service..
Jun 15 11:31:17 vagrant env[1712]: A=B
Jun 15 11:31:17 vagrant env[1712]: C=D
Jun 15 11:31:17 vagrant env[1712]: LANG=en_US.UTF-8
Jun 15 11:31:17 vagrant env[1712]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Jun 15 11:31:17 vagrant env[1712]: VAR_NAME=some_value
Надеюсь, мой вопрос (и ваш ответ) поможет другим в будущем!
@GMc, рад помочь :-)
Спасибо @Tarun_Lalwani - я не могу поверить, что потратил дни на чтение справочных страниц, поиск в Интернете, пробы и ошибки, чтобы найти что-то новое, что было бы просто, - но просто не мог увидеть. Ты был тем «чем бы то ни было», что позволило мне найти иголку в стоге сена! Спасибо еще раз.