文章目录
- 背景
- 排查
- 1、检查gitlab状态
- 2、运维终极杀器---重启大法
背景
最近公司系统重构，所以开发打包频繁,因为我们的gitlab-runner和gitlab服务器在一个机器上，所以产生了大量的artifacts和images，导致磁盘使用达到100%。然后另一个同事在没有细查情况下清空了/var/log/目录。导致gitlab服务器只能拉代码，无法push代码，而且不能登录gitlab，一直提示500和502.
排查
gitlab是使用yum 默认安装。版本：10.
1、检查gitlab状态
使用gitlab-ctl status命令查看gitlab各组件状态，发现各组件都是ok状态。初步认为是删除的空间不够，准备再清理一下空间，然后去清理artifacts文件(/var/opt/gitlab/gitlab-rails/shared/artifacts/),此处也可以在每个ci文件中添加expries_in指定产物过期时间。删除过后依然不能使用。
2、运维终极杀器—重启大法
经过第一步清理，发现没有什么作用，然后又去百度和谷歌搜索gitlab报500和502的解决办法。做了很多尝试，都没有解决，开发一直催促。最后没办法就只有祭出运维大杀器----重启。使用gitlab-ctl restart重启了gitlab。
在重启的时候，发现有几个组件提示：timeout。然后决定单独重启timeout的组件。发现这些组件有时候能重启，有时重启也提示：timeout。
查看gitlab日志：（-_-）,因为同事删除了/var/log/的信息，啥日志都看不到，只能在重启后查看gitlab启动日志：gitlab-ctl tail。日志里一直提示:/var/opt/gitlab/gitlab-workhorse/socket 拒绝访问。找到这个文件也不能把他咋样，又不敢删除。
然后就针对这些timeout的组件单独处理：
1)、查看组件状态,以sidekip为例gitlab-ctl status sidekip + ps -ef | grep sidekip 发现这个组件一直提示: /var/log/sidekip等一些列目录或者文件打不开，然后手动去创建目录和空文件。再重启组件就正常了。照着这个方式将所有有问题的组件都创建目录。然后发现所有组件都能正常启动。
2)、组件状态都是OK,也不超时依然报502
但是，访问gitlab时依然报502。开始怀疑是nginx的问题，排查了gitlab自带的nginx，发现也没有什么能看出的异常。然后又百度、谷歌，有博主说，遇到unicorn组件端口冲突会遇到502报错。unicorn默认是8080端口，使用netstat -nltp排查服务器上没有端口冲突。直接就麻了~~~
3)、死马当活马医
反正也没有别的办法，而且有一点和这个博主说的很相似的是，我的unicorn的进程号也在一直变大，说明unicorn在一直重启，那就试试，修改gitlab配置文件：
vim /etc/gitlab/gitlab.rb
....
unicorn['port'] = 8281
....
gitlab_workhorse['auth_backend'] = "http://localhost:8281"重启unicorn。
好了，居然奇迹般的好了，简直医学奇迹。
完结撒花，祝各位运维好运！
