前文提到過一個奇葩的問題，就是配置好後，出現了問題，不能訪問gitlab，重啟後才可以訪問，當時並不認為有問題。但最近發現配置後，這個問題時常出現。所以這裡要解決下。

可能性一

文中大致提到是unicorn服務與tomcat埠衝突，配置下unicorn使用埠應該就可以了[這個埠在《GitLab之：簡單安裝屬於自己的一個GitLab伺服器》這裡特意提到過是8080，不知道你注意到了沒]

設定埠（設定自己合適的埠即可）的方法：

unicorn['port'] = 9090

再gitlab-ctl reconfigure

可能性二

而這次遇到的明顯不是這個問題，已經修改了unicorn使用的埠，restart了多次，但是依然是502。

查看了下gitlab的狀態

$gitlab-ctl status gitlab run: gitlab-workhorse: (pid 18179) 99s; <span style="color: #ff0000;"><strong>down</strong></span>: log: 0s, normally up, want up run: logrotate: (pid 41667) 2739s; run: log: (pid 1437) 708348s run: postgresql: (pid 1453) 708348s; run: log: (pid 1436) 708348s run: sidekiq: (pid 1450) 708348s; run: log: (pid 1438) 708348s run: unicorn: (pid 1452) 708348s; run: log: (pid 1435) 708348s

看到沒gitlab-workhorse中處於down狀態。

502嗎，是nginx返回的錯誤，那我們在看下nginx的錯誤日誌：

2017/03/22 10:36:23 [error] 19487#0: *358778 connect() to unix:/var/opt/gitlab/gitlab-workhorse/socket failed (111: Connection refused) while connecting to upstream, client: 117.100.247.144, server: demo.nideyuan.com, request: "GET / HTTP/1.1", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/socket:/", host: "demo.nideyuan.com" 2017/03/22 10:36:23 [error] 19487#0: *358778 connect() to unix:/var/opt/gitlab/gitlab-workhorse/socket failed (111: Connection refused) while connecting to upstream, client: 117.100.247.144, server: demo.nideyuan.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/socket:/favicon.ico", host: "demo.nideyuan.com"

可以確定gitlab-workhorse出問題了，日誌中說是/var/opt/gitlab/gitlab-workhorse/socket無法訪問（注意：有遇到Permission denied-的比較多，自行解決吧）。看下是否存在有該檔案

$ll /var/opt/gitlab/gitlab-workhorse/socket srwxrwxrwx 1 git git 0 Mar 21 12:17 /var/opt/gitlab/gitlab-workhorse/socket

存在且許可權沒有問題。這如何是好？有看了下有關gitlab-workhorse的程序

# ps -ef |grep workhorse git 18179 31313 0 09:38 ? 00:00:00 /opt/gitlab/embedded/bin/gitlab-workhorse -listenNetwork unix -listenUmask 0 -listenAddr /var/opt/gitlab/gitlab-workhorse/socket -authBackend <span style="color: #ff0000;">http://localhost:8080</span> -authSocket /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket -documentRoot /opt/gitlab/embedded/service/gitlab-rails/public -pprofListenAddr root 19063 18927 0 09:43 pts/2 00:00:00 grep workhorse root 23287 1 0 Mar21 ? 00:00:00 svlogd -tt /var/log/gitlab/gitlab-workhorse git 27842 1 0 Mar21 ? 00:00:00 /opt/gitlab/embedded/bin/gitlab-workhorse -listenNetwork unix -listenUmask 0 -listenAddr /var/opt/gitlab/gitlab-workhorse/socket -authBackend <span style="color: #ff0000;">http://localhost:8080</span> -authSocket /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket -documentRoot /opt/gitlab/embedded/service/gitlab-rails/public -pprofListenAddr root 31311 1 0 Mar21 ? 00:00:22 runsvdir -P /opt/gitlab/service log: ock directory: /var/log/gitlab/gitlab-workhorse: temporary failure?svlogd: fatal: no functional log directories.?svlogd: <span style="color: #ff0000;">warning:</span> unable to lock directory: /var/log/gitlab/gitlab-workhorse: temporary failure?svlogd: fatal: no functional log directories.?svlogd: warning: unable to lock directory: /var/log/gitlab/gitlab-workhorse: temporary failure?svlogd: fatal: no functional log directories.? root 31313 31311 0 Mar21 ? 00:00:57 runsv gitlab-workhorse

暈倒，怎麼又兩個一樣的gitlab-workhorse的程序，且含有8080埠，不就是我們開始改之前unicorn使用的埠嘛。先停到gitlab服務，kill掉gitlab-workhorse的程序

#gitlab-ctl stop # kill -9 27842

我們再檢查下gitlab的配置檔案（/etc/gitlab/gitlab.rb ），看其中是否還有與8080埠有關的配置

果然還有

# gitlab_workhorse['auth_backend'] = "http://localhost:8080" #ä¿®æ¹ä¸º gitlab_workhorse['auth_backend'] = "http://localhost:9090"

再gitlab-ctl reconfigure 重啟配置，這樣GitLab伺服器就可以正常運行了。

整體思路：檢查gitlab的狀態，檢視nginx日誌，檢視程序狀態，在做判斷。