ss -tulnp 查不到 PID 和进程名是因为非 root 用户权限不足，-p 参数静默失效；需 sudo 执行，否则输出中 PID/Program name 列为空或报 Permission denied。
ss -tulnp 为什么查不到 PID 和进程名
直接执行 ss -tulnp 却看不到 PID/Program name 列，通常是因为权限不足。非 root 用户无法读取其他用户进程的 socket 信息，-p 参数会静默失效，输出里 PID 那列为空或报错 Permission denied。
实操建议：
- 加
sudo执行：sudo ss -tulnp | grep :8080 - 如果仍无 PID，检查是否被 SELinux 或容器命名空间隔离（如 Docker 容器内运行时，宿主机视角才可见完整进程）
-
ss在某些精简镜像（如 Alpine）中默认不带-p支持，需安装iproute2完整版
lsof -i :端口号 输出里 NAME 字段显示 *:http-alt 是什么意思
http-alt 是 IANA 注册的服务别名，对应端口 8080；*:http-alt 表示该进程监听在所有 IPv4/IPv6 地址（*）的 8080 端口，协议为 TCP。这不是错误，而是正常解析结果。
但要注意：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 如果看到
*:https却实际想用 8443，说明配置里写的是服务名而非数字端口，可能引发意外交互 - 想跳过服务名解析、强制显示数字端口，加
-P参数：sudo lsof -i :8080 -P -
NAME列出现IPv6但你只绑了 IPv4，可能是应用未显式禁用 IPv6，导致内核自动映射双栈监听
netstat 显示端口在 LISTEN 状态，但 kill 掉 PID 后端口还是被占
常见于僵尸监听、TIME_WAIT 残留或内核级绑定（如 systemd socket activation）。netstat 显示的 LISTEN 不一定对应活跃用户态进程。
排查要点：
- 确认 PID 是否真实存在：
ps -p <pid></pid>，若返回 “No such process”，说明进程已退出但 socket 尚未释放 - 检查 TIME_WAIT 状态：
ss -tan state time-wait | grep :8080，这是 TCP 正常回收机制，持续约 60 秒 - 查看 systemd socket 单元：
systemctl list-sockets | grep 8080，若匹配到，需停用对应.socket单元而非服务 - 某些内核模块（如 nf_conntrack）或代理（如 haproxy 的 transparent mode）也可能持有端口，此时
lsof和ss均不可见
fuser -k 强杀后新进程启动仍报 Address already in use
fuser -k 只终止直接打开该 socket 的进程，但不会清理其子进程、守护进程或 fork 后 exec 的新实例。尤其 Java、Node.js 等常通过守护模式重启，杀一次很快又拉起。
更稳妥的做法：
- 先定位主进程：
sudo lsof -i :8080 | head -n 2，关注COMMAND列和父进程关系 - 结合
systemctl查服务：systemctl status $(basename $(readlink /proc/<pid>/exe) 2>/dev/null)</pid> - 对 Java 应用，用
ps aux | grep java配合-Dserver.port=8080等 JVM 参数反查启动命令 - 真正要释放端口，得停服务单元：
sudo systemctl stop tomcat或sudo pkill -f "java.*8080"
