我目前正在重寫upstart要使用的工作systemd，我想知道：

**的“預設”位置在EnvironmentFile**哪裡？

它可能會進入/etc/environment

它可能與 中的所有其他服務文件一起存在/etc/systemd/service，/run/systemd/system或者/lib/systemd/system但我EnvironmentFile在這些位置中看不到任何其他 s 中的任何其他Service.

我也辯論過/etc/default/或/etc/<PACKAGE_NAME>

沒有記錄的“正常”位置可以放置它。我見過的許多範例似乎/tmp/<FILE_NAME>都沒有意義，因為在重新啟動時會被擦除，並且這些文件需要保留，以便在啟動或重新啟動/tmp時可以引用它們。Service

---

背景：我EnvironmentFile在安裝 debian 軟體包之前生成預安裝時間（使用維護者腳本），並且我知道每次啟動/重新啟動服務時該文件都必須可用。

systemd 的人不喜歡環境文件。

所以一個都沒有。

多年來，有幾個 systemd 人員記錄在案，稱環境文件是一種他們一開始就不應該提供給 systemd 的機制。

原生 systemd 機制畢竟是服務單元文件本身，其中環境變數是用Environment=鍵設置的。在他們看來，使用管理員定義的或特定於機器的變數來定制服務的環境是在單元的片段文件中放置的問題，這些單元使用更多的鍵.conf設置其他環境變數。Environment=

（但老實說，嘗試將內容動態轉換為適合EnvironmentFile=.*$$ … $$*也是/etc/sysconfig一個應該真正消失的紅帽主義，整個概念是有缺陷的。添加新的/run/sysconfig/肯定會使情況變得更糟。）我可能一開始就不應該添加EnvironmentFile=。打包者誤解了單元文件受管理員配置的約束並且應該被這樣對待，並且將單元文件的配置拆分為單獨的文件EnvironmentFiles=是一種非常荒謬的不必要的間接遊戲。

— Lennart Poettering (2015-12-09)。關於“EnvironmentFile”的查詢。系統開發。

使用EnvironmentFile=幾乎總是一個壞主意，我們可能永遠不應該添加它，因為它會邀請打包者重新引入我們試圖消除的瘋狂/etc/default/。/etc/sysconfig/

— Lennart Poettering (2015-07-22)。請考慮為整個單元文件設置變數。系統錯誤 #618。GitHub。

獎勵內容

在 daemontools 世界中，我們當然有環境目錄envdir，使用/s6-envdir命令讀取。儘管它不是 daemontools 的標准或要求，但可以使用的一種約定與某些工具一致，即環境目錄被命名並與程序和其他東西env一起存在於服務目錄中。run

引用自：https://unix.stackexchange.com/questions/418851