Сразу пример:
[Service]
Environment="FOO=bar"
ExecStart=/bin/bash /usr/local/sbin/bashdays.sh
Сделал юнит, но в скрипт
bashdays.sh не передаётся переменная FOO. Хотя логически всё правильно.Тут снова приколы.
➡️ 1. Скрипт запускается не напрямую, а через интерпретатор.
Если в
ExecStart указан скрипт с shebang’ом (#!/bin/bash), systemd запускает его как отдельный процесс, и переменные окружения передаются.ㅤ
Но если ты укажешь в
ExecStart сам интерпретатор, вот так:ExecStart=/bin/bash /usr/local/sbin/bashdays.sh
То переменная
FOO, заданная через Environment=, не попадёт в подскрипт, потому что ExecStart запускает bash, а уже bash запускает — скрипт, и переменные окружения само собой нихуя не передаются.Как правильно?
Вот так:
[Service]
Environment="FOO=bar"
ExecStart=/usr/local/sbin/bashdays.sh
А сам скрипт:
#!/bin/bash
echo "FOO is $FOO"
Всё! Теперь переменная из юнита будет корректно передаваться в скрипт.
➡️ 2. Использовать EnvironmentFile=
Если у тебя дохуя переменных, то выносим их в отдельный файл, например сюда
/etc/bashdays-service.env.FOO=bar
BAZ=qux
А в самом юните прописываем:
[Service]
EnvironmentFile=/etc/bashdays-service.env
ExecStart=/usr/local/sbin/bashdays.sh
Всё! Теперь переменные считываются из файла и скрипт их видит.
➡️ 3. Передавать переменные прямо в ExecStart
[Service]
ExecStart=/bin/bash -c 'FOO=bar exec /usr/local/sbin/bashdays.sh'
Тут особо и комментировать нечего, всё очевидно.
Как отладить и задебажить?
А вот так:
systemctl show nginx
Вместо nginx подставляешь свой сервис и наблюдаешь все переменные которые передались. В наших примерах увидишь
Environment=FOO=bar.Справедливо не только для собственных юнитов, но и для других, например для того же nginx или docker.
Как вариант, можешь добавить в скрипт такую хуйню:
env > /tmp/env.log
И смотришь, какие переменные реально передаются в твой скрипт.
Еще одна база выдана, вроде очевидные вещи, но так глубоко в это никто не лезет. Пользуйся.
🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog