是否可以像下面的示例一样配置 systemd 服务?我要实现用户,团体和目录在 /etc/default/service 等额外文件中进行配置。
我的目标环境是 OpenSuse Linux 15.1。系统234
[Unit]
Description=Sample Service
After=network.target
[Service]
User=$USER
Group=$GROUP
Type=simple
WorkingDirectory=$DIR
ExecStart=/opt/123/service.sh start
ExecStop=/opt/123/service.sh stop
Restart=on-failure
[Install]
WantedBy=multi-user.target
PS:仍然可以在 service.sh 中进行配置文件解析并发出用户特定的操作。不过我想知道一种简单的直接方法。
答案1
systemd 的人不喜欢环境文件。
/etc/default/example
在这种情况下当然是一个环境文件。
多年来,一些 systemd 人员曾公开表示,环境文件是他们一开始就不应该提供给 systemd 的机制。
毕竟,本机 systemd 机制就是服务单元文件本身。在他们看来,使用管理员定义的或特定于计算机的内容自定义服务只需放入.conf
单元的片段文件,即可在主单元文件中添加或替换键。
为用户生成具有参数化设置的包定义的主要服务单元以及诸如此类的内容是文本处理和宏替换的问题,以从模板创建实际的服务单元,就像许多包所做的那样。
(但老实说,尝试将内容动态转换为适合EnvironmentFile=
.[…]还有/etc/sysconfig
一种真正应该消失的红帽主义,整个概念都是有缺陷的。添加新的/run/sysconfig/
肯定会使情况变得更糟。)
EnvironmentFile=
我可能一开始就不应该添加。打包者误解了单元文件受管理配置的约束,并且应该如此对待,并且将单元文件的配置拆分成单独的文件EnvironmentFiles=
是一种非常无意义的不必要的间接游戏。
— 伦纳特·珀特林 (2015-12-09)。关于“环境文件”的查询。 systemd-开发。
使用— 伦纳特·珀特林 (2015-07-22)。请考虑为整个单元文件添加变量。系统错误#618。 GitHub。EnvironmentFile=
几乎总是一个坏主意,我们可能永远不应该添加它,因为它会邀请打包者重新引入我们试图消除的疯狂/etc/default/
。/etc/sysconfig/