问题背景

最近因为gitlab服务器空间爆了，所以给服务器加装了一个新的大机械硬盘，因为之前的gitlab、opengrop的应用都是安装在/opt目录下的，所以为了减少重新安装配置的烦恼，想把新的硬盘直接挂载到/opt目录下，原来在/opt目录下的内容拷贝到其他地方再拷贝回来，这样重启后所有应用应该都是正常可以工作的。

理想很美好，现实很骨感。按上面的想法操作完后，其他服务都正常工作了，唯独gitlab服务器无法连接，提示“Whoops，GitLab is taking too much time to respond”

解决方案

 网上搜了一波文章，有内存不够的、端口冲突的，各种方案试了一波，最后都没有解决问题。不过对gitlab的分析有了一些了解，所以就准备用gitlab-ctl tail查看gitlab运行的log，看能不能查出具体的异常。

查看log，果然发现了一个比较可以的异常“Permission denied @ rb_sysopen - /opt/gitlab/var/puma/puma.pid (Errno::EACCES)”，这个是puma服务的异常log，通过gitlab-ctl status查看的时候也发现puma的进程一直在变，而其他进程的进程号是没有变的，侧面说明puma进程一直在重启

 查到了具体原因，离问题解决就不远了，看 Errno::EACCES这错误是读写失败，文件是存在的估计是权限问题，直接对/opt/gitlab/var/puma目录支持sudo chmod -R 777 /opt/gitlab/var/puma进行修改权限，然后执行gitlab-ctl restart进行重启后，连接gitlab服务成功。

注：产生权限问题原因，猜测是之前的目录用户不是root，但是我执行拷贝的时候是以root身份去执行的，所以最终拷贝会/opt目录下的gitlab用户组变了，而puma的执行是gitlab用户，没有权限去写root组的文件，改成777后，所有用户都有权限去读写了，所以权限问题解决。