systemd 的人员不喜欢环境文件。

systemd 的人员不喜欢环境文件。

我目前正在重写upstart要使用的工作systemd,我想知道:

哪里是“默认”的地方EnvironmentFile

它可能会进入/etc/environment

它可能与中的所有其他服务文件有关/etc/systemd/service/run/systemd/system或者但我在这些位置/lib/systemd/system没有看到任何其他的。EnvironmentFileService

我也曾辩论/etc/default//etc/<PACKAGE_NAME>

没有记录“常规”位置来放置它。我见过的许多示例似乎都使用了/tmp/<FILE_NAME>毫无意义的文件,因为它们在重新启动时会被清除,并且这些文件需要保留,以便在启动或重新启动/tmp时可以引用它们。Service


背景:我在安装 debian 包之前在预安装时生成EnvironmentFile(使用维护脚本),并且我知道每次启动/重新启动服务时该文件都必须可用。

答案1

其他人回答了这个问题Unix & Linux Stack Exchange 上的地点。

(以下摘录)


systemd 的人员不喜欢环境文件。

所以没有。

多年来,许多 systemd 人员都曾公开表示,环境文件是一种机制,他们根本不应该把它交给 systemd。

毕竟,原生的 systemd 机制是服务单元文件本身,其中环境变量是用Environment=键设置的。在他们看来,使用管理员定义或特定于机器的变量来定制服务环境,就是将代码片段.conf文件放入单元中,用进一步的键设置其他环境变量Environment=

(但老实说,尝试将内容动态地转换为适合的文件确实毫无意义EnvironmentFile=[…]也是/etc/sysconfig一种应该彻底消除的 Redhatism,整个概念都是有缺陷的。添加新的/run/sysconfig/肯定会让情况变得更糟。)

EnvironmentFile=我可能一开始就不应该添加。打包者误解了单元文件受管理员配置的约束,应该这样对待,而将单元文件的配置拆分成单独的EnvironmentFiles=文件是一种非常无意义的、不必要的间接游戏。
— Lennart Poettering(2015-12-09)。关于“EnvironmentFile”的查询.systemd-开发。

使用EnvironmentFile=几乎总是一个坏主意,我们可能永远不应该添加它,因为它会邀请包装者重新引入我们试图删除的/etc/default/和疯狂。/etc/sysconfig/
— Lennart Poettering(2015-07-22)。请考虑为整个单元文件设置变量. systemd 错误 #618。GitHub。

奖励内容

在 daemontools 世界中,我们有环境目录当然,使用envdir/s6-envdir命令读取。虽然这不是 daemontools 的标准或要求,但习俗人们可以使用的与某些工具一致的是环境目录被命名并且与程序和其他内容env一起位于服务目录中。run

相关内容