前言

再一次作妖，尝试在新买的一台 1核1g 服务器上安装 gitlab。本来是没那么大的胆子的，毕竟之前的一台服务器就因为这个原因挂了，然后不知道怎么解决，花了 2 千多冤枉钱去升级配置，浪费了资源和金钱，到现在 cpu 都一直空闲着 →_→ 。

这次因为是新买的测试机，在闲置了几个月后，陆续给它装了 php，mysql 和 Nginx。因为一直空闲着，平时只是用它来测试软件新版本和 php 框架的新特性，并且这次还找到了相关的服务器低配置的解决方案 gitlab安装教程。它通过给 Linux 扩展 swap 交换分区 的方式增加虚拟内存，从而达到 gitlab 安装最低配置的要求的。

一时兴奋手痒，就去尝试了一下。之后发现 swap 分区创建后，一直处于空闲状态。gitlab-ctl reconfigure 启动 gitlab，直接挂在那边了，没有反应。到了第二天去查看了一下，可能 gitlab 相关服务都开启了，服务器异常的卡顿，指令都输入不进去。多次尝试重启主机发现，每次开机后不久服务器运行良好，过一段时间就不行了。

没办法，借用之前总结的 完全卸载删除gitlab 教程，走了一遍，发现走到第 4 步杀死 ps aux | grep gitlab 的第一条进程这块走不下去了，因为每次杀死后 runsvdir 进程都会重新启动，然后就是依附于 runsvdir 的其他进程也杀不死。这在之前是没有遇到过的。

解决方法

阿里云提交工单以后，一开始提示我开通无性能约束，但这个模式我尝试开启过，没有用。工程师要了我服务器权限，但是没有登录进去，估计是时间久了，相关服务又把服务器搞得超负载了。他提示我杀死进程看看，我强制重启后，登录进去，发现 runsvdir 杀不死，他说要等他们那边后台工程师来检查，估计他也没辙了。

我闲着无聊，就用 kill -9 process_id 把所有 ps aux | grep gitlab 进程都杀死了一遍，没用。不断地杀死，它又不断地再次冒出来。百度，必应搜索 runsvdir 进程杀不死 相关的解决方案，根本没有，都在讲 第 4 步 通过 kill -9 xxx 杀死第一个 gitlab 相关的进程。

通过 top 和 ps 指令确定了 runsvdir 不是一个 zombie 僵尸进程，它处于 Ss 睡眠状态。那么就是有创建它的进程或者服务还在运行。ps -ef | grep process_id 查找 runsvdir 的父进程，没有找到，只看到一列的子进程。猜想是否是 gitlab 本身没有卸载掉（虽然进程里已经没有 gitlab 了）。

我之前卸载 gitlab 服务用的是 yum remove gitlab-ce，想到卸载指令还有另外一条 rpm -e gitlab-ce。虽然作用都一样：卸载 gitlab，但不死心，总要尝试一下的嘛，卸载指令这个时候又不会有什么严重后果。

执行完 rpm -e gitlab-ce，在用 ps aux | grep gitlab 查看 gitlab 相关进程，发现并没有作用。再次尝试杀死 runsvdir 进程 kill -9 xxx，竟然成功了！！！

总结

回想这次解决过程，不由感叹太幸运了，当然不放弃尝试各种方法也是最终解决问题的必要前提条件。

runsvdir 进程应该是与 gitlab 有联系的，通过 yum remove 指令没能够完全卸载掉 gitlab 是问题的所在。之后 rpm -e 完全卸载掉 gitlab ，使得 runsvdir 能够被杀死。