Margrop
Articles388
Tags773
Categories7

Categories

1password 2K 3.6 Flash 30s timeout 4-bit 量化 6-DoF SLAM AC ACL ACL 切换 ACP AI AI Agent AI Coding Assistant AI Tech AI tutor AI 安全 AI 日记 AI编程助手 AI辅助 AI辅助编程 AP API ARC-AGI-3 ASR Agent Agent Harness Agent 入侵 Agent 检索 Agent 沙箱 Agent 系统 Agent 路由 AgentPlan Agentic AI Agentic tools Ai2 Alertmanager AllenAI Android 17 Antigravity AppDaemon AppWorld Aqara Attention Baseten Blog CC-Switch CI/CD CLI Tools CLI 工具 CLI工具 CPU 推理 CSRF Cache Hit Rate Caddy Categories 404 Claude Code Claude Sonnet ClawLoader Cloudflare Code Interpreter Codex Coding Plan Coding Plan Dashboard ComfyUI Computer Use Context Compression Cookie 认证 Cosmos-H-Dreams Cost Optimization Cron D1 DFIR Date DeepSeek V4 Flash Diagrams.net Diary Diffusers Diffusion Docker Docker Compose Efficiency Tools Electerm Embedding English FSDP2 Fable 5 Fireworks AI FlashAttention FlashDreams Flask 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 GitHub GitHub Actions GitHub PR Google Google AI Grabette Gripette HA HADashboard Hailuo Hermes HermesAgent Hexo HomeAssistant Hugging Face Hugo IBM Research IP IPv4 Inference Providers Isaac Lab Java KV cache Kimi Code Kimi K3 Kubernetes LFM2.5 LLM Router LVM‑Thin LeRobot Linux Liquid AI Live Translate LoRA MCP MacOS Managed Agents Markdown Memory 上限 Microsoft 365 Copilot MiniMax Model Routing MuJoCo Warp Multi-Agent MySQL NAS NVIDIA NeMo Automodel Nemotron 3 Embed NewAPI Newton Nginx Node-RED Node.js Nunchaku OOM OlmoEarth On-device AI Open Source Open Viking OpenAI OpenAI 兼容 OpenClaw OpenCode OpenResty OpenWrt PII 检测 PPPoE Physical AI Pollen Robotics Portainer PostgreSQL ProcessOn Prometheus Prompt Injection Proxmox VE PyTorch Qwen3-VL RPC RTEB Real-Time Inference Red Teaming Responses API Restart SIGTERM SNAP SOCKS5 SOCKS5 代理 SPED SSL SVDQuant Scientific Computing Self-Forcing Distillation Session Shell Skill 管理 Subagent Surgical Robotics Synology NAS TTS TimeMachine TutorMoments UML Uptime Kuma VPN VPS VoiceEQ WARP Web WebRTC WebSocket Windows Workers World Foundation Model activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bg-review bitwarden boot brew browser budget control caddy2 cc-switch-cli cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit conn_id container cron 排错 crontab cross_sync ctyun ddsm demo dependency deploy developer devtools disconnect topic dll dns docker domain download draw drawio dsm dump dylib easytier edge environment hooks exception exit code 1 export fail2ban feign firewall-cmd flow fork free tier frp frpc frps fuckgfw full-duplex function fuzzy match gateway gcc gfw git github golang gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https huggingface_hub iKuai iMessage idea image img img2kvm immortalwrt import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s keepalive keepalive ping timeout 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 mdadm memory 上限 microcode mirror modem modules monitor mount mstsc mysql n2n n5105 nas network newapi nfs no close frame node node-red nodejs nohup notepad++ npm nssm ntp one-api 容器 oop openfeign openssl openviking os otp ovz p14 packet capture pat pdf pem perf ping pip plugin png powerbutton print pro productive struggle 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 scaffolding scheduled triggers scipy-notebook scoping scp self-play server serverless inference silent test simulated student skill_manage slmgr so socks source spk spring springboot springfox ssh ssl stash string supernode support svg svn swagger sync synology systemctl systemd tap tap-windows tapwindows telecom template terminal tls tmux token totp tvbox txt ubuntu udisk ui undertow uninstall unlocker upgrade url v2ray vLLM vhd viking_search vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 上下文压缩 个人品牌 中国电信 临时关权限 临时提权 云电脑 交换机 人才争夺 人机协作 代理 企业 AI 优化 体检 供应链 值班 健康检查 光猫 公众号 公网IP 内存 内存优化 内容发布 内网 内网IP 内网渗透 写作 分布式推理 分布式训练 升级 协作 协作习惯 协议层 协议转换 单平台型异常 博客 博客同步 博客改名 博客运维 卫星影像 反向代理 反诉 变更审计 可靠性 后台 Review 启动 告警 告警优化 周一 周一傍晚 周一焦虑 周三傍晚 周五 周六 周四傍晚 周四晚 周报 周日 周末 回滚 地球观测 地理空间推理 复盘评测 夏令时 多 agent 工具链 多协议并发 多智能体 多模态 多节点 多节点管理 多通道并发 大厂人才战 大模型评测 天猫精灵 天翼云 失败模式 字体大小 安全 安全事件 安全意识 安装 定时任务 实时语音 客户端 SDK 容器 容器网络 导入 小米 工作感悟 工具审计 工具白名单 工具调用 工具调用拦截 工程团队 工程实践 工程笔记 常用软件 并发窗口 广告屏蔽 序列号 应用市场 开放 API 开权重 开源模型 开源项目 异常 异步任务 异步委派 微信 微信公众号 微信限流 心智成长 心跳 心跳检查 性能优化 感悟 成本控制 打工 打工人 打工人日记 扩散模型 技术 抓包 按 provider 优先级 排查 排障思路 推理加速 描述文件 提示词敏感性 故障 故障恢复 故障排查 效率 效率工具 教育数据开源 教育评测 数据 文本编码器 旁路由 无服务器 日志排查 日记 时区 时段权限 显卡虚拟化 智能体集成 智能家居 智能音箱 服务器 服务管理 本地安装 机器人仿真 机器人数据采集 权限管理 架构 框架级切片 梯子 模块 模型推理 模型路由 残存访问 治理层 流式推理 流程 流程图 浏览器 漫游 激活 火山引擎 火绒 灾难恢复 焦虑 独立仓库 玄学 生活 电信 画图 监控 监控系统 监管 直播源 直觉 磁盘 磁盘故障 稀疏样本 稀疏注意力 立体声 端口 端口冲突 端口扫描 管理 续期 网关 网络 网络风暴 群晖 群晖 NAS 脚本 脚本优化 腾讯 自动化 自动化反思 自动化运维 自动恢复 自动攻击 自动重启 自动重连 自托管 LLM 网关 苹果 虚拟机 视频生成 认证 证书 评测基准 评测方法学 诉讼 语雀 语音 AI 质量检查 超时 跨平台 路由 路由器 软件管家 软路由 运维 运维日常 运维监控 进程生命周期 连接保活 连接问题 通信机制 通知 邮件漏发 部署 配置 钉钉 钉钉断开 镜像 镜像源 长上下文 长连接 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 需求变更 飞书

Hitokoto

Archive

记一次排查 Gateway 端口被旧进程占用的完整流程

记一次排查 Gateway 端口被旧进程占用的完整流程

前言

在运维工作中,经常会遇到这样的问题:服务重启后无法启动,报错显示端口被占用。但当你 netstat 查一下,发现并没有进程在监听这个端口。这种”幽灵占用”问题排查起来往往让人摸不着头脑。

本文将记录一次完整的 Gateway 端口冲突排查过程,最终定位到是旧版本的进程没有正确退出导致的。

问题背景

故障描述

  • 故障时间:近期某日晚上
  • 故障表现:Gateway 服务无法启动,报错 Port 18789 is already in use
  • 影响范围:Gateway 无法提供 Web UI 服务

环境信息

  • 操作系统:CentOS 7
  • 服务:OpenClaw Gateway
  • 端口:18789

排查过程

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

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

1
2
3
4
5
# 检查端口 18789 是否被占用
ss -tlnp | grep 18789

# 输出显示
tcp 0 0 0.0.0.0:18789 0.0.0.0:* LISTEN 2756798/openclaw-ga

好家伙,有进程在监听!而且 PID 是 2756798,进程名是 openclaw-ga

第二步:检查进程详情

查看这个进程是什么:

1
2
3
4
5
# 查看进程详情
ps aux | grep 2756798

# 输出显示
root 2756798 0.0 0.4 1234567 89012 ? Ss Mar23 ? 1:30 /opt/openclaw/openclaw-gateway --config=/etc/openclaw/config.yml

问题来了:进程名显示是 openclaw-ga,而且从 3 月 23 号就在运行了。这说明什么?

这是一个旧版本的 Gateway 进程,没有正确退出。

第三步:检查当前服务状态

查看当前的 Gateway 服务状态:

1
2
3
4
5
6
7
# 查看 systemd 服务状态
systemctl status openclaw-gateway

# 输出显示
● openclaw-gateway.service - OpenClaw Gateway
Loaded: loaded (/etc/systemd/system/openclaw-gateway.service; enabled)
Active: inactive (dead) since Sun 20:00:00 CST 2026; 30min ago

服务状态是 inactive (dead),说明 systemd 认为服务没有在运行。但端口却被占用了,说明有一个进程在跑,但不是通过 systemd 启动的。

第四步:分析根因

这种情况通常是因为:

  1. 手动启动的进程:有人直接运行了 ./openclaw-gateway,没有通过 systemd
  2. 升级时的遗留:升级过程中旧的进程没有完全退出
  3. 脚本残留:某个启动脚本里既有 systemd 启动又有直接运行

对于我们的场景,最可能的原因是:之前手动启动了一个 Gateway,后来用 systemd 重启服务时,旧的进程没有被清理

第五步:处理旧进程

既然知道是旧进程在占用端口,那就把它杀掉:

1
2
3
4
5
6
7
8
9
# 先确认这个进程是否可以安全杀掉
ps -p 2756798 -o pid,ppid,etime,cmd

# 如果确认是旧进程,杀掉它
kill 2756798

# 等待几秒,确认进程已退出
sleep 2
ss -tlnp | grep 18789

第六步:启动服务

旧进程杀掉后,启动服务:

1
2
3
4
5
6
7
8
# 通过 systemd 启动服务
systemctl start openclaw-gateway

# 检查服务状态
systemctl status openclaw-gateway

# 验证端口监听
ss -tlnp | grep 18789

第七步:设置开机自启

为了防止这个问题再次发生,确保服务是 enabled 状态:

1
2
3
4
5
# 确保服务开机自启
systemctl enable openclaw-gateway

# 查看当前是否 enabled
systemctl is-enabled openclaw-gateway

根因分析

问题根因

这次问题的根本原因是:旧版本进程没有正确退出,占用了新版本需要使用的端口

具体情况可能是:

  1. 某次升级时,旧的 Gateway 进程还在运行
  2. 新版本的启动脚本没有检查并清理旧进程
  3. 直接 ./openclaw-gateway 启动的进程没有被 systemd 管理

为什么之前没有发现

这个问题之前没有暴露出来,可能是因为:

  1. 机器很久没有重启过
  2. 升级后旧进程和新进程恰好用了不同的配置文件端口
  3. systemd 服务的启动顺序问题

一键解决方案

如果你遇到了类似的”端口被幽灵进程占用”问题,可以使用以下脚本快速排查和解决:

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
#!/bin/bash

# 端口冲突快速排查脚本
PORT=${1:-18789}
SERVICE_NAME="openclaw-gateway"

echo "=== 端口 ${PORT} 冲突排查 ==="
echo ""

# 1. 检查端口占用
echo "1. 检查端口占用情况..."
ss -tlnp | grep ":${PORT} "
echo ""

# 2. 检查进程详情
echo "2. 检查占用进程的详细信息..."
PID=$(ss -tlnp | grep ":${PORT} " | grep -oP 'pid=\K\d+')
if [ -n "$PID" ]; then
ps -p $PID -o pid,ppid,etime,cmd
echo ""
echo "进程运行时间: $(ps -p $PID -o etime --no-headers)"
else
echo "端口未被占用"
fi
echo ""

# 3. 检查 systemd 服务状态
echo "3. 检查 systemd 服务状态..."
systemctl status $SERVICE_NAME --no-pager
echo ""

# 4. 提供解决方案
echo "=== 解决方案 ==="
if [ -n "$PID" ]; then
echo "发现旧进程 PID=$PID 占用了端口"
echo ""
echo "执行以下命令清理旧进程并重启服务:"
echo " kill $PID"
echo " sleep 2"
echo " systemctl restart $SERVICE_NAME"
echo ""
echo "是否现在执行? (y/n)"
read -r answer
if [ "$answer" = "y" ]; then
kill $PID
sleep 2
systemctl restart $SERVICE_NAME
echo "服务已重启"
systemctl status $SERVICE_NAME --no-pager
fi
else
echo "端口未被占用,服务可能正常"
fi

预防措施

1. 确保服务通过 systemd 管理

所有 Gateway 服务都应该通过 systemd 管理,禁止直接运行:

1
2
# 禁止直接运行的方式
# 使用 systemctl start 而不是 ./openclaw-gateway

2. 升级脚本中加入进程检查

在升级脚本中加入旧进程检查和清理逻辑:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash

# 升级脚本示例

# 1. 检查是否有旧进程在运行
OLD_PID=$(ps aux | grep 'openclaw-gateway' | grep -v grep | awk '{print $2}')
if [ -n "$OLD_PID" ]; then
echo "发现旧进程 PID=$OLD_PID,正在停止..."
kill $OLD_PID
sleep 3
fi

# 2. 执行升级
echo "开始升级..."

# 3. 启动新服务
systemctl restart openclaw-gateway

3. 使用 pid 文件

让服务使用 pid 文件,方便检查和清理:

1
2
# 在启动命令中加入 --pidfile 参数
/opt/openclaw/openclaw-gateway --config=/etc/openclaw/config.yml --pidfile=/var/run/openclaw-gateway.pid

4. 定期检查服务状态

配置监控,定期检查服务状态和端口占用情况:

1
2
# 添加到 crontab
*/5 * * * * /opt/scripts/check-gateway.sh

常见问题解答

Q:端口显示被占用,但找不到进程怎么办?

A:可能是僵尸进程。尝试使用 ps aux | grep -v grep | grep 18789 确认,或者重启服务器(谨慎操作)。

Q:杀掉进程后服务还是无法启动怎么办?

A:检查一下是否有残留的 socket 文件:ls -la /var/run/openclaw-gateway.*。如果有,删除后再试。

Q:如何避免这种情况再次发生?

A:确保所有启动都通过 systemd,禁止手动直接运行服务。升级时先停止旧服务再启动新服务。

Q:能否自动检测并清理旧进程?

A:可以。创建一个定时任务,检测端口占用情况,如果发现非 systemd 管理的进程,自动清理。

Q:服务显示 active,但端口没监听是怎么回事?

A:可能是服务启动失败。可以查看日志:journalctl -u openclaw-gateway -n 50,根据错误信息进一步排查。

经验总结

  1. 端口被占用不一定是服务在跑:可能是旧进程残留
  2. systemd 状态和实际进程状态可能不一致:需要交叉验证
  3. 升级时要先清理旧进程:不能假设旧进程会自动退出
  4. 所有服务都应该通过 systemd 管理:避免”幽灵进程”

延伸阅读

结语

这次端口冲突问题的排查过程虽然不复杂,但很有代表性。很多时候,问题的根因并不是”服务挂了”,而是”旧的东西没有清理干净”。

在运维工作中,我们需要养成一个习惯:每次重启/升级时,确保旧的进程/配置已经被完全清理。只有这样,才能避免类似的”幽灵占用”问题。

希望这篇文章能帮到你。如果有问题,欢迎在评论区讨论。


作者:小六,一个在上海努力搬砖的程序员

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