當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

LXD 2.0 系列（十二）：调试，及给 LXD 做贡献

發布時間：2025/3/8 编程问答 28 豆豆

生活随笔收集整理的這篇文章主要介紹了 LXD 2.0 系列（十二）：调试，及给 LXD 做贡献小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

介紹

終于要結束了！這個大約一年前開始的這系列文章的最后一篇博文。

LXD 入門

安裝與配置

你的第一個 LXD 容器

資源控制

鏡像管理

遠程主機及容器遷移

LXD 中的 Docker

LXD 中的 LXD

實時遷移

LXD 和 Juju

LXD 和 OpenStack

調試，及給 LXD 做貢獻

如果你從一開始就關注了這個系列，你應該已經使用了 LXD 相當長的時間了，并且非常熟悉它的日常操作和功能。

但如果出現問題怎么辦？你可以做什么來自己跟蹤問題？如果你不能，你應該記錄什么信息，以便上游可以跟蹤問題？

如果你想自己解決問題或通過實現你需要的功能來幫助改善LXD怎么辦？如何構建，測試和貢獻 LXD 代碼庫？

調試 LXD 并填寫 bug 報告

LXD 日志文件

/var/log/lxd/lxd.log：

這是 LXD 日志的主文件。為了避免它快速充滿你的磁盤，默認只會記錄?INFO、WARNING?或者?ERROR?級別的日志。你可以在 LXD 守護進程中使用?–debug?改變其行為。

/var/log/lxd/CONTAINER/lxc.conf：

每當你啟動容器時，此文件將更新為傳遞給 LXC 的配置。

這里會展示容器將如何配置，包括其所有的設備、綁定掛載等等。

/var/log/lxd/CONTAINER/forkexec.log：

這個文件包含 LXC 命令執行失敗時產生的錯誤。這個情況是非常罕見的，因為 LXD 通常會在發生之前處理大多數錯誤。

/var/log/lxd/CONTAINER/forkstart.log：

這個文件包含 LXC 在啟動容器時的錯誤信息。含 LXC 命令執行失敗時產生的錯誤。

CRIU 日志 (對于實時遷移)

如果使用 CRIU 進行容器實時遷移或實時快照，則每次生成 CRIU 轉儲或恢復轉儲時都會記錄額外的日志文件。

這些日志也可以在?/var/log/lxd/CONTAINER/?中找到，并且有時間戳，以便你可以找到與你最近的操作所匹配的那些日志。它們包含 CRIU 轉儲和恢復的所有內容的詳細記錄，并且比典型的遷移/快照錯誤消息更容器理解。

LXD 調試消息

如上所述，你可以使用?-debug?選項將守護進程切換為執行調試日志記錄。另一種方法是連接到守護進程的事件接口，它將顯示所有日志條目，而不管配置的日志級別（即使是遠程工作）。

舉例說，對于?lxc init ubuntu:16.04?xen?來說，

lxd.log?會是這樣：

INFO[02-24|18:14:09] Starting container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000

INFO[02-24|18:14:10] Started container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000

而?lxc monitor –type=logging?會是：

metadata:

context: {}

level: dbug

message: 'New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00a'

timestamp: 2017-02-24T18:14:01.025989062-05:00

type: logging

metadata:

context:

ip: '@'

method: GET

url: /1.0

level: dbug

message: handling

timestamp: 2017-02-24T18:14:09.341283344-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: StorageCoreInit

timestamp: 2017-02-24T18:14:09.341536477-05:00

type: logging

metadata:

context:

ip: '@'

method: GET

url: /1.0/containers/xen

level: dbug

message: handling

timestamp: 2017-02-24T18:14:09.347709394-05:00

type: logging

metadata:

context:

ip: '@'

method: PUT

url: /1.0/containers/xen/state

level: dbug

message: handling

timestamp: 2017-02-24T18:14:09.357046302-05:00

type: logging

metadata:

context: {}

level: dbug

message: 'New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'

timestamp: 2017-02-24T18:14:09.358387853-05:00

type: logging

metadata:

context: {}

level: dbug

message: 'Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'

timestamp: 2017-02-24T18:14:09.358578599-05:00

type: logging

metadata:

context:

ip: '@'

method: GET

url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait

level: dbug

message: handling

timestamp: 2017-02-24T18:14:09.366213106-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: StoragePoolInit

timestamp: 2017-02-24T18:14:09.369636451-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: StoragePoolCheck

timestamp: 2017-02-24T18:14:09.369771164-05:00

type: logging

metadata:

context:

container: xen

driver: storage/zfs

level: dbug

message: ContainerMount

timestamp: 2017-02-24T18:14:09.424696767-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: ContainerUmount

timestamp: 2017-02-24T18:14:09.432723719-05:00

type: logging

metadata:

context:

container: xen

driver: storage/zfs

level: dbug

message: ContainerMount

timestamp: 2017-02-24T18:14:09.721067917-05:00

type: logging

metadata:

context:

action: start

created: 2017-02-24 23:11:45 +0000 UTC

ephemeral: "false"

stateful: "false"

used: 1970-01-01 00:00:00 +0000 UTC

level: info

message: Starting container

timestamp: 2017-02-24T18:14:09.749808518-05:00

type: logging

metadata:

context:

ip: '@'

method: GET

url: /1.0

level: dbug

message: handling

timestamp: 2017-02-24T18:14:09.792551375-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: StorageCoreInit

timestamp: 2017-02-24T18:14:09.792961032-05:00

type: logging

metadata:

context:

ip: '@'

method: GET

url: /internal/containers/23/onstart

level: dbug

message: handling

timestamp: 2017-02-24T18:14:09.800803501-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: StoragePoolInit

timestamp: 2017-02-24T18:14:09.803190248-05:00

type: logging

metadata:

context:

driver: storage/zfs

level: dbug

message: StoragePoolCheck

timestamp: 2017-02-24T18:14:09.803251188-05:00

type: logging

metadata:

context:

container: xen

driver: storage/zfs

level: dbug

message: ContainerMount

timestamp: 2017-02-24T18:14:09.803306055-05:00

type: logging

metadata:

context: {}

level: dbug

message: 'Scheduler: container xen started: re-balancing'

timestamp: 2017-02-24T18:14:09.965080432-05:00

type: logging

metadata:

context:

action: start

created: 2017-02-24 23:11:45 +0000 UTC

ephemeral: "false"

stateful: "false"

used: 1970-01-01 00:00:00 +0000 UTC

level: info

message: Started container

timestamp: 2017-02-24T18:14:10.162965059-05:00

type: logging

metadata:

context: {}

level: dbug

message: 'Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'

timestamp: 2017-02-24T18:14:10.163072893-05:00

type: logging

lxc monitor?的格式有點不同于每個條目都縮合成一行的日志文件，但更重要的是，你可以看到所有?level：dbug?條目。

如何報告 bug

LXD 的 bug

最好報告 bug 的地方是?https://github.com/lxc/lxd/issues。確保完整填寫了 bug 報告模板中的內容，這些信息可以節省我們我們時間來復現環境。

Ubuntu 的 bug

如果你發現 Ubuntu 包本身有問題，無法安裝、升級或刪除。或者遇到 LXD init 腳本的問題。報告此類錯誤的最好是在 Launchpad 上。

在 Ubuntu 系統上，你可以使用：ubuntu-bug lxd?，它將自動包括一些日志文件和包信息供我們查看。

CRIU 的 bug

與 CRIU 相關的 Bug，你可以通過 CRIU 的錯誤輸出發現，你應該在 Launchpad 上報告這些：ubuntu-bug criu

請注意，通過 LXD 使用 CRIU 屬于測試版功能，除非你愿意通過 Canonical 的支持合同付費支持，要么可能需要一段時間才能查看你的錯誤報告。

貢獻給 LXD

LXD 用?Go?寫成并托管在 Github。我們歡迎任外部的貢獻。為 LXD 貢獻不需要 CLA 或類似的法律協議簽署，只是通常的開發者所有權證書（Signed-off-by:?行）。

在我們的問題追蹤器工具中，我們列有許多潛在的功能需求，新的貢獻者可以以此作為良好的起點。通常最好在開始處理代碼先發出 issue，這樣每個人都知道你正在做這項工作，以便我們可以提供一些早期反饋。

從源碼源碼構建 LXD

這里有上游的維護說明：https://github.com/lxc/lxd#building-from-source

你需要在 Github 上 fork 上游倉庫，然后將你的更改推送到你的分支。我們建議每天 rebase 上游的 LXD，因為我們傾向于定期合并更改。

運行測試套件

LXD 維護了兩套測試集，單元測試和集成測試。你可以用下面的命令測試所有：

sudo -E make check

要只運行單元測試，使用：

sudo -E go test ./...

要運行集成測試，使用：

cd test

sudo -E ./main.sh

后者支持相當多的環境變量來測試各種存儲后端、禁用網絡測試、使用 ramdisk 或只是調整日志輸出。其中一些是：

LXD_BACKEND：btrfs、dir、lvm?或?zfs” 之一（默認為?dir） ??
運行 LXD 存儲驅動程序相關的所有測試。
LXD_CONCURRENT：true?或?false（默認為?false） ??
這啟用一些額外的并發測試。
LXD_DEBUG：true?或?false（默認為?false） ??
記錄所有 shell 命令，并在調試模式下運行所有?? LXD 命令。
LXD_INSPECT：true?或?false（默認為?false） ??
測試程序會在故障時掛起，以便你可以檢查環境。
LXD_LOGS：將所有?LXD?日志文件轉儲到的目錄（默認為 “”） ??
所有生成的 LXD 守護進程的?logs?目錄將被復制到此路徑。
LXD_OFFLINE：true?或?false（默認為?false） ??
禁用任何依賴于外部網絡連接的測試。
LXD_TEST_IMAGE： unified 格式的 LXD 鏡像的路徑（默認為 “”） ??
可以使用自定義測試鏡像，而不是默認的最小 busybox 鏡像。
LXD_TMPFS：true?或?false（默認為?false） ??
在?tmpfs?安裝中運行整個測試套件，這會使用相當多的內存，但會使測試速度明顯更快。
LXD_VERBOSE：true?或?false（默認為?false） ??
不太極端的?LXD_DEBUG?版本。shell 命令仍然會記錄，但?-debug?不會傳遞給 LXC 命令，LXD 守護進程只能使用?-verbose?運行。

測試程序將在實際運行之前提醒你任何缺失的依賴項。在相當快的機器上運行該測試可在 10 分鐘內完成。

原文發布時間為：2017-03-09

本文來自云棲社區合作伙伴“Linux中國”

總結

以上是生活随笔為你收集整理的LXD 2.0 系列（十二）：调试，及给 LXD 做贡献的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：移动端类似IOS的滚动年月控件（需要jQ
下一篇：老男孩IT教育38期面授班学员邢伟的决