![在用户服务中,是否可以从用户会话继承环境变量?](https://linux22.com/image/184260/%E5%9C%A8%E7%94%A8%E6%88%B7%E6%9C%8D%E5%8A%A1%E4%B8%AD%EF%BC%8C%E6%98%AF%E5%90%A6%E5%8F%AF%E4%BB%A5%E4%BB%8E%E7%94%A8%E6%88%B7%E4%BC%9A%E8%AF%9D%E7%BB%A7%E6%89%BF%E7%8E%AF%E5%A2%83%E5%8F%98%E9%87%8F%EF%BC%9F.png)
通常,使用 Systemd 启动的服务会被赋予一个“干净”的环境,该环境不会从用户会话继承。这是设计使然,也是一个很好的默认值。
不过,我为自己编写了一些服务(例如~/.config/systemd/user/foo.service
),可以方便地继承我在 X 会话中设置的环境变量,例如XDG_DATA_HOME
.
我不想将环境变量的值硬编码到每个服务中。
有什么方法可以向 systemd 表明我做想要继承用户服务启动的环境?
或者至少(也许更好)我可以将要继承的特定环境变量列入白名单吗?
目前,我的环境变量是在 POSIX shell 脚本中配置的,我在X 和shell中都获取了该~/.xsessionrc
脚本(及其非 Debian 等效项) 。~/.profile
如果有帮助,我愿意将此配置移至~/.pam_environment
,但这将需要一些脆弱的黑客攻击。我为我选择的显示管理器 (LightDM) 设置的操作系统提供的 (Debian) 配置user_readenv=0
,pam_env.so
因此我必须进行系统范围的配置更改,然后我必须担心在软件包更新后保持同步和正确。
当然,我可以向 Debian 软件包提交一个补丁来更改此默认值,但默认值很可能是有充分理由的,而且我怀疑我自己自私的用例是否足以说服他们除了这样的一个补丁。
另一种选择是从 更改ExecStart=foo -a -b
为ExecStart=sh -c 'exec foo -a -b'
。这有点令人讨厌,因为我过去遇到过 Systemd 失去进程跟踪的问题foo
,认为它已经成功退出,而实际上它已经以非零退出状态崩溃了。也许我“做错了”,可以再试一次。但这感觉比使用 PAM env 更加混乱,如果可能的话我宁愿避免它。