我最近在一個專門為託管一些虛擬機器而構建的新伺服器上安裝了 Ubuntu Utopic 14.04 LTS。此盒子的網路配置包含兩個 NIC，僅透過虛擬橋公開這兩個 NIC - 一個連接到專用網絡，一個連接到面向公眾的 Internet。一個來賓虛擬機器將透過分路器存取兩個網橋，充當主機（特別是主機）和一般專用網路的防火牆和網關。另一個虛擬機器只是專用網路上的一個單獨的訪客伺服器。主機只會透過對應的專用網橋直接參與專用網路。
因此，eth0 和 eth1 都只會在其對應虛擬橋的上下文之外「啟動」。然而，當 Ubuntu 啟動時，我相信 upstart 的故障保護錯誤地假設（堅持？）至少 eth0 獨立啟動，然後才允許系統透過故障保護施加的 20/40/60 秒延遲。然而，在啟動完成並且允許來賓虛擬機不受限制地啟動之前，延遲幾乎沒有解決的希望！看到悖論了嗎？老實說，我不確定 eth0 和 eth1 是否會曾經達到故障安全狀態要求很高。
在原始的、反動的層面上，我內心沮喪的、非 Ubuntu 的一面想要取消故障保護，因為每次重新啟動配置更改都會迫使我等待長達兩分鐘的狀態更改，我 99.9% 肯定會這樣做永遠不會發生按設計。底線—沒有故障安全依賴性。我只想製作額外的圈子，我意識到故障保護正在迫使它們消失。
出於同樣的原因，我試圖至少對 Upstart 試圖用故障保護做什麼持開放態度，因為這是我第一次接觸它。我已經看到一些（非常模糊的）訊息，其中一種方法涉及更改/etc/network/interfaces 的設定方式，將我的網橋設定移到它們自己的Upstart 任務中，但我真的更願意保留我的介面定義，快樂，工作。
那麼，我的選擇是什麼呢？我可以消除故障安全任務分配，或修改它以改變其條件嗎？如果是這樣，怎麼辦？我必須破解我的介面檔案嗎？
答案1
首先，讓我為回答我自己的問題道歉。
其次，事實上，我已經解決了failsafe.conf 啟動延遲問題。雖然我意識到這個問題上沒有大量的活動，但我在其他各種線程上看到了足夠多的關於類似故障安全/啟動延遲問題的活動，我正在發布我的研究和解決方案，以造福類似泡菜中的其他人。
概述
正如第一篇文章所指出的，我所看到的問題是故障安全新貴作業對我的系統啟動施加了不必要的限制。然後我進一步研究了這個問題，找出了為什麼故障保護會是這樣。
分析
預設情況下，failsafe.conf 定義了一個在啟動時有效觸發它的啟動條件（只要檔案系統和環回介面可用），並定義了兩個可能的停止條件之一：
start on filesystem and net-device-up IFACE=lo
stop on static-network-up or starting rc-sysinit
Failsafe 堅持延遲的原因是沒有觸發「停止」事件。第二個條件rc-sysinit是upstart運行的最終系統初始化任務之一，它有自己的啟動條件
start on (filesystem and static-network-up) or failsafe-boot
沒有故障保護停止，顯然 rc-sysinit 不是開始。一旦逾時到期，故障安全將發出故障安全啟動事件。鑑於故障安全已啟動，隱含“檔案系統”，因此兩個事件共同的唯一剩餘條件是“靜態網路啟動”。故障安全正在運行，因為它認為沒有任何網路介面處於「啟動」狀態。
原因
透過/etc/network/if-up.d 向後工作，定義了一個upstart 腳本，該腳本迭代使用「auto」限定符定義的/etc/network/interfaces 中定義的所有網路接口，這意味著要啟動該接口在啟動時。介面如何被視為「向上」的定義成為一個重要的語義問題，我將在稍後描述。
當且僅當所有「自動」配置的介面都「啟動」時，新貴腳本才會發出著名的「靜態網路啟動」事件。反過來，這將允許 rc-sysinit 觸發並終止故障保護 - 這就是我的問題的根本原因。我的網路介面在啟動時都沒有 IP 位址 - 按照設計。但「static-network-up」並不遵守介面「up」的概念沒有IP 位址，因此故障保護會掛起，直到逾時為止。
對於我的情況，我將盒子中的兩個實體網路卡從屬於橋接器，並透過分接頭將它們暴露給兩個不同的虛擬機器。一台虛擬機器透過一個分接頭提供 DHCP，另一台虛擬機器只是同一網路上的一台伺服器。為了使網橋能夠按照虛擬機器的分接正常運作，NIC 必須至少處於「UP」狀態，被動地允許封包通過。因此，「auto」在 /etc/network/interfaces 中似乎是合適的。它是不是然而，從故障安全的角度來看，這是適當的，因此唯一的解決方案必須是遵守故障安全語義的解決方案。
那麼，我的問題的解決方案有兩個：
- 從我定義的每個網路介面（環回除外）中刪除「自動」聲明。
- 建立新貴作業以「手動」調出先前的「自動」介面。
我透過模仿提供的解決方案，為四個設備（兩個分路器和兩個虛擬網橋）中的每一個定義了一項工作這裡。
在此配置中，由於沒有“自動”接口，網路腳本現在應立即發出“static-network-up”，從而強制故障安全終止。最後的修改要求我為每個 Tap 的介面定義新增一個「post-up」子句，以呼叫「brctl」並建立對應的虛擬橋，之前作為「auto」配置的一部分完成。
所以，我的 /etc/network/interfaces （部分）現在看起來像：
#auto tpRED (commented out)
iface tpRED inet manual
pre-up /usr/sbin/tunctl -t tpRED
post-up /sbin/brctl addbr brRED
#auto brRED
iface brRED inet manual
bridge_ports eth1 tpRED
bridge_hw xx:yy:aa:bb:cc:dd
酸性測試
酸測試？重新啟動伺服器。當我這麼做的時候，故障安全逾時消失了，而我的網路採用了功能相同的配置。有用！我只是希望我們能夠更好地處理“UP”網路介面的語義！