如何確定 RHEL 伺服器中是否正在使用 haldaemon 或 udev？
如果 hal 真的在使用還是只是 udev，我很困惑。
我的理解：
- 一般來說，HAL 是一個抽象層，它允許作業系統與硬體設備進行互動。
- daemon hald 與 HAL 不同。它是一種提供 HAL 的服務，用於辨識設備，然後安裝它們（以及它們將在哪裡，在 /dev 下？）或自動配置它們以供應用程序使用。
- 它現在被 udev 棄用，它也做了類似的事情，即通過讀取來自核心的消息並根據預定義的規則命名來自動掛載連接的設備。
- 目前只有少數基於 GUI 的應用程序，如 GNOMe 使用暫停，以獲取有關新連接設備的通知（而安裝仍然由 udev 負責？）
所以我的問題是，如果 hal 僅用於通知基於 GUI 的應用程序有關新連接的硬體，因為它可以通過 DBUS 進行通信，但 udev 沒有 dbus 實現。而對於自動掛載設備，只有 udev 這樣做，而沒有使用 hal？
我特別在談論 Redhat 5,6 和 7。
謝謝。
一些背景：
udev已經存在了很長時間（從 2.5 核心開始）和（對於 RHEL）它是在驅動程序宣布硬體時設置設備節點的東西。即使在使用 HAL 的系統上，仍然存在udev。udev當它“發現”變化時，它本身可以呼叫其他程序，而 HAL 試圖抽像出桌面 *nix 系統（不僅是 Linux，還有其他像 FreeBSD 等）的某些新硬體的公告和配置。最終，人們取消了某些 HAL 部分，但並非所有 HAL 部分都可以移動到udev其中——其中一些分裂為其他守護程序。到 2012 年左右，大多數最前沿的 Linux 發行版都放棄了 HAL，而現在（2019 年初）上述守護程序是這樣的udisks，upower等等。在https://en.wikipedia.org/wiki/HAL_(software)上有一個很好的總結……因此，鑑於 RHEL 鬆散地基於 Fedora（可以在https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Relationship_with_Fedora上看到粗略的映射），並且我們知道Fedora 16 是無 HAL 的：
- RHEL 5 肯定會有
hald- RHEL 6 可能會有
hald- RHEL 7 沒有
hald，其他守護程序將接管udev無法說服的事情。怎麼找
$$ $$如果在 RHEL 伺服器中使用 haldaemon 或 udev？
只需啟動適當版本的 RHEL 並執行以下操作：
rpm -qa "*hal*"（哦，不，我剛剛意識到您在一個中隱藏了多個問題：-（）
daemon hald 與 HAL 不同。它是一種提供 HAL 的服務，用於辨識設備，然後安裝它們（以及它們將在哪裡，在 /dev 下？）或自動配置它們以供應用程序使用。
設備在
/dev但我是否需要“掛載”設備取決於上下文。我可能會安裝一個磁碟（例如，在下面，/mnt但還有其他地方也安裝了東西）但我不安裝掃描器（宣布/查找掃描器是 HAL 處理的事情）。它現在被 udev 棄用，它也做了類似的事情，即通過讀取來自核心的消息並根據預定義的規則命名來自動掛載連接的設備。
有時它僅由 完成
udev，有時其他服務也參與其中。/dev設備命名udev受控，是的。目前只有少數基於 GUI 的應用程序，如 GNOM
$$ E $$使用 hald，獲取有關新連接設備的通知（而安裝仍然由 udev 負責？）
好吧，現代系統沒有，
hald所以您的問題既奇怪又復雜。此外，即使在這樣做的系統上，答案也是“視情況而定”。是udev的，可以進行安裝，但有時諸如通過 PTP 協議連接 USB 攝像頭之類的事情幾乎由 GNOME 使用者空間處理（儘管我猜你可以爭論整個 FUSE 角度）。所以我的問題是 hal 是否僅用於通知
$$ sic $$關於新連接硬體的基於 GUI 的應用程序，因為它可以通過 DBUS 進行通信，但 udev 沒有 dbus 實現。
這是一個問題嗎？HAL 用於通知 GUI 應用程序，但它也可以在設備更改時觸發其他事情（例如調整電源規則/安裝磁碟）。
而對於自動掛載設備，只有 udev 這樣做，而沒有使用 hal？
再次是共同努力。是的，
udev規則要做很多，但根據上下文可能會涉及其他事情（例如，如果您需要開始提示使用者），這就是udisks開始涉及的事情。我想這裡有一個潛台詞：你為什麼要問是否使用了 HAL？你最好直接問這個問題……
（這些多部分的問題很痛苦:-()