LSBInitScripts
以下是譯文。
怎樣LSB化 Init Script
一個可用的狀態頁，講解了引導序列的依賴關係。
這是一篇簡短文檔，介紹了怎樣使 Init Scripe 符合LSB(Linux Standard Base，Linux標準規範)—遵從Chapter 20 of the LSB 3.1的規範。
LSB系的 init scripts 需要
- 至少提供以下操作：start, stop, restart, force-reload, 和 status。所有這些，除了status，都需要按Debian Policy, chapter 9.3.2要求的編寫腳本。”Status”的支持已經要求轉化爲政策，見＃291148和LSBInitScripts / StatusSupport。
- 返回正確的退出狀態碼。
- 標明運行時依賴關係。
- [可選的]使用的init.d的函數：log_success_msg，log_failure_msg和log_warning_msg來記錄日誌消息（這會使輸出腳本一致，就像http://lists.debian.org/debian-devel/2005/06/msg00729.html中要求的，
同時也應該遵循 Debian Policy, chapter 9.4 Console messages from init.d scripts）
LSB腳本必須實現的操作(包括返回碼)的全部信息的在LSB 3.1, Chapter 20.2. Init Script Actions可見。維護人員應審查該節和審查/相應調整對應的init.d腳本。
運行時依賴
添加運行時的依賴性對於Lenny是一個發佈目標(release goal?)，基於引導順序的依賴性是默認的在Squeeze中。有一個單獨的wiki頁面記錄這一成就。
通過爲init.d腳本添加運行時依賴關係，使得驗證當前的引導順序，使用這些依賴關係啓動，並行運行啓動腳本，以加快引導過程這件事情變得可能。
在init.d腳本中添加的塊可能像這樣的：
### BEGIN INIT INFO
# Provides: scriptname
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO上面顯示該塊有一個特殊的剛性格式，由這兩行線劃定
### BEGIN INIT INFO
### END INIT INFO
其中所有尾隨空格將被忽略。另一方面，在塊內的所有行應是這樣的形式：
＃ {keyword}: arg1 [arg2...]
以第一列中的散列字符’#’爲開始,再接着是一個單獨的空格，除了接下來的描述關鍵字的行以外。定義了以下關鍵字：
Provides: boot_facility_1 [boot_facility_2…]
以下是谷歌翻譯結果，還未人工修正。
定義此初始化腳本，這樣提供的引導設施時運行該腳本用start參數時， 指定的引導設施將被視爲需要這些引導設施存在，因此其他初始化腳本 必須在以後階段啓動。通常情況下，你應該使用腳本的名稱作爲啓動設備（不.SH如果文件名中有這樣的結局），但是可以在特殊情況下也可以使用的名稱 服務（S），該腳本代替。由腳本提供的引導設施，不能以“$”。（下面列出的虛擬設備名稱中的init.d腳本之外定義。）設備名稱應該是唯一的分佈範圍內，以避免在安裝包時，“重複提供”錯誤。
所需的啓動：boot_facility_1 [boot_facility_2 …]
定義的設施必須可用來啓動腳本。如考慮使用虛擬設備名稱下面，如果足夠。如果沒有指定啓動工廠則意味着該腳本可以引導後，剛開始沒有本地文件系統安裝，也沒有系統日誌程序等等。
所需-停止：boot_facility_1 [boot_facility_2 …]
定義了用於通過由腳本提供的服務設施。該腳本提供的設施應停止列出的設施都被停止，以避免衝突之前。通常你會在這裏有相同的設施作爲必選啓動關鍵字。
應該啓動：boot_facility_1 [boot_facility_2 …]
定義如果存在的話應該由腳本提供的服務前，啓動設備。儘管如此，該腳本仍然可以啓動，如果所列設施缺失。這使得弱相關性不導致服務失敗，如果一個功能不可用。考慮如下所述，如果充分利用虛擬設備的名稱。
應該-停止：boot_facility_1 [boot_facility_2 …]
定義如果存在應此服務後停止服務。通常你會在這裏有相同的設施，那些具有如若啓動關鍵字使用。
默認啓動：run_level_1 [run_level_2 …]
默認-停止：run_level_1 [run_level_2 …]
定義運行級別，其中的腳本應啓動（停止）默認情況下。例如，如果一個服務應該在運行級別3，4運行和5只，指定“默認啓動：3 4 5”和“默認停止：0 1 2 6”。
短說明：SHORT_DESCRIPTION
提供初始化腳本的動作的簡要說明。不限於文字單行。
說明：multiline_description
提供初始化腳本的操作的更完整的說明。可以跨多行。在多行的描述，每個續行必須以’＃’後面製表符或’＃’後面至少有兩個空格字符。多行描述由不匹配此條件的第一行終止。
的X啓動前：boot_facility_1 [boot_facility_2 …]
的X停止-後：boot_facility_1 [boot_facility_2 …]
提供反向相關性，這看起來好像列出的設施必須要啓動，並在包裝上使用這些標題應該停。
的X互動：真
表明，該啓動腳本可以與用戶進行交互，請求一些輸入（例如，一個口令）。這確保單獨運行腳本時引導系統啓動的parallell腳本和直接訪問該終端。
對於依賴性跟蹤的提供，須─和前肩關鍵字是重要的，其餘的是未使用的。默認運行級別所使用的程序命令初始化腳本（如insserv）來跟蹤時，一個服務被添加在第一時間更新它的rc＃.d的目錄下，並應反映服務的意圖。
有一些“虛擬”的設施名稱，在上市 [LSB 3.1]。這些都是：
守護程序可以提供主機名解析（如果存在的話）正在運行。例如，守護程序查詢DNS，NIS +，或LDAP。
所有的文件系統掛載。在一些LSB運行時環境，文件系統，如/ usr可能是遠程的。如果腳本需要一個裝在/ usr /，它需要依賴於
系統時間已定，例如通過使用一個基於網絡的時間程序作爲NTP或RDATE，或經由硬件實時時鐘這樣。注意，只是根據NTP不會導致一個精確的時間的NTP剛開始之後。它通常需要幾分鐘，直到NTP實際調整時間。還要注意的是標準insserv.conf只是列出hwclock的爲
通過支持設施insserv畢竟腳本不依賴於
其他（非系統）的設施可以由其他應用程序來定義。這些設施應採用相同的命名來命名啓動 腳本中定義的約定。見提議Debian的特定的虛擬設備列表以獲取更多的信息。
本節大多最初基於從消息由皮特Reinholdtsen上的Debian-devel軟件包。
BTS報告與LSB的頭被usertagged。
常見問題
是否有可能啓動一個給定的初始化腳本儘可能晚？
是的，如果你真的想這樣做，insserv認識使得腳本將在年底執行的$所有虛擬設備的名稱。
是否可以添加額外的關鍵字？
如果沒有當前的關鍵字，你可以用你的需求，LSB允許使用前綴X-本地擴展。例如，X-Debian的foobardecl或X-Ubuntu的fastdecl。
是否可以指定給定的腳本應的另一個腳本之前啓動？
不存在這樣的標準定義的報頭，但在實施了提議的延伸insserv（自1.09.0-8版本）封裝。使用X-啓動前和X-停止-後提出的標題？的SuSE。
我不應該等到Debian政策的變化？
Debian的政策變化是緩慢的，即使引進的東西（的例子，見＃291148），其中大部分維護者同意是好的，因爲我們必須首先要等待許多軟件包，以將其納入政策之前做的事情以同樣的方式。因爲我們想成爲LSB標準，init.d腳本均可以調節，現在是LSB兼容的。
什麼是“適當的”退出狀態碼？
縱觀＃208010，這似乎頗具爭議。非零退出代碼，甚至可能導致破裂，而LSB在這裏Debian政策衝突。
CategoryBootProcess