如何通过 systemd 中的 .conf 文件覆盖单元环境配置?

如何通过 systemd 中的 .conf 文件覆盖单元环境配置?

我已经在以下位置定义了这项服务/etc/systemd/system/gunicorn-production.service

[Unit]
Description=gunicorn production daemon
After=network.target

[Service]
PIDFile=/run/gunicorn_production/pid
User=www-data
Group=www-data
RuntimeDirectory=gunicorn_production
WorkingDirectory=/home/production/current
Environment=WORKERS='2'
ExecStart=/home/production/.virtualenvs/production/bin/gunicorn \
-w $WORKERS \
...
# rest of gunicorn configuration parameters

该服务通过指定的 2 个工作程序启动/重新加载/停止等。

我打算将所有硬编码路径移动到一个配置文件中,以便我可以重用此服务定义,并且我开始WORKERS在“drop in”目录中的文件中定义/etc/systemd/system/gunicorn-production.d/gunicorn-production.conf::

[Service]
Environment=WORKERS='4'

如果我systemctl daemon-reload这样,那么systemctl restart gunicorn-production4 个工作器的配置就不会生效。我尝试了各种配置/文件名排列,但似乎无法通过文件覆盖环境设置.conf

根据手册页 systemd.units 看起来“放入”目录应该可以解决问题:

除了单元文件 foo.service 之外,还可能存在一个“嵌入式”目录 foo.service.d/。此目录中所有带有“.conf”后缀的文件将在解析文件本身后解析。这对于更改或添加单元的配置设置非常有用,而无需修改单元文件。每个嵌入式文件都必须具有适当的节标题。请注意,对于实例化的单元,此逻辑将首先查找实例“.d/”子目录并读取其“.conf”文件,然后查找模板“.d/”子目录和其中的“.conf”文件。另请注意,“[Install]”节中的设置在嵌入式单元文件中不受尊重,并且不起作用。

答案1

我错误地命名了 drop-in 目录。我将其命名为:,/etc/systemd/system/gunicorn-production.d但实际上应该是:/etc/systemd/system/gunicorn-production.service.d。修复后,我使用了新的环境值。

答案2

首先将环境设置为空(理论上这应该重置变量),然后将其设置为 4。

[Service]
Environment=
Environment=WORKERS='4'

我不确定它是否会起作用,但这是使用插入文件重置 systemd 单元文件令牌的方法。

相关内容