[架構之美]linux下常見故障問題解決方案
一，文本文件忙
問題一：root@wh-VMware-Virtual-Platform:/home/hail# cp /root/containerd/bin/* /usr/bin/
cp: 無法創建普通文件 ‘/usr/bin/containerd’: 文本文件忙
在Linux系統中遇到“文本文件忙”錯誤時，通常是因為目標文件正在被進程占用。以下是分步解決方案：
現象截圖：
1.1 問題原因分析
錯誤 cp: 無法創建普通文件 '/usr/bin/containerd': 文本文件忙 表明：
- 目標文件
/usr/bin/containerd正在被系統進程占用。 - 該文件可能屬于正在運行的容器運行時服務（如
containerd或docker）。
1.2 解決方案步驟
1. 確認占用文件的進程
使用 lsof 或 fuser 命令查找正在使用文件的進程：
sudo lsof /usr/bin/containerd
# 或
sudo fuser -v /usr/bin/containerd
2. 停止相關服務
停止正在使用 containerd 的服務（按順序操作）：
# 停止 Docker（如果使用）
sudo systemctl stop docker# 停止 Containerd
sudo systemctl stop containerd# 確保進程終止（強制清理）
sudo pkill -9 containerd
3. 復制文件
確認服務停止后，重新執行復制命令：
sudo cp /root/containerd/bin/* /usr/bin/
4. 重啟服務
復制完成后恢復服務：
sudo systemctl start containerd
sudo systemctl start docker # 如果之前停止了 Docker
1.3 附加說明
- 內核鎖定問題：某些情況下，即使服務已停止，內核仍可能鎖定文件。此時可重啟系統或使用
cp --remove-destination覆蓋：sudo cp --remove-destination /root/containerd/bin/* /usr/bin/ - 安全模式操作：如果仍無法替換，可嘗試進入單用戶模式或使用 LiveCD 環境操作。
1.4 命令總結
# 1. 檢查進程占用
sudo lsof /usr/bin/containerd# 2. 停止服務
sudo systemctl stop docker containerd
sudo pkill -9 containerd# 3. 強制復制
sudo cp --remove-destination /root/containerd/bin/* /usr/bin/# 4. 重啟服務
sudo systemctl start containerd docker
解決截圖：
二，域名解析錯誤
root@wh-VMware-Virtual-Platform:~# ping www.baidu.com
ping: www.baidu.com: 域名解析出現暫時性錯誤
root@wh-VMware-Virtual-Platform:~#
現象截圖：
以下是一些可能的原因和解決方法：
2.1 DNS 服務器配置問題
- 原因：DNS 服務器可能沒有正確配置，或者當前的 DNS 服務器無法解析
www.baidu.com。 - 解決方法：
-
檢查當前系統的 DNS 設置。你可以通過以下命令查看當前的 DNS 配置：
cat /etc/systemd/resolved.conf如果發現 DNS 服務器地址不正確或不可用，可以手動修改為可靠的 DNS 服務器，例如 Google 的公共 DNS（8.8.8.8 和 8.8.4.4）或阿里云的公共 DNS（223.5.5.5 和 223.6.6.6）。
-
修改 /etc/systemd/resolved.conf 文件，添加以下內容：
DNS=8.8.8.8 8.8.4.4 -
保存文件后， 重啟
systemd-resolved服務 ，再次嘗試ping。sudo systemctl restart systemd-resolved
-
? 解決截圖：
2.2 網絡連接問題
- 原因：你的網絡連接可能不穩定，或者網絡配置有問題。
- 解決方法：
- 檢查網絡連接是否正常。嘗試
ping本地網關或其他已知的 IP 地址，例如：
如果無法成功，說明網絡連接可能有問題。ping -c 4 8.8.8.8 - 檢查網絡配置文件（如
/etc/network/interfaces或/etc/netplan/*.yaml），確保網絡配置正確。 - 如果是通過 DHCP 自動獲取 IP 地址，嘗試重啟網絡服務：
或者重啟網絡管理器：sudo systemctl restart networkingsudo systemctl restart NetworkManager
- 檢查網絡連接是否正常。嘗試
2.3 防火墻或安全組限制
- 原因：防火墻或安全組可能阻止了 DNS 查詢或 ICMP（ping）請求。
- 解決方法：
- 檢查系統防火墻規則。你可以使用以下命令查看防火墻狀態：
如果防火墻處于活動狀態，確保允許 DNS 查詢（UDP 端口 53）和 ICMP 流量。sudo ufw status - 如果你在虛擬機中運行，檢查虛擬機的網絡設置和宿主機的防火墻規則。
- 檢查系統防火墻規則。你可以使用以下命令查看防火墻狀態：
2.4 DNS 緩存問題
- 原因：本地 DNS 緩存可能損壞或過期。
- 解決方法：
- 清除本地 DNS 緩存。在 Linux 系統中，可以嘗試以下命令：
或者：sudo systemctl restart nscdsudo systemctl restart NetworkManager - 再次嘗試
ping。
- 清除本地 DNS 緩存。在 Linux 系統中，可以嘗試以下命令：
三，卸載pcre
3.1 卸載通過 apt 安裝的 PCRE
運行以下命令卸載系統中通過 apt 安裝的 PCRE：
sudo apt remove --purge libpcre3 libpcre3-dev
這將刪除所有與 PCRE 相關的包及其配置文件。
3.2 確認卸載成功
運行以下命令確認 PCRE 是否已被完全卸載：
pcre-config --version
如果系統提示 沒有那個文件或目錄，說明 PCRE 已被成功卸載。
四，openrsty
root@wh-VMware-Virtual-Platform:~/apisix-offline/apisix/apisix-3.12.0# openresty -v
openresty: symbol lookup error: openresty: undefined symbol: lua_getexdata
# 刪除舊版OpenResty
sudo rm -rf /usr/local/openresty# 清理可能的殘留庫
sudo rm -f /usr/local/lib/libluajit-*.so*# 檢查全局環境變量（確保無舊路徑）
echo $LD_LIBRARY_PATH # 如有舊路徑，需修改~/.bashrc或/etc/profile#清除后重新安裝
4.1 解決 APISIX 安裝時的 GPG 公鑰錯誤
此錯誤是由于 APT 軟件源缺少 Docker 官方倉庫的 GPG 公鑰導致。以下是詳細修復步驟：
1. 添加缺失的 Docker GPG 公鑰
# 直接下載并安裝 Docker 官方 GPG 密鑰
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg# 設置密鑰文件權限
sudo chmod 644 /etc/apt/trusted.gpg.d/docker.gpg
2. 修正軟件源配置
檢查 /etc/apt/sources.list.d/ 目錄下的 Docker 源文件（如 docker.list），確認其指向 華為云鏡像源 時使用正確的密鑰配置：
# 示例：華為云 Docker CE 鏡像配置
echo "deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://repo.huaweicloud.com/docker-ce/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list
3. 清除并更新 APT 緩存
# 清理舊緩存
sudo rm -rf /var/lib/apt/lists/*# 強制更新
sudo apt update --allow-insecure-repositories
4. 修復 APISIX 依賴安裝
重新執行 APISIX 的依賴安裝命令：
cd apisix-3.12.0
make deps
4.2關鍵問題解析
| 問題原因 | 解決方案 | 作用說明 |
|---|---|---|
| 缺少 Docker 倉庫公鑰 | 手動下載并安裝 GPG 密鑰 | 驗證軟件包簽名合法性 |
| 鏡像源簽名配置錯誤 | 在源配置中顯式指定 signed-by 路徑 | 明確關聯密鑰與倉庫 |
| APT 緩存污染 | 強制清理并更新緩存 | 確保獲取最新元數據 |
4.3驗證修復結果
# 檢查 Docker 源狀態
sudo apt update 2>&1 | grep "docker-ce"# 預期輸出應無 GPG 錯誤，顯示倉庫可更新：
# Get:1 https://repo.huaweicloud.com/docker-ce/linux/ubuntu noble InRelease [2,854 B]
4.4備選方案：跳過 GPG 驗證（不推薦）
若緊急情況下需臨時繞過驗證（生產環境禁用）：
# 修改源配置為信任倉庫
echo "deb [trusted=yes] https://repo.huaweicloud.com/docker-ce/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
4.5 附錄：Docker 官方源配置參考
# 標準 Docker 官方源（非鏡像）
echo "deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list
五，docker拉取鏡像超時
# 查看 containerd 是否正在運行
sudo systemctl status containerd# 如果未運行，啟動服務并設置開機自啟
sudo systemctl start containerd
sudo systemctl enable containerd
5.1 問題分析
Docker 在嘗試拉取鏡像時無法連接到 containerd 服務（底層容器運行時），導致超時錯誤。常見原因包括：
- containerd 未運行：服務未啟動或崩潰。
- 權限問題：用戶或 Docker 無權限訪問
containerd.sock。 - 資源不足：系統資源（如磁盤空間、內存）耗盡。
- 配置錯誤：Docker 或 containerd 的配置損壞。
5.2 逐步解決方案
1. 檢查 containerd 服務狀態
# 查看 containerd 是否正在運行
sudo systemctl status containerd# 如果未運行，啟動服務并設置開機自啟
sudo systemctl start containerd
sudo systemctl enable containerd
2. 驗證 containerd.sock 文件權限
# 檢查 socket 文件是否存在
ls -l /run/containerd/containerd.sock# 預期權限示例（所屬組通常為 docker 或 root）
srw-rw---- 1 root root 0 Aug 10 15:30 /run/containerd/containerd.sock# 如果權限不符，修復權限并重啟服務
sudo chmod 660 /run/containerd/containerd.sock
sudo chown root:docker /run/containerd/containerd.sock
sudo systemctl restart containerd
3. 重啟 Docker 和 containerd 服務
sudo systemctl restart docker containerd
4. 檢查系統資源
# 檢查磁盤空間
df -h# 檢查內存使用
free -h# 如果資源不足，清理空間或增加資源
5. 查看詳細日志定位問題
# 查看 containerd 日志
sudo journalctl -u containerd --since "5 minutes ago"# 查看 Docker 日志
sudo journalctl -u docker --since "5 minutes ago"
6. 重裝 Docker 和 containerd（若配置損壞）
# 卸載舊版本
sudo apt-get purge -y docker-ce docker-ce-cli containerd.io# 清理殘留文件
sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd# 重新安裝
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io# 啟動服務
sudo systemctl start docker containerd
5.3 其他可能原因
1. Docker 與 containerd 版本不兼容
- 確保使用官方支持的版本組合，參考 Docker 文檔。
2. 防火墻/SELinux 攔截
# 臨時禁用 SELinux（僅用于測試）
sudo setenforce 0# 如果問題解決，需調整 SELinux 策略或禁用
sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
3. 檢查 Docker 配置文件
# 查看 Docker 的 containerd 配置
sudo cat /etc/docker/daemon.json# 如果文件存在，確保包含以下內容（若無則無需修改）
{"exec-opts": ["native.cgroupdriver=systemd"],"log-driver": "json-file","log-opts": { "max-size": "100m" },"storage-driver": "overlay2"
}
六，apisix停服務報錯
root@wh-VMware-Virtual-Platform:/home/apisix/apisix-3.12.0# apisix stop /usr/local/openresty//luajit/bin/luajit ./apisix/cli/apisix.lua stop nginx: [error] open() “/home/apisix/apisix-3.12.0/logs/nginx.pid” failed (2: No such file or directory)
6.1 問題原因
執行 apisix stop 時提示 nginx.pid 文件缺失，通常有兩種可能：
- APISIX/Nginx 并未真正運行，因此沒有生成 PID 文件。
- PID 文件路徑配置錯誤，APISIX 找不到預期的
nginx.pid文件。
6.2 解決步驟
1. 確認 APISIX/Nginx 是否正在運行
ps aux | grep -E 'apisix|nginx'
- 如果輸出中沒有類似
nginx: worker process或apisix的進程，說明服務未運行，直接忽略錯誤即可（無需停止）。 - 如果輸出中有相關進程，說明服務仍在運行，但 PID 文件丟失，需手動停止。
2. 手動停止服務
-
方法 1：優雅停止（推薦）
如果知道nginx.pid的正確路徑（比如在配置文件中指定了其他路徑）：nginx -p /home/apisix/apisix-3.12.0/ -c conf/nginx.conf -s stop -
方法 2：強制停止
如果進程存在但找不到 PID 文件：sudo pkill -f nginx # 強制終止所有 nginx 相關進程
6.3. 檢查 PID 文件路徑配置
打開 APISIX 的配置文件 conf/config.yaml，確認 nginx_config.pid_file 配置項：
nginx_config:pid_file: /home/apisix/apisix-3.12.0/logs/nginx.pid # 檢查此路徑是否存在
- 如果路徑錯誤（例如目錄不存在），需修改為正確路徑或手動創建目錄：
mkdir -p /home/apisix/apisix-3.12.0/logs/
6.4. 重新啟動 APISIX
停止后重新啟動服務，觀察是否正常生成 PID 文件：
apisix start
- 檢查 PID 文件是否生成：
ls /home/apisix/apisix-3.12.0/logs/nginx.pid
6.5. 查看日志定位問題
如果啟動失敗，檢查錯誤日志：
tail -f /home/apisix/apisix-3.12.0/logs/error.log
常見問題：
- 端口被占用
- 配置文件語法錯誤
- 權限不足（可嘗試用
sudo運行）
希望本教程對您有幫助，請點贊??收藏?關注支持！歡迎在評論區留言交流技術細節！
)
