systemd.unit翻譯

SYSTEMD.UNIT(5)            systemd.unit                    SYSTEMD.UNIT(5)
名稱
Systemd.unit - 單元配置
概要
systemd.service, systemd.socket, systemd.device, systemd.mount,     systemd.automount,          systemd.swap, systemd.target, systemd.path,     systemd.timer,systemd.snapshot
描述
一個單元的配置文件編碼信息關於服務，套接字，設備，掛載點，交換文件或者分區，開始標籤，文件系統路徑或者時間控制和監控被systemd(1)。這個語法被XDG DesktopEntry Specification[1]授予。桌面文件，又受微軟Windows的.ini文件所授予。

這個man pages 顯示了所有單元類型的命令配置選項。這些配置選項您可以查看［Unit］或[Install] 章節關於單元文件。

除了能用的［Unit］和［Install］章節描述外，還可以參考其它章節，例如 ［Service］ 的服務單元。看respective man pages瞭解更多信息。

單元文件可能包含附加的選項在這些列表中。如果systemd 遇到一個未知的選項時，他將顯示一個警告信息，但是繼續加載這個單元。如果某個選項的前綴爲X－，那麼它將被systemd忽略.有些應用程序可能使用這些包含附加信息的單元文件。

布爾參數用在單元文件上可能會被寫成變量的格式。比如正確將設置成字符串1，yes，true或者on是一樣的。不正常將設置成字符串0，no，false 或者off 是一個的。
在單元文件中時間跨度值編碼可能被寫成變量格式。一個獨立的數字指定時間爲秒。如果後綴有時間單位,單位是你指定的。這個單元可以支持多個值進行關聯，在這種情況下這些值將進行累加。例如：“50”指的是50秒；“2min200ms” 指的是2分鐘加上200毫秒，i.e. 120200ms。下面的這些時間單位    你必須明白：s，min，h，d，w，ms，us。

空行和行首爲＃或者；是被忽略的，這是用來做註釋用的。行尾如果是反斜槓是與下面的行連起來一起讀或者反斜槓替換爲一個空格字符。這個用於比較長的行。

如果行首是.include後跟一個文件名，指定的文件將被解析在這一點上，確保文件包括有適當章節的頭部在執行任何指令之前。

連同一個單位文件foo.service 一個目錄 foo.service.wants/ 的存在。所有的單元鏈接從這樣一個目錄默認添加依賴項類型Wanted= 到這個單元。這是有用的單元等待其它的單元啓動，不用修改他們單元的配置文件。想了解更詳細關於Wanted=的語法如下。首先創建符號鏈接在.wants/目錄，然後使用
systemctl enable 命令開啓服務,在單元文件systemctl(1)工具從[Install]章節中讀取信息。（如下）有一個類似功能的存在 requires= 的信賴性很好，這個目錄的後綴是.requires/ 在這種情況下。

注意，雖然systemd將提供了一個靈活的依賴系統，各單元之間推薦使用這種功能只有稀疏的而不是靠技術,如總線或基於socket的活性化使依賴更含蓄，這兩個結果是更簡單、更靈活的系統。

一些單位名稱反映路徑中存在文件系統的名稱空間。例如一個設備單元    dev-sda.service 反映一個設備節點/dev/sda在這個文件系統名稱空間。如果這適用於一種特殊的方式來逃避使用路徑名，則這個結果只作爲文件名的一部分。基本上，給出一個路徑，“／”被“－”所代替，所有的不可輸出的字符和“－”    是被C－style “\x20”反替代。根目錄“／“的代碼是一個破折號，然爾初始化和結束“／”將被移除從所有路徑轉換的過程中。 這個轉義是可逆的。

另外，單位可以被實例化當對模板文件進行排序時。這允許創建多個單元從一個配置文件。如果systemd 尋找一個單元配置文件，它將首先搜索文字單元名在這個文件系統中。如果結果沒成功或者這個單元獲得一個＠符，systemd 將查詢單元臨時共享的同名文件，但是這個實例串（i.e. ＠字符和    後綴兩都的一部分）被移除。例如：如果一個服務[email protected]被請求並且沒有沒有文件被找到，systemd將查找[email protected]和實例化一個服務從配置文件中。

指定實例串在這個配置文件中，你可以使用特殊的%i說明符在很多配置選項中。其它的說明符如下：
表1. 在單元文件中可用的說明符
說明符
含義
詳細
%u
完整的單元名
%N
非轉義的單元名
％p
前綴名
指定的串在＠之前，i.e.”getty” 在example 上，“tty3”是實例名
％P
非轉義前綴名
％i
實例名
在這個＠符和後綴之間的字符串
％I
非轉義例名
％f
非轉義文件名
如果這個非轉義的實例名（如果設置）的前綴帶(如果需要) /，或者這個前綴名與 / 目錄相似。
%c
控制單元組的路徑
％r
root控制systemd的組路徑
%R
root控制systemd的組路徑的父目錄
％t
運行時套接字目錄
要麼/run（系統管理）要麼$XDG_RUNTIME_DIR(用戶管理)
％u
用戶名
這是配置的名稱的用戶單位，或(如果沒有設置)用戶運行systemd實例
%h
用戶家目錄
這是配置用戶單元的家目錄，或(如果沒有設置)用戶運行systemd實例
%s
用戶shell
這是配置用戶單元的shell，或(如果沒有設置)用戶運行systemd實例
%m
機器ID
運行系統的機器ID，格式爲字符串，看machine-id(5)瞭解更多信息
%b
引導ID
運行系統的引導ID，格式爲字符串，看random(4)瞭解更多信息
H
主機名
運行系統的主機名
如果一個單元文件爲空（i.e. 文件大小是0）或被指向到/dev/null，那麼他的配置將不被加載或出現一種被加載的假狀，並且不能被激活。使用一個有效的方法去完整的禁用一個單元，使它不可以手動啓動。
這個單元文件的格式被Interface Stability Promise[2]覆蓋。

OPTIONS
單元文件包括一個（Unit）章節，同時提供關於單元信息，但不信賴於單元類型。
Description=
一個用來自由描述單元的字符串。這是用於UIs顯示單位名稱的描述性信息
Documentation＝
空格分隔的列表引用文檔的uri爲本單位或其配置。接受只有uri的類型 httpd://，https://，file:，info:。想了解更多關於uri的語法看uri(7)
Requires=
配置需求依賴於其他單位。如果這個單元被激活，這裏列出的單位也會被激活。如果其中一個其他單位被停用或其激活失敗,本單元將被停用.這個選項可以指定超過一次，在這種情況下,要求對所有被創建列出的名    稱都有依賴。注意,需求依賴關係不影響服務的順序啓動或停止。這必須被配置獨立於After=或Before=選項。如果一個單元foo.service請求一個單元bar.service 將被配置Requires=，但沒有事先配置After=或Before=，如果服務被激活，兩個單元將同時被啓動並在啓動時沒有任何延遲。通    常它是一個更好的選擇，用Wants=代替Requires=是爲了實現一個系統更健壯的處理失敗的服務
注意,這種類型的依賴關係也可以被配置在配置文件以外的單位，添加一個軟鏈接到.requires/ 目錄來連接這個單元文件。更詳細的看上面。
RequiresOverridable=
和Requires=類似。信賴項列在RequiresOverridable=不能滿足或者啓動失敗是被忽略的，這個明顯是被用戶請求的。如果一開始是由一些信賴了間接或自動啓動的單位，不是用戶所請求的這種信賴性被滿足，否則事務失敗。因此，這個選項可以用來配置信賴關係，通常是榮幸的，除非有明確啓動單元，在這種情況下他們是否失敗是無關緊要的。
Requisite=, RequisiteOverridable=
Requisite=和RequisiteOverridable=類似，分別的。然而，如果一個單位列在這裏是沒有開始，他將不會被啓動或者這個事務立即失敗。
Wants=
       一個版本比較低的Requires=，如果是配置單元，那麼這個單元列出的選項將開始。然而如果列出單元是啓動失敗或者不能被添加到事務中，這沒有影響事務的有效性和完整性，這是推薦的啓動方式，當一個單位啓動到其它單元上時。
注意,這種類型的依賴關係也可以被配置在配置文件以外的單位，添加一個軟鏈接到.wants/ 目錄來連接這個單元文件。更詳細的看上面。
BindsTo=
配置需求依賴關係，和Requires=的風格非常相似，然而除了這個行爲它還聲明這個單位是停止的當其它單位突然消失的時候，單元可能突然的，出人意料的消失如果一個服務的終止是它自己的選擇，一個設備是不插電或者卸載掛載點沒有在systemd中包含。
PartOf=
配置信賴類似於Requires=，但限於停止和重新啓動的單位，當systemd停止或重啓時，這個動作將被傳播到這個單位。注意這是一個信賴的方法－發到這個單位不影響其它的單位。
Conflicts=
配置非需求信賴關係。如果一個單元有一個Conflicts=設置在另一個單位上，啓動前將停止後者,反之亦然。注意，這個設置是獨立的和正交的在After=和Before=的先後信賴關係上。
如果一個單元和另一個單元B相沖突，那麼B也同時啓動。事務要麼失    敗（如果兩者都需要事務的一部分）或被修改是固定的（如果一個或兩個工作不是一個必需的事務的一部分）。在後一種情況下的工作不是必須的將被刪除，或者兩者都不需要單位，這個衝突將要開始或者這個單元的衝突將被終止。
Before=, After=
配置單元之前的信賴關係。如果一個單元foo.service 設置了Before=bar.service，那麼我兩個單元將被開啓，bar.service 的開啓將延遲直到foo.service開啓。注意，這個設置是獨立的和正交的信賴關係當配置了Requires=。這是一個常見的模式包括單位名稱After=和Requires=這兩個選項，在這種情況下，單位列出的這些配置選項將在此之前開始。這個選項可以指定超過一次，在這種情況下，所有列出的名稱都將按照信賴順序被創建。After和Before=是相反的，例如，當After=確保配置    單元是開啓後這個列出來的單元完成啓動，Before=正好與之相反，例如配置單元完全啓動前這個列出的單元將被啓動。當兩個單位之間產生依賴關係時，它們都將關閉，反過來這個啓動順序將被應用。例如，如果一個單元配置了After=在其它單元上，那麼前者是停止在後者之前如果兩者都是關閉的。如果一個帶依賴順序的單元在其它的單元關閉後啓動，那麼這個關閉的順序是否在啓動之前，是否有信賴性實際取決於類型    After=或者Before=。如果兩個單元之前沒有依賴順序，那麼他將同時關閉或者啓動，無順序將要發生。
OnFailure=
列出一個或者多個被激活的單元當這個單元處於‘failed’狀態。
PropagatesReloadTo=, ReloadPropagatedFrom=
列出一個或者多個單位，重新加載請求的單位將被傳播到其它的單位或者從其它單位進行傳播。發佈一個重新加載的請求在一個單元，它將自動刷新重載請求在所有單位，重新加載請求將通過這兩信設置進行傳播。
RequiresMountsFor=
以空格分隔列表的絕對路徑。自動添加信賴項的類型Requires=和After=，對於所有掛載單位需要訪問指定的路徑。
OnFailureIsolate=
需要一個布爾參數。如果爲true，列在OnFailure=的單元將被加入隊列並且隔離模式，例如。所有單位中不是他的信賴將被停止。如果只是設置一個單一的單位，可以被列入OnFailure=中。默認爲false
IgnoreOnIsolate=
需要一個布爾參數。如果爲true,那麼這個單位將不會被停止當隔離其它單位時，默認爲false
IgnoreOnSnapshot=
需要一個布爾參數。如果爲true，那麼這個單位將不包含在快照中。默認值爲true爲設備和快照單位，false爲其它單位。
StopWhenUnneeded=
需要一個布爾參數。如果爲true，這個單元將被停止當他不再使用時。注意，爲了最小化執行工作，systemd將不會停止，除非它們默認的單位與其它單位發生衝突，或者用戶主動地請求他們關閉。如果設置了這個選項，一個單元將自動清理如果沒有其他活動單位需要它，默認爲false。
RefuseManualStart=, RefuseManualStop=
需要一個布爾參數。如果爲true，這個單位只能間接激活或者不激活。在這種情況下直接啓動或者終止用的請求都將被拒絕，但是如果開啓或者停止是信賴於其它單位，開啓或者終止都將成功。這主要是有一個安全特性來保證用戶並不意外激活單元，並不打算明確的被明確的激活，不是不小心停用單位，不是爲了被停用。這個選項默認爲false。
AllowIsolate=
需要一個布爾參數。如果值爲true,這個單位可能使用systemctl isolate 命令。相反將被拒絕。它可能是一個好的方法，除了目標單位以外的都將被禁用，應使用類似於init系統的運行級別來運行SysV，只是作爲一項預防措施來避免無法使用系統的狀況。這個選項默認爲false。
DefaultDependencies=
需要一個布爾參數。如果值爲true（默認）,一些默認的依賴性將隱式的創建爲單位。實際上創建依賴關係取決於單位類型。例如服務單位，這些依賴關係要確保該服務已經開始，只有在基本系統初始化完成和正確    地終止系統關機。看各自的man page頁瞭解詳情。通常只有服務參與早期的引導或者晚關機應該設置這個選項爲false。強烈建議啓用這個選項對於大多數常見的單位。如果設置爲false，這個選項沒有禁用所有隱式的信賴項，只是非必要的。
JobTimeoutSec=
當客戶正在等待一個工作被這個單位完成時，時間在指定的時間後。如果這個時間限制到達後，那麼這個作業將被取消，這個單位將不會改變狀態或者進入“failed”模式。這個值默認爲0（任務超時被禁用），除了設備單位。注：這個超時是獨立於任何單位－具體工作的超時（例如，超時設置Timeout=爲服務單位）不會影響到單位本身，只有在工作上纔有    可能等待它。換句話說：指定單位超時對取消單位狀態改變是有用的，並且恢復它們。工作超時設定這個選項是有用的，但是隻有中止這個工    作單位狀態的改變。
ConditionPathExists=,ConditionPathExistsGlob=,ConditionPathIsDirectory=,     ConditionPathIsSymbolicLink=,ConditionPathIsMountPoint=,
ConditionPathIsReadWrite=,     ConditionDirectoryNotEmpty=,     ConditionFileNotEmpty=, ConditionFileIsExecutable=,         ConditionKernelCommandLine=,ConditionVirtualization=,ConditionSecurity=,     ConditionCapability=, ConditionHost=, ConditionNull=
在開始前一個單元驗證指定的條件爲true。如果它是不正確的啓動單元    將被忽略，然而所有的信賴順序仍然不受任何影響。一個失敗的情況不會導致單位被移動到一個失敗狀態。這個條件檢查當時隊列中將要開始被執行的任務。
ConditionPathExists= 一個文件存在的條件是在檢查一個單元啓動之前。如果指定的絕對路徑名不存在，那這個條件將失敗。如果這個絕對路徑名傳遞給ConditionPathExists=的前綴是一個感嘆號（‘！’），測試是否定的，只有這個路徑不存在這個單元纔開始。
ConditionPathExistsGlob=和ConditionPathExists=類似，但會檢查是否存在至少一個文件或目錄能夠匹配指定的通配模式。
ConditionPathIsDirectory=和ConditionPathExists=類似，但會驗證特定的路徑是否存在和是否是目錄。
ConditionPathIsSymbolicLink和ConditionPathExists=類似，但會驗證特定的路徑是否存在和是否是軟鏈接。
ConditionPathIsMountPoint=和ConditionPathExists=類似，但會驗證特定的路徑是否存在和是否是掛載點。
ConditionPathIsReadWrite=和ConditionPathExists= 類似，但會驗證底層的文件系統是否可讀可寫（例如不爲只讀）。
ConditionDirectoryNotEmpty=和ConditionPathExists=類似，但會驗證特定的路徑是否存在和是否是非空目錄。
ConditionFileNotEmpty= 和ConditionPathExists=類似，但會驗證特定的路徑是否存在和指定一個非零大小的常規文件
ConditionFileIsExecutable=和 ConditionPathExists= 類似，但會驗證特定的路徑是否存在和是否是一個可執行的常規文件。
類似的，ConditionKernelCommandLine=可以用來檢查是否一個特定的內核命令行選項被設置（或者說前綴感嘆號沒有設置）。這個參數必須是一個單詞，或是一個任務（例如兩個單詞，隔離’=’）。在前一種情況下內    核命令行是尋找這個詞的出現或者是左手邊的一項任務。在後一種情況下精確的尋找右手邊或是左手邊匹配的任務。
ConditionVirtualization=可用於檢查系統是否可以在虛擬環境中執行和有選擇性的測試它是否可以實現。需要使用布爾值來檢查是否可以在任何虛擬化環境中執行，或使用一個vm和container 來測試一個通用型的虛    擬化解決方案，或者選擇qemu，kvm，vmware，microsoft，oracle，xen，    bochs，chroot，openvz，lxc，lxc-libvirt，systemd-nspawn其中之一來有針對性的測試。如果多個虛擬化技術只考慮最內層嵌套。那麼這個測試可能被追加一個感嘆號。
ConditionSecurity=可以用來檢查系統上的安全模塊是否啓用。目前唯一公認的是selinux。這個測試可能被追加一個感嘆號。
ConditionCapability=可以用來檢查是否存在特定的能力在服務管理的性能邊界設置上（這並不檢查是否有能力，實際上是允許和有效的集合是否可用，看capabilities(7) 瞭解詳情）。通過能力的名字如CAP_MKNOD，可以用一個感嘆號來否定檢查。
ConditionHost=可以用主機名或機器ID來匹配主機。這不是需要一個主機名的字符串，而是用來測試設置主機名的返回值gethostname(2)，或機器ID的格式爲字符串（看 machine-id(5)）。這個測試可能被追加一個感嘆號。
最後，ConditionNull=可以添加一個常數條件檢查值到這個單位。它需要一個布爾參數。如果設置爲false這個條件將總是失敗，相反則成功。
如果多個條件被指定，那麼所有的應用單元都將被執行（例如。一個合    乎邏輯的應用）。條件檢查可以加上前綴管道符號（｜），在這種情況下一個條件成爲一個觸發條件。如果至少有一個觸發條件是定義單元然後    單位將被執行，如果至少一個觸發條件應用和所有的非觸發條件。如果你的前綴的參數是管道符和感嘆號，那麼管道符第一，感嘆號第二。除了 ConditionPathIsSymbolicLink=，所有路徑的檢查都允許軟鏈接。
SourcePath=
一個用來存放單元配置文件的一個路徑。這主要是用於實現生成程序的工具，將外部配置文件的格式轉換爲本地單元文件。因此這個功能不應該用在正常的單位上。
單元文件可能包含一［Install］章節，包含這個單元的安裝信息。當systemd(1)    正在運行時，這個章節將不被解釋。它專門用於systemctl（1）工具在安裝    單元期間使用enable和disable命令：
Alias=
這個單位在安裝時的其它名字。這裏列出的名稱必須具有相同後綴（類型）作爲單位的文件名稱。這個選項可以指定多次，在這種情況下，所有列出的名稱都可用。在安裝時，systemctl enable將創建軟鏈接用這些名稱作爲單元文件名。
WantedBy=, RequiredBy=
分別的爲一個單元安裝一個符號鏈接在.wants/或.requires/的子目錄上，這個效果是當列出的單元名稱是被激活，那麼這單元列出也將被激活。WantedBy=foo.service一個服務bar.service 幾乎等於    Alias=foo.service.wants/bar.service在相同文件中。
Also=
當這個單元被安裝後附加的單元。如果用戶要求在安裝時配置這個選項，systemctl enable 將自動的安裝單元並且列出這個選項。
SEE  ALSO
systemd(1), systemctl(8), systemd.special(7), systemd.service(5),     systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5),
systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5),     systemd.snapshot(5), capabilities(7)
注意
1. XDG 桌面入口規範          
   http://standards.freedesktop.org/desktop-entry-spec/latest/

2. 接口穩定性承諾
    http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise

systemd                                                       SYSTEMD.UNIT(5)