---

🌌你好！这里是 晓雨的笔记本 在所有感兴趣的领域扩展知识，感谢你的陪伴与支持~ 👋 欢迎添加文末好友，不定期掉落福利资讯

---

写在最前面

版权声明：本文为原创，遵循 CC 4.0 BY-SA 协议。转载请注明出处。

最终方案写到最前面

sudo reboot

重启解决大多数问题hh

原因是：

1. Server-B 上的 systemd-logind 服务与 D-Bus 通信出现问题
2. Claude (Node.js 应用) 在初始化时需要通过 D-Bus 与系统服务交互
3. D-Bus 响应超时，导致整个初始化过程挂起
4. Claude 卡在 plugin 初始化阶段，等待永远不会到来的 D-Bus 响应

---

Claude (Kiro) 辅助撰写
日期：2026-06-20
标签：#debugging #systemd #dbus #claude-code #troubleshooting

📋 问题描述

在服务器 Server-B 上使用 Claude Code VSCode Extension 时，每次发送消息后都会卡住 60 秒超时，而在同配置的服务器 Server-A 上却完全正常。

现象：

• 发送消息后 Extension 无响应
• 60 秒后超时报错
• 日志显示在 “Found 0 plugins” 后停止
• API 代理工作正常，curl 测试成功
• Claude CLI 同样卡死

🔍 调试过程

第一阶段：配置排查（❌ 无效）

尝试 1：检查 API 配置

• 对比了 Server-A 和 Server-B 的 ~/.claude/settings.json
• 配置完全相同，API 地址和 token 正确
• 结论：配置没有问题

尝试 2：重建配置文件

# 备份并重建
mv ~/.claude ~/.claude_backup
cat > ~/.claude/settings.json << 'EOF'
{
  "env": {
    "ANTHROPIC_BASE_URL": "http://api-gateway.internal:28647/",
    "ANTHROPIC_AUTH_TOKEN": "sk-ant-xxxxx...",
    "ANTHROPIC_MODEL": "claude-opus-4-8"
  }
}
EOF

• 结果：问题依旧

尝试 3：测试 API 连接

curl -X POST 'http://api-gateway.internal:28647/v1/messages' \
  -H 'x-api-key: sk-ant-xxxxx...' \
  -d '{"model":"claude-opus-4-8","max_tokens":50,"messages":[{"role":"user","content":"hi"}]}'

• 结果：API 完全正常，返回 200
• 结论：API 服务端没有问题

第二阶段：网络和代理排查（❌ 无效）

尝试 4：使用 localhost 代理

# 在 Server-B 上启动本地代理
python3 /tmp/api_proxy.py &
# 转发 localhost:28647 → api-gateway.internal:28647

# 更新配置使用 localhost
ANTHROPIC_BASE_URL="http://localhost:28647/"

• 结果：问题依旧
• 结论：不是网络延迟或 DNS 问题

尝试 5：检查防火墙和网络连接

# 检查端口监听
netstat -tln | grep 28647

# 测试代理
curl http://localhost:28647/v1/messages

• 结果：代理工作正常，curl 返回 200
• 结论：网络层面完全正常

第三阶段：进程和日志分析（🔍 发现线索）

尝试 6：追踪 Claude 进程

# 实时监控日志
tail -f ~/.claude/sessions/*/debug.log

# 发现关键日志
2026-06-20T02:06:16.240Z [DEBUG] Found 0 plugins (0 enabled, 0 disabled)
# 之后就卡住，没有后续日志

• 发现：Claude 在 plugin 初始化后挂起
• 正常流程应该继续执行 getPluginSkills()

尝试 7：对比 Server-A 的日志

# Server-A 上的正常日志
Found 0 plugins (0 enabled, 0 disabled)
getPluginSkills: Processing 0 enabled plugins  # 立即继续
Total plugin workflows loaded: 0
...

• 结论：Server-B 上 Claude 在调用 getPluginSkills() 时永久挂起

尝试 8：strace 追踪系统调用

strace -e trace=read,connect ~/.vscode-server/.../claude --print 'hi'

• 发现：Claude 不断重复读取 /proc/PID/stat
• 疑似陷入某种监控循环或等待状态

第四阶段：环境隔离测试（🔍 确认系统级问题）

尝试 9：隔离测试环境

# 完全隔离的环境
mkdir /tmp/claude_test
cd /tmp/claude_test
export HOME=/tmp/claude_test
export ANTHROPIC_BASE_URL='http://localhost:28647/'

timeout 15 ~/.vscode-server/.../claude --print 'hi'

• 结果：仍然卡住！
• 重要发现：问题与 ~/.claude 配置无关，是系统级问题

尝试 10：对比系统环境

# 对比内核版本
uname -r  # 两台都是 6.11.0-17-generic

# 对比 ulimit
ulimit -a  # 基本相同

# 对比 MD5
md5sum claude  # binary 完全相同

# 对比系统库
ldd claude | grep libc  # 版本相同

• 结论：系统环境高度相似，但 Server-B 就是不工作

第五阶段：Claude CLI 直接测试（🔍 复现问题）

尝试 11：CLI 直接调用

export ANTHROPIC_BASE_URL='http://localhost:28647/'
export ANTHROPIC_AUTH_TOKEN='sk-...'

echo 'What is 1+1?' | timeout 20 \
  ~/.vscode-server/.../claude --no-chrome

• 结果：超时，无输出
• 确认：CLI 和 Extension 都有同样问题

尝试 12：Debug 模式追踪

claude --no-chrome --debug --debug-to-stderr --print 'hi'

• 输出：

[DEBUG] Found 0 plugins (0 enabled, 0 disabled)
[DEBUG] Git remote URL: null
[DEBUG] No git remote URL found
# 卡住，没有 getPluginSkills 日志

第六阶段：Binary 和 Extension 替换（❌ 无效）

尝试 13：从 Server-A 复制整个 Extension

rsync -az ~/.vscode-server/extensions/anthropic.claude-code-2.1.183-linux-x64/ \
  user@Server-B:~/.vscode-server/extensions/anthropic.claude-code-2.1.183-linux-x64/

• 结果：问题依旧
• 结论：Extension 本身没有问题

第七阶段：根因发现（✅ 找到问题！）

尝试 14：测试 systemd 服务

# 尝试重启（需要 sudo）
sudo reboot

# 报错：
Failed to activate service 'org.freedesktop.login1': 
timed out (service_start_timeout=25000ms)

💡 关键发现：systemd-logind 和 D-Bus 通信超时！

验证：

systemctl status systemd-logind.service
# Status: active (running)
# 但 D-Bus 调用超时 25 秒

systemctl status dbus.service  
# Status: active (running)
# 但队列可能阻塞

根本原因分析：

1. Server-B 上的 systemd-logind 服务与 D-Bus 通信出现问题
2. Claude (Node.js 应用) 在初始化时需要通过 D-Bus 与系统服务交互
3. D-Bus 响应超时，导致整个初始化过程挂起
4. Claude 卡在 plugin 初始化阶段，等待永远不会到来的 D-Bus 响应

✅ 解决方案

方案 1：重启 systemd 服务（推荐）

sudo systemctl restart systemd-logind.service

方案 2：完全重启服务器（如果方案 1 失败）

sudo reboot

重启后的恢复步骤

1. 重启 API 代理

python3 /tmp/api_proxy.py &

2. 验证 API

curl http://localhost:28647/v1/messages -X POST \
  -H 'x-api-key: sk-...' \
  -d '{"model":"claude-opus-4-8","max_tokens":10,"messages":[...]}'

3. 测试 Claude CLI

export ANTHROPIC_BASE_URL='http://localhost:28647/'
export ANTHROPIC_AUTH_TOKEN='sk-...'
echo 'hi' | claude --no-chrome

4. 恢复聊天记录

# 从备份恢复
cp -r ~/.claude_backup_20260620_100604/projects/* ~/.claude/projects/
cp -r ~/.claude_backup_20260620_100604/sessions/* ~/.claude/sessions/
cp -r ~/.claude_backup_20260620_100604/file-history ~/.claude/
cp -r ~/.claude_backup_20260620_100604/session-env ~/.claude/

自动化恢复脚本

创建 /tmp/restore_claude_69.sh：

#!/bin/bash
echo "=== Claude Server-B 恢复脚本 ==="

# 1. 启动 API 代理
if ! pgrep -f "api_proxy.py" > /dev/null; then
    nohup python3 /tmp/api_proxy.py > /tmp/api_proxy.log 2>&1 &
    sleep 2
fi

# 2. 验证端口
ss -tln | grep -q ":28647" || exit 1

# 3. 测试 API
HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' \
  http://localhost:28647/v1/messages -X POST ...)
[ "$HTTP_CODE" = "200" ] || exit 1

# 4. 测试 Claude CLI
export ANTHROPIC_BASE_URL='http://localhost:28647/'
export ANTHROPIC_AUTH_TOKEN='sk-...'
TEST_OUTPUT=$(echo 'hi' | timeout 15 claude --no-chrome 2>&1)
echo "$TEST_OUTPUT" | grep -qi "kiro\|claude" || exit 1

echo "✓ 所有检查通过！"

📊 问题验证

重启前：

$ echo 'hi' | claude --no-chrome
# 60秒超时，无输出

重启后：

$ echo 'hi' | claude --no-chrome
Hi! I'm Kiro, ready to help...
# ✅ 立即响应

Debug 日志对比：

重启前：

[DEBUG] Found 0 plugins (0 enabled, 0 disabled)
[DEBUG] Git remote URL: null
# 卡住

重启后：

[DEBUG] Found 0 plugins (0 enabled, 0 disabled)
[DEBUG] Git remote URL: null
[DEBUG] getPluginSkills: Processing 0 enabled plugins  # ✅ 继续执行
[DEBUG] Total plugin workflows loaded: 0
[DEBUG] Commands and agents loaded in 52ms
...

🎓 经验总结

1. 问题定位的关键步骤

由表及里的排查顺序：

1. ✅ 配置文件（最常见）
2. ✅ 网络连接（次常见）
3. ✅ 进程状态和日志（找到线索）
4. ✅ 环境隔离测试（确认范围）
5. ✅ 系统服务（根本原因）

2. 重要的调试技巧

日志对比法：

• 对比正常环境（Server-A）和问题环境（Server-B）的日志
• 找到最后一条相同的日志，问题就在之后

环境隔离法：

• 逐步排除配置、用户数据的影响
• 使用干净的 HOME 目录测试
• 确认是系统级还是应用级问题

进程追踪法：

• 使用 strace 追踪系统调用
• 使用 --debug 模式查看详细日志
• 监控进程的 CPU、I/O 状态

3. 关键判断点

问题不在 Claude 本身的证据：

• 同一个 binary 在 Server-A 上正常工作
• MD5 哈希完全相同
• 配置文件相同
• API 连接测试成功

问题在系统层面的证据：

• 隔离环境（新 HOME）仍然失败
• 系统服务（systemd-logind）超时
• D-Bus 通信阻塞
• reboot 命令也超时

4. Node.js 应用常见的系统依赖

Node.js 应用（如 Claude）在 Linux 上可能依赖：

• D-Bus：系统服务通信
• systemd-logind：会话管理
• systemd-resolved：DNS 解析
• Unix domain sockets：进程间通信

当这些系统服务出现问题时，应用可能：

• 初始化挂起
• 超时后继续运行
• 某些功能失效

5. 为什么 curl 正常但 Claude 不行？

curl：

• 纯 HTTP 客户端
• 不依赖 D-Bus
• 不需要系统会话管理

Claude (Node.js)：

• 复杂的初始化流程
• 可能查询系统信息（用户、会话、权限）
• 依赖多个系统服务

6. 预防和监控

预防措施：

# 定期检查 D-Bus 状态
systemctl status dbus.service

# 监控 systemd-logind
journalctl -u systemd-logind -f

# 检查 D-Bus 队列
dbus-monitor --system

健康检查脚本：

#!/bin/bash
# 系统服务健康检查

check_service() {
    local service=$1
    if systemctl is-active --quiet $service; then
        echo "✓ $service: active"
    else
        echo "✗ $service: inactive"
        return 1
    fi
}

check_service dbus.service
check_service systemd-logind.service

# 测试 D-Bus 通信
timeout 5 dbus-send --system --print-reply \
    --dest=org.freedesktop.login1 \
    /org/freedesktop/login1 \
    org.freedesktop.DBus.Introspectable.Introspect \
    > /dev/null 2>&1

if [ $? -eq 0 ]; then
    echo "✓ D-Bus communication: OK"
else
    echo "✗ D-Bus communication: TIMEOUT"
fi

🔧 相关问题排查清单

如果遇到类似问题，按以下顺序检查：

• 配置文件是否正确（~/.claude/settings.json）
• API 服务是否正常（curl 测试）
• 网络连接是否畅通（ping、traceroute）
• 进程日志在哪里卡住（--debug 模式）
• 是否能在隔离环境复现（新 HOME 目录）
• systemd-logind 是否正常（systemctl status）
• D-Bus 通信是否超时（dbus-send 测试）
• 是否有其他应用也卡住（Node.js、Electron 应用）
• 系统日志是否有错误（journalctl -xe）
• 最近是否有系统更新或配置变更

📚 参考资源

• Claude Code Documentation
• systemd D-Bus 接口
• Node.js 系统集成
• Linux D-Bus Troubleshooting

💬 总结

这次问题的根本原因是 Server-B 服务器的 systemd-logind 服务与 D-Bus 通信阻塞，导致所有依赖系统服务的应用（包括 Claude）在初始化时挂起。

关键教训：

1. 当应用在某个特定环境失败时，不要只看应用本身
2. 对比正常和异常环境的差异是快速定位的关键
3. 系统服务的健康状态往往被忽视但非常重要
4. 隔离测试可以快速缩小问题范围

时间统计：

• 配置和网络排查：~30 分钟
• 进程和日志分析：~20 分钟
• 环境隔离测试：~15 分钟
• 发现根因：~10 分钟
• 验证解决：~5 分钟
• 总计：~80 分钟

重启服务器后，所有问题立即解决，Claude 恢复正常工作。

---

hello，这里是 晓雨的笔记本 。如果你喜欢我的文章，欢迎三连给我鼓励和支持：👍点赞 📁 关注 💬评论，我会给大家带来更多有用有趣的文章。
原文链接 👉 ，⚡️更新更及时。

欢迎大家点开下面名片，添加好友交流。