Margrop
Articles294
Tags448
Categories23
1password AC ACP AI AP API AppDaemon Aqara CI/CD Caddy Cloudflare Cookie 认证 Cron D1 Date Diagrams.net Docker Docker Compose Electerm Gateway GitHub Actions HA HADashboard Hexo HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Markdown MiniMax Multi-Agent MySQL NAS Nginx Node-RED Node.js OOM OpenAI OpenClaw OpenResty PPPoE Portainer PostgreSQL ProcessOn Prometheus Proxmox VE RPC SOCKS5 SSL Session Shell Subagent TTS TimeMachine UML Uptime Kuma VPN VPS Web WebSocket Windows Workers activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bitwarden boot brew browser caddy2 cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit container crontab ctyun ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dump dylib edge exception export fail2ban feign firewall-cmd flow frp frpc frps fuckgfw function gcc gfw git github golang gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https iKuai idea image img img2kvm import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live low-code lvm lxc m3u8 mac macos mariadb markdown maven md5 microcode mirror modem modules monitor mount mstsc mysql n2n n5105 nas network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop openfeign openssl os otp ovz p14 packet capture pat pdf pem perf ping pip plugin png powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reflog remote remote desktop renew repo resize retina root route router rule rules runtime safari sata scipy-notebook scoping scp server slmgr so socks source spk spring springboot springfox ssh ssl stash string supernode svg svn swagger sync synology systemctl systemd tap tap-windows tapwindows telecom template terminal tls token totp tvbox txt ubuntu udisk ui undertow uninstall unlocker upgrade url v2ray vhd vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 中国电信 云电脑 交换机 人机协作 代理 体检 值班 健康检查 光猫 公网IP 内存 内存优化 内网 内网IP 内网渗透 写作 升级 协作 博客 反向代理 启动 周一 周末 夏令时 多智能体 多节点 多节点管理 天猫精灵 天翼云 安全 安装 定时任务 容器 容器网络 导入 小米 常用软件 广告屏蔽 序列号 应用市场 异常 心跳 感悟 打工 打工人 技术 抓包 排查 描述文件 故障 故障排查 效率 效率工具 无服务器 日记 时区 显卡虚拟化 智能家居 智能音箱 服务器 服务管理 架构 梯子 模块 流程 流程图 浏览器 漫游 激活 火绒 焦虑 玄学 生活 电信 画图 监控 直播源 直觉 磁盘 端口 端口扫描 管理 续期 网关 网络 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 虚拟机 认证 证书 语雀 超时 路由 路由器 软件管家 软路由 运维 运维监控 连接保活 连接问题 通信机制 部署 配置 钉钉 镜像 镜像源 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客

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:http://blog.margrop.com/post/2026-05-02-gateway-port-eaddrinuse-troubleshooting/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可