进程PID kill不掉？如何解决端口占用

最新推荐文章于 2024-09-13 10:38:20 发布

风乎舞雩咏而归

最新推荐文章于 2024-09-13 10:38:20 发布

阅读量5.8k

点赞数 7

分类专栏：开发

本文链接：https://blog.csdn.net/m0_37828989/article/details/115721880

版权

开发专栏收录该内容

17 篇文章 0 订阅

订阅专栏

当需要特定端口但被其他进程占用，尤其是被Systemd管理的alertmanager进程占用时，简单的kill命令可能无法解决问题。文中详细描述了通过检查进程依赖、使用systemctl停止相关Unit以及最终成功释放9094端口的步骤，强调了解决此类问题的正确方法。

摘要由CSDN通过智能技术生成

问题描述

我需要9094端口，出于某些原因，我的程序只能运行在该端口。但是该端口被其他的进程所占用，如图：
在这里插入图片描述
一般来说，遇到这种情况，直接kill -9 PID就可以结束该进程，进而释放端口号了。但是问题来了，kill进程并不能成功，alertmanager进程换了个PID，继续牢牢地占用着9094端口。

问题解决

首先在这我们需要明确，并不是kill进程不成功，事实上，kill进程成功了，所以alertmanager结束，PID3087释放；但是，它又被其他服务唤醒，所以alertmanager换了一个新的PID 97600，仍旧占据着端口号9094。

那么我们进而需要找到唤醒alertmanager的其他进程，通过pstree -asp PID可以查看进程的父进程，如下图
在这里插入图片描述
从图中可以发现问题的症结所在：从最高层来看，它是由Systemd 系统守护进程调用的。可以简单的理解成：Systemd是alertmanager的祖先进程。
Systemd是操作系统的第一个进程（PID等于1），其他的进程都是它的子进程；它的设计目标是，为系统的启动和管理提供一套完整的解决方案；Systemd 并不是一个命令，而是一组命令，涉及到系统管理的方方面面；Systemd 可以管理所有系统资源。不同的资源统称为 Unit（单位）。

关于Systemd，可参考Systemd 入门教程：命令篇

所以，我们采用sudo systemctl stop alertmanager想要停止alertmanager这个Unit，结果
在这里插入图片描述
果然，还是不行。那么我们还是从alertmanager的父进程 runsvdir /opt/gitlab/service入手，采用命令“systemctl stop gitlab-runsvdir.service”

成功，9094端口成功释放！

命令总结：

sudo netstat -nlpt | grep 9094 		# 查看端口9094占用
sudo kill `sudo lsof -t -i:3306` 	# 杀死占用端口3306的所有进程
pstree -asp PID						# 列出该PID进程的依赖关系
sudo systemctl stop 进程名			# 停止该进程