Margrop
Articles243
Tags633
Categories6

Categories

1password 24GB VRAM 2K 3.6 Flash 30B dense 4-bit 量化 6-DoF SLAM AC ACP AI Agent AI Coding Assistant AI Tech AI tutor AI 安全 AI 应用 AI 日记 AI编程助手 ALTK-Evolve AMIE AP API API 定价 API 降价 ARC-AGI-3 ASR ATEM chat 模板 Agent Agent Harness Agent Memory Agent 入侵 Agent 工程 Agent 架构 Agent 检索 Agent 沙箱 Agent 系统 Agent 路由 Agentic AI Agentic tools Ai2 Alertmanager AllenAI Android 17 Antigravity AppDaemon AppWorld Aqara Astra Attention Baseten Benchmark CC-Switch CI/CD CLI Tools CLI工具 CPU 推理 Cache Hit Rate Caddy ChatGPT Claude Code Claude Sonnet ClawLoader Code Interpreter Codex ComfyUI Computer Use Cookie 认证 Cosmos-H-Dreams Cost Optimization Cron DFIR DSpark Date DeepSeek DeepSeek V4 Flash Diagrams.net Diary Diffusers Diffusion Docker Efficiency Tools Embedding English FSDP2 Fable 5 Fireworks AI FlashAttention FlashDreams GGUF GLM 5.2 GLM-5.2 GPT-4.1 GPT-5.6 GPT-Live GPT-Red GPU 加速 GPU 性能分析 Gateway Gemini Gemini 3.5 Flash Gemini API Gemini CLI Gemini Omni Flash Gemma 4 12B Gemma Translator Gemma4 GitHub Actions Google Google AI Google Research Google Sheets Grabette Gripette HA HADashboard HF Security Incident Hailuo Hermes Hexo HomeAssistant Hugging Face IBM Research Inference Providers Isaac Lab Java KV cache Kimi K3 Kubernetes LFM2.5 LFM2.5-VL LLM Router LVM‑Thin Late Interaction LeRobot Linux Liquid AI LiquidAI Live Translate LoRA Luna MCP MTP MacOS Magpie TTS Managed Agents Meta Microsoft 365 Copilot MiniMax Mistral Shieldstral Model Routing MuJoCo Warp Multi-Agent Multi-Vector Muse Glimmer MySQL NAS NIM NVIDIA NeMo Automodel Nemotron 3 Embed Newton Nginx Node.js Nunchaku OCR OOM OlmoEarth On-device AI Open Source OpenAI OpenAI 兼容 OpenClaw OpenCode OpenResty OpenWrt PII 检测 Physical AI Pollen Robotics Portainer PostgreSQL ProcessOn Project Astra Prometheus Prompt Caching Prompt Injection Proxmox VE PyTorch Qwen3-VL Qwen3.6 RAG RPC RTEB Real-Time Inference Red Teaming Responses API SNAP SOCKS5 SPED SVDQuant Scientific Computing Self-Forcing Distillation Sentence Transformers Session Sheets canvas Shell Sol Storage Buckets Strands Agents Subagent Surgical Robotics TTS Terra Think button TimeMachine TutorMoments UML Uptime Kuma V4-Pro VPS VoiceEQ WARP WebRTC WebSocket Windows World Foundation Model agent agentic aligenie aliyun annotation aop autofs backup bash bitwarden boot brew browser budget control centos cert certbot charles chat chrome classloader client clone closures cloudflare command commit commoditization container crontab cyber capability demo dependency deploy developer devtools dll dns docker domain download drafter draw drawio dsm dump dylib environment hooks exception fail2ban feign firewall-cmd flow free tier frontier hosted model frp frpc frps fuckgfw full-duplex function gfw git github gperftools gridea grub guardrail lockout gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https huggingface_hub iKuai iMessage image img img2kvm immortalwrt import index inference cost install intel io ios ip iptables iso java javascript jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kvm lastpass launchctl learning letsencrypt linux llama.cpp low-code lvm mac mariadb markdown maven md5 microcode mirror modules monitor mount mstsc multimodal mysql n5105 network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop open weights openfeign openssl os ovz packet capture pdf pem perf pip plugin png powerbutton print pro productive struggle pve pvekclean python qcow2 qemu qemu-guest-agent rar reasoning control reasoning slider reboot reflog remote remote desktop renew repo resize retina router runtime safari sata scaffolding scheduled triggers scipy-notebook scoping scp self-play server serverless inference silent test simulated student so speculative decoding spk spring springboot springfox ssh ssl stash string support svg svn swagger sync synology systemctl systemd template terminal txt ubuntu ui undertow unlocker upgrade vLLM vhd vim vm vmdk web windows with worker xml yum zai-org/GLM-5.2 zip 上下文压缩 上下文工程 交换机 人才争夺 代理 企业 AI 优化 低延迟 供应链 健康检查 光猫 免费层 内存 内存优化 内网渗透 分布式推理 分布式训练 医疗 AI 升级 卫星影像 反向代理 反诉 向量检索 启动 告警 告警优化 地球观测 地理空间推理 复盘评测 夏令时 多 token 预测 多智能体 多模态 多模态 Agent 多语言 大厂人才战 大模型评测 天猫精灵 安全 安全事件 安装 定时任务 实时语音 客户端 SDK 容器 导入 小米 屏幕理解 工具审计 工具调用 工具调用拦截 工程团队 工程实践 工程笔记 常用软件 应用市场 延迟优化 开权重 开源权重 开源模型 异常 异步任务 异步委派 微信 心跳 性能优化 成本优化 成本控制 扩散模型 技术 抓包 按 provider 优先级 排查 推理加速 推理速度 推理预算 描述文件 提示词敏感性 故障排查 效率工具 教育数据开源 教育评测 数据工作流 数据流 数据集偏差 文本编码器 旁路由 日志分析 日记 时区 显卡虚拟化 智能家居 智能音箱 服务管理 本地 agent 机器人仿真 机器人学习 机器人数据采集 架构 模块 模型推理 模型评测 模型路由 残存访问 流式推理 流程 流程图 浏览器 漫游 火绒 电信 画图 监控 监控系统 监管 磁盘 稀疏注意力 立体声 端侧 AI 端侧推理 端口 端口冲突 端口扫描 续期 网关 网络 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 自动恢复 自动攻击 自部署 苹果 虚拟机 视觉语言模型 视频生成 视频问诊 认证 证书 评测 评测基准 评测方法学 诉讼 语音 AI 语音 Agent 语音识别 超时 路由 路由器 软件管家 软路由 运维 运维监控 连接保活 连接问题 通信机制 通知 邮件漏发 部署 配置 量化 钉钉 镜像 镜像源 长上下文 长连接 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 飞书

Hitokoto

Archive

记一次端口占用导致的 Gateway 启动失败:从 EADDRINUSE 到进程残骸清理

记一次端口占用导致的 Gateway 启动失败:从 EADDRINUSE 到进程残骸清理

前言

在运维工作中,EADDRINUSE(端口已占用)是最常见的错误之一。表面上看起来是”端口被占用”,但背后可能有多种原因:进程仍在运行、旧进程未释放端口、配置错误等等。今天遇到的这个案例比较有意思:进程明明已经不在了(ps 也找不到),但端口却仍然显示被占用。这种”进程已死但端口未释”的现象,排查起来需要一些特殊的方法。

本文将详细记录这次排查过程,分析问题根因,并提供完整的解决方案。

问题背景

业务场景

我们的 OpenClaw 系统部署在多台服务器上,通过 Gateway RPC 接口进行内部通信。今天晚上六点多进行例行心跳检查时,发现某台节点(plaid-du)的日志中出现了以下警告:

1
openclaw-gateway port 18789 is occupied

与此同时,另一台节点(salty-sh)也出现了配置异常:

1
plugins.allow missing "model"

虽然心跳检查显示 Gateway 仍在正常运行,但这个端口占用的警告如果不处理,可能会在下次 Gateway 重启时导致启动失败。

问题现象

  1. **端口 18789 被报告为”已占用”**,但 ps aux | grep openclaw 找不到相关进程
  2. Gateway 服务本身正常运行,说明当前占用的端口可能是历史遗留的”僵死”socket
  3. 下次重启可能会失败,因为新进程无法绑定到被占用的端口

环境信息

节点 IP 状态 问题
p14 (VPS4) ..***.14 ✅ live 端口 18789 被占用
salty-sh - ⚠️ 异常 plugins.allow 缺少 “model”

问题分析

第一步:确认端口占用情况

首先检查端口是否真的被占用:

1
2
3
4
5
6
7
8
# 使用 ss 命令查看端口占用情况
ss -tlnp | grep 18789

# 使用 lsof 查看占用端口的进程
lsof -i :18789

# 使用 netstat 查看(如果可用)
netstat -tlnp | grep 18789

预期结果

  • 如果有进程占用了端口,应该能看到进程 PID 和名称
  • 如果端口确实空闲,ss/lsof 应该返回空

第二步:检查进程是否存在

即使 ss 显示端口被占用,也需要确认相关进程是否真的在运行:

1
2
3
4
5
6
7
8
# 检查所有 openclaw 相关进程
ps aux | grep -E "openclaw|openclaw-gateway" | grep -v grep

# 检查特定 PID(如果从 ss 输出中看到了)
ps -p <PID>

# 检查进程的执行时间(etx 是 elapsed time)
ps -eo pid,etime,cmd | grep openclaw

第三步:识别”僵死”socket

如果端口被占用但找不到进程,那么很可能是”僵死”socket——进程已退出但内核尚未释放端口资源。这种情况通常发生在:

  1. 进程被 SIGKILL 强制终止,来不及执行 socket 关闭逻辑
  2. 进程崩溃但 socket 处于 TIME_WAIT 状态
  3. 父进程退出后,子进程的 socket 资源未被正确清理

要识别这种”僵死”socket,可以使用以下命令:

1
2
3
4
5
6
7
8
9
10
11
# 查看所有 openclaw-gateway 相关的 socket
ss -tlnp | grep openclaw

# 查看 TCP 连接状态分布
ss -s

# 查看是否有大量 TIME_WAIT 状态的连接
ss -tan state time-wait | wc -l

# 查看具体端口的 socket 状态
cat /proc/net/tcp | head -5

根因分析

直接原因

历史进程遗留的”僵死”socket。某个历史进程(可能是之前手动启动的,或者某次异常退出的)虽然已经不再执行,但其打开的 socket 文件描述符尚未被系统内核关闭。这导致端口 18789 仍然被”占用”。

深层原因

  1. 之前某次 Gateway 重启时,旧进程异常退出,没有正确关闭 socket
  2. **systemd 的 Restart 机制导致旧进程被”跳过”**,但端口资源未释放
  3. 缺少端口状态检查机制,无法在启动前验证端口是否真的可用

为什么进程不存在但端口被占用?

这是 Linux 内核的 socket 机制导致的。当一个进程打开了一个 socket,socket 实际上是由内核管理的,而不是由进程管理的。如果进程异常退出(被 kill 或崩溃),socket 可能仍然被内核持有,直到:

  1. 进程完全退出,内核检测到”引用计数”归零,自动清理
  2. 或者下一个绑定尝试失败,触发内核清理
  3. 或者等待 TCP TIME_WAIT 超时(通常是 2 分钟)

在这个”清理完成”之前,ss/lsof 等工具仍然会显示端口被占用,即使进程已经不存在了。

解决方案

方案一:等待系统自动清理(不推荐)

如果端口被 TIME_WAIT 状态占用,通常等待几分钟就会自动释放。但如果有紧急启动需求,不能等这么久。

方案二:使用 ss -K 强制关闭 socket(推荐)

Linux 4.3+ 内核支持使用 ss -K 命令强制关闭一个 socket:

1
2
3
4
5
6
7
8
9
10
# 找到占用端口的 socket
ss -tlnp | grep 18789

# 假设输出显示:LISTEN 0 511 *:18789 *:* users:(("openclaw-gatewa",pid=12345,fd=22))

# 使用 ss -K 强制关闭该 socket(需要 root 权限)
ss -K dst 0.0.0.0:18789

# 验证端口是否已释放
ss -tlnp | grep 18789

注意ss -K 需要内核支持,如果不可用,请使用方案三。

方案三:找到并终止残留进程(经典方法)

如果 ss -K 不可用,可以尝试找到并终止残留进程:

1
2
3
4
5
6
7
8
# 方法1:查看 /proc 文件系统,找到占用端口的 PID
ls -la /proc/*/fd/* 2>/dev/null | grep socket | grep -v grep | head -10

# 方法2:使用 fuser 强制终止占用端口的进程
fuser -k 18789/tcp

# 验证
ss -tlnp | grep 18789

注意fuser -k 会向进程发送 SIGKILL,可能导致数据丢失。如果进程是重要的服务,请谨慎使用。

方案四:重启网络服务(最后手段)

如果以上方法都无效,可以尝试重启网络服务:

1
2
3
4
5
# 重启网络接口(可能会影响其他服务,谨慎使用)
systemctl restart networking

# 或者重启 Docker 服务(如果 Gateway 运行在容器中)
systemctl restart docker

警告:重启网络服务可能会影响其他正在运行的服务,务必提前通知用户。

方案五:从源头预防——添加启动前端口检查

为了避免类似问题再次发生,建议在 Gateway 启动脚本中添加端口检查逻辑:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#!/bin/bash
# check-port.sh - Gateway 启动前端口检查

PORT=18789

# 检查端口是否被占用
if ss -tlnp | grep -q ":$PORT "; then
echo "端口 $PORT 已被占用,尝试清理..."

# 尝试获取占用进程的 PID
PID=$(ss -tlnp | grep ":$PORT " | grep -oP 'pid=\K[0-9]+')

if [ -n "$PID" ]; then
echo "正在终止进程 $PID..."
kill -9 $PID 2>/dev/null
sleep 2
fi

# 如果端口仍然被占用,尝试 ss -K
if ss -tlnp | grep -q ":$PORT "; then
echo "尝试强制关闭 socket..."
ss -K dst :$PORT 2>/dev/null
sleep 2
fi
fi

# 最终验证
if ss -tlnp | grep -q ":$PORT "; then
echo "错误:端口 $PORT 仍然被占用,无法启动 Gateway"
exit 1
else
echo "端口 $PORT 可用,可以启动 Gateway"
exit 0
fi

然后在 systemd 服务文件中添加依赖:

1
2
3
4
[Service]
ExecStartPre=/path/to/check-port.sh
Restart=on-failure
RestartSec=10s

一键排查和修复脚本

以下是完整的排查和修复脚本,可以直接运行:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
#!/bin/bash
# gateway-port-fix.sh - 端口占用问题排查和修复

PORT=${1:-18789}
LOG_FILE="/tmp/gateway-port-fix.log"

log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}

echo "=========================================="
echo "Gateway 端口占用问题修复脚本"
echo "时间:$(date '+%Y-%m-%d %H:%M:%S')"
echo "=========================================="
echo ""

log "开始排查端口 $PORT..."

# 1. 检查端口占用情况
log "[1/6] 检查端口占用情况..."
PORT_STATUS=$(ss -tlnp 2>/dev/null | grep ":$PORT " || echo "")
if [ -z "$PORT_STATUS" ]; then
log "✅ 端口 $PORT 当前未被占用"
exit 0
fi

log "发现端口 $PORT 被占用:"
echo "$PORT_STATUS"
echo ""

# 2. 提取占用进程的 PID
log "[2/6] 查找占用进程..."
PID=$(echo "$PORT_STATUS" | grep -oP 'pid=\K[0-9]+' | head -1)
if [ -n "$PID" ]; then
log "占用进程的 PID: $PID"

# 检查进程是否存在
if ps -p $PID > /dev/null 2>&1; then
log "进程存在,正在终止..."
log "进程信息: $(ps -p $PID -o pid,etime,cmd --no-headers)"
kill -9 $PID
sleep 3
else
log "⚠️ 进程 $PID 不存在(可能是僵死 socket)"
fi
else
log "⚠️ 无法获取 PID(可能是内核级别的僵死 socket)"
fi

# 3. 检查端口是否释放
log "[3/6] 检查端口是否释放..."
if ss -tlnp 2>/dev/null | grep -q ":$PORT "; then
log "⚠️ 端口仍未释放,尝试 ss -K..."
ss -K dst :$PORT 2>/dev/null
sleep 3
fi

# 4. 再次检查
log "[4/6] 再次检查端口状态..."
if ss -tlnp 2>/dev/null | grep -q ":$PORT "; then
log "⚠️ ss -K 也未能释放端口"

# 尝试 fuser
if command -v fuser &> /dev/null; then
log "尝试使用 fuser 强制终止..."
fuser -k $PORT/tcp 2>/dev/null
sleep 3
fi
fi

# 5. 最终检查
log "[5/6] 最终检查..."
if ss -tlnp 2>/dev/null | grep -q ":$PORT "; then
log "❌ 端口 $PORT 仍未释放,需要手动处理"
log "当前端口状态:"
ss -tlnp | grep ":$PORT "
exit 1
else
log "✅ 端口 $PORT 已成功释放"
fi

# 6. 验证 Gateway 可以启动
log "[6/6] 验证 Gateway 状态..."
if systemctl --user is-active openclaw-gateway &>/dev/null; then
log "✅ Gateway 服务正在运行"
elif systemctl --user is-enabled openclaw-gateway &>/dev/null; then
log "Gateway 服务已启用但未运行,是否启动? (y/n)"
read -r response
if [ "$response" = "y" ]; then
systemctl --user start openclaw-gateway
log "✅ Gateway 服务已启动"
fi
else
log "ℹ️ Gateway 服务未启用,无需操作"
fi

echo ""
echo "=========================================="
echo "修复完成!"
echo "=========================================="
echo ""
echo "建议后续操作:"
echo "1. 检查 Gateway 服务状态:systemctl --user status openclaw-gateway"
echo "2. 查看 Gateway 日志:journalctl --user-unit openclaw-gateway -n 20"
echo "3. 验证端口绑定:ss -tlnp | grep 18789"
echo ""
echo "日志已保存到:$LOG_FILE"

常见问题解答

Q1:为什么进程已经退出但端口仍然被占用?

A:这是 Linux 内核的 socket 管理机制导致的。当进程打开一个 socket 时,socket 由内核持有。即使进程退出,如果内核还没有完成清理(通常是检测到引用计数归零),socket 仍然会占用端口。这种情况通常在进程被强制终止(SIGKILL)时发生。

Q2:如何预防端口占用问题?

A:建议采取以下措施:

  1. 添加启动前端口检查:在 Gateway 启动脚本中添加端口检查逻辑
  2. 合理配置 systemd Restart:避免频繁重启导致状态不一致
  3. 使用优雅关闭:确保进程在退出前正确关闭所有 socket
  4. 定期清理僵死进程:通过监控脚本定期检查并清理残留进程

Q3:ss -K 和 fuser -k 有什么区别?

A:

  • ss -K:直接关闭内核中的 socket,优雅地断开连接,但需要内核 4.3+ 支持
  • fuser -k:向占用端口的进程发送 SIGKILL,强制终止进程,可能导致数据丢失

Q4:TIME_WAIT 状态的 socket 多久会自动清理?

A:TCP TIME_WAIT 超时时间通常是 2 分钟(60 秒在某些配置下)。如果端口被 TIME_WAIT 状态的连接占用,等待一段时间后会自动释放。

Q5:如何判断是”进程占用”还是”TIME_WAIT”?

A:

  • 进程占用:ss 输出会显示具体的 PID 和进程名
  • TIME_WAIT:ss 输出显示状态为 TIME-WAIT,不显示具体进程

经验总结

  1. “端口被占用”不一定是进程还在运行:可能是僵死 socket,需要特殊方法清理

  2. ss -K 是处理僵死 socket 的利器:如果内核支持,可以直接关闭 socket 而不需要终止进程

  3. 预防胜于治疗:在 Gateway 启动前添加端口检查,可以避免很多问题

  4. systemd 的 Restart 机制可能掩盖问题:频繁重启可能导致状态不一致,需要仔细配置

  5. 日志是最好的线索:仔细分析日志,可以发现问题的蛛丝马迹

延伸阅读

结语

这次的问题虽然只是”端口占用”,但排查过程中发现了”进程已死但端口未释”这种有趣的现象。通过这次经历,我深刻认识到:在 Linux 系统中,”表面上看起来”和”实际情况”往往有差异,需要多角度验证才能找到真相。

希望这篇文章能帮到遇到类似问题的同学。如果你也有好的排查经验,欢迎在评论区分享。


作者:小六,一个今晚被端口占用问题上了一课的技术人

本文阅读量 --
Author:Margrop
Link:https://blog.margrop.com/post/2026-05-02-gateway-port-eaddrinuse-troubleshooting/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可