Debugging
在 dmesg 中理解時間
我知道時間
dmesg是自啟動以來的時間。但是我的具體問題是這個時間是在該行中提到的過程的開始還是結束時計算的？為什麼這很重要？
舉個例子：
[ 4.352025] floppy0: no floppy controllers found [ 5.718270] random: nonblocking pool is initialized [ 94.134265] Adding 2094076k swap on /dev/sda5. Priority:-1 extents:1 across:2094076k FS** [ 96.988453] init: bootchart main process (274) terminated with status 127如果時間，是在完成程序後計算的，第 3 行的程序應該負責慢啟動。
但如果時間是從流程開始計算的，則應由第 2 行負責。
dmesg但是當我們在啟動後很長時間檢查時會變得更加複雜。以此為例：
[28047.749604] wlp3s0: associated [28941.112855] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=757985 end=757986) [31407.938694] cfg80211: World regulatory domain updated: [31407.938699] cfg80211: DFS Master region: unset這個2466s的差距應該沒有任何有用的意義。
我看到很多次對於哪條線路
dmesg應該對慢速啟動負責。我們如何在 dmesg 中理解時間？
每個日誌條目顯示列印日誌條目的時間。不多也不少。如果日誌條目描述的過程不是即時的，則沒有規定日誌條目必須在該過程執行之前或之後出現，這取決於開發人員選擇做什麼。語法是一條線索：“did this”表示動作已完成，“will do this”表示尚未完成；但是“這樣做”是模棱兩可的。
正如cmks 所解釋的那樣，
dmesg它只顯示核心日誌，它並沒有描繪出一旦 initramfs 或 init 程序啟動後系統上發生的情況的有用畫面。您顯示的所有行都沒有描述花費超過幾分之一秒的事件，因此它們都不是導致啟動時間長的原因。這是其他事情，核心中沒有發生。
dmesg 不是分析或調查引導過程性能的合適方法。您應該使用
bootchart或者在較年輕的發行版中已經在 systemd 集成版本的 bootchart 中systemd-analyse。因為這些是複雜的過程，我不會將教程複製到這個答案。