Gitlab 502 ошибка whoops gitlab is taking too much time to respond

Теги: nginx, gitlab, гитлаб

Нередко пользователи сервиса GitLab сталкиваются с проблемой под названием «Ошибка 502». Как правило, она сопровождается следующей фразой: «Whoops, GitLab is taking too much time to respond». Давайте разберём, в чём может быть проблема.

Ошибку 502, как и вышеупомянутую фразу, вам показывает Nginx (компонент, входящий в GitLab). В общем случае речь идёт о том, что web-сервер не может получить от бэкенда ответ. А раз мы говорим о GitLab, то бэкендом здесь выступает Unix-сокет — /var/opt/gitlab/gitlab-workhorse/socket. Тут стоит упомянуть, что конфигурация Nginx для GitLab находится по адресу /var/opt/gitlab, а конкретно Nginx — здесь: /var/opt/gitlab/nginx/conf.

Почему же бэкенд не отвечает?

Ответить на этот вопрос со 100%-ной точностью нельзя. Но ряд причин всё же имеется:
1. У вас на сервере недостаточно оперативной памяти. Если памяти всего 2 Гб, ошибку 502 вы будете всё равно время от времени видеть, даже работая с GitLab в одиночку. Дело в том, что для работы таких компонентов, как Nginx, PostgreSQL, Redis и прочих требуется много памяти. В качестве решения проблемы можно увеличить либо включить swap.
2. У вас упала служба под названием GitLab-workhorse. Она открывает сокет, который слушает Nginx. А вот почему это произошло — вопрос отдельный. Не менее интересно и то, почему она функционирует, а сокета нет. Чтобы решить проблему, попробуйте просто перезагрузить сервер. Также бывает, что сервис падает из-за занятого порта какой-то службы, относящейся к GitLab. Это случается, если на сервере, кроме GitLab запущены другие службы. Ошибки могут быть и в конфигурации. Также нередко проблемы появляются после обновления.
3. Из-за каких-то причин изменились права доступа к сокету /var/opt/gitlab/gitlab-workhorse/socket, в результате чего Nginx не может получить доступ. Проверьте, от какого именно пользователя работает Nginx и удостоверьтесь, что у него достаточно прав для доступа к сокету.

Пожалуй, это основные причины возникновения ошибки 502 в GitLab, покрывающие большинство случаев.

Более подробно ознакомиться с архитектурой GitLab и освоить нюансы его работы вы можете на курсе CI/CD. Именно этой теме посвящено несколько занятий из первого модуля. Скачать программу курса можно здесь.

По материалам статьи «Установка и настройка Gitlab на Centos и Ubuntu».

502 Error GitLab is taking too much time to respond on Ubuntu 14.04

Hi, I have been trying to install Gitlab onto a fresh Ubuntu 14.04 VM by following the steps in the 2 minute guide.

Ran the following steps

sudo apt-get install curl openssh-server ca-certificates postfix

$ sudo gitlab-ctl status [sudo] password for loh: run: logrotate: (pid 86120) 2796s; run: log: (pid 12241) 67598s run: nginx: (pid 12228) 67600s; run: log: (pid 12227) 67600s run: postgresql: (pid 12129) 67654s; run: log: (pid 12128) 67654s run: redis: (pid 12010) 67666s; run: log: (pid 12009) 67666s run: sidekiq: (pid 12217) 67602s; run: log: (pid 12216) 67602s run: unicorn: (pid 12189) 67608s; run: log: (pid 12188) 67608s

For rake, all green except

GitLab Shell version >= 2.6.3 ? . OK (2.6.3) Repo base directory exists? . yes Repo base directory is a symlink? . no Repo base owned by git:git? . yes Repo base access is drwxrws—? . yes Satellites access is drwxr-x—? . yes hooks directories in repos are links: . can’t check, you have no projects Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: FAILED: Failed to connect to internal API gitlab-shell self-check failed Try fixing it: Make sure GitLab is running; Check the gitlab-shell configuration file: sudo -u git -H editor /opt/gitlab/embedded/service/gitlab-shell/config.yml Please fix the error above and rerun the checks.

GitLab user. git by default

Url to gitlab instance. Used for api calls. Should end with a slash.

Источник

Ошибка 502 в GitLab

Нередко пользователи сервиса GitLab сталкиваются с проблемой под названием «Ошибка 502». Как правило, она сопровождается следующей фразой: «Whoops, GitLab is taking too much time to respond». Давайте разберём, в чём может быть проблема.

Ошибку 502, как и вышеупомянутую фразу, вам показывает Nginx (компонент, входящий в GitLab). В общем случае речь идёт о том, что web-сервер не может получить от бэкенда ответ. А раз мы говорим о GitLab, то бэкендом здесь выступает Unix-сокет — /var/opt/gitlab/gitlab-workhorse/socket. Тут стоит упомянуть, что конфигурация Nginx для GitLab находится по адресу /var/opt/gitlab, а конкретно Nginx — здесь: /var/opt/gitlab/nginx/conf.

Почему же бэкенд не отвечает?

Ответить на этот вопрос со 100%-ной точностью нельзя. Но ряд причин всё же имеется: 1. У вас на сервере недостаточно оперативной памяти. Если памяти всего 2 Гб, ошибку 502 вы будете всё равно время от времени видеть, даже работая с GitLab в одиночку. Дело в том, что для работы таких компонентов, как Nginx, PostgreSQL, Redis и прочих требуется много памяти. В качестве решения проблемы можно увеличить либо включить swap. 2. У вас упала служба под названием GitLab-workhorse. Она открывает сокет, который слушает Nginx. А вот почему это произошло — вопрос отдельный. Не менее интересно и то, почему она функционирует, а сокета нет. Чтобы решить проблему, попробуйте просто перезагрузить сервер. Также бывает, что сервис падает из-за занятого порта какой-то службы, относящейся к GitLab. Это случается, если на сервере, кроме GitLab запущены другие службы. Ошибки могут быть и в конфигурации. Также нередко проблемы появляются после обновления. 3. Из-за каких-то причин изменились права доступа к сокету /var/opt/gitlab/gitlab-workhorse/socket, в результате чего Nginx не может получить доступ. Проверьте, от какого именно пользователя работает Nginx и удостоверьтесь, что у него достаточно прав для доступа к сокету.

Пожалуй, это основные причины возникновения ошибки 502 в GitLab, покрывающие большинство случаев.

Более подробно ознакомиться с архитектурой GitLab и освоить нюансы его работы вы можете на курсе CI/CD. Именно этой теме посвящено несколько занятий из первого модуля. Скачать программу курса можно здесь.

Источник

GitLab is taking too much time to respond. 502Error #1016

what might cause this problem?

I have restart docker and remove container both redis and postgres.

and refetch this image.Also change the port,but still got this error.

thanks for reply.

The text was updated successfully, but these errors were encountered:

How long does it stay like this? it’s «normal» to show this for a few minutes while the database and everything else get setup. (Running docker-compose logs -f gitlab might be insightful.)

2016-12-13 05:29:55,645 INFO exited: unicorn (exit status 1; not expected)
2016-12-13 05:29:56,660 INFO spawned: ‘unicorn’ with pid 654
2016-12-13 05:29:57,661 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

WARNING: This version of GitLab depends on gitlab-shell 4.0.3, but you’re running 4.0.0. Please update gitlab-shell.

I found some log here.

I think you should fire up bash for your gitlab container and check the logs for unicorn .
It’s constantly exiting and spawning right?

yes,it might be the problem of the image itself.

You should try attach to the bash shell of your gitlab container and checkout the unicorn logs.

When you’re attached via bash check out the files in log directory.
I see that I have two files for unicorn: unicorn.stderr.log and unicorn.stdout.log

I have the same issue and the following in the unicorn.stderr.log :

worker=0 I, [2016-12-15T13:53:07.435196 #22795] INFO — : worker=0 ready E, [2016-12-15T13:53:09.416083 #495] ERROR — : worker=1 PID:22344 timeout (61s > 60s), killing E, [2016-12-15T13:53:09.455313 #495] ERROR — : reaped #

worker=1 I, [2016-12-15T13:53:09.646793 #22819] INFO — : worker=1 ready E, [2016-12-15T13:54:08.681832 #495] ERROR — : worker=0 PID:22795 timeout (61s > 60s), killing E, [2016-12-15T13:54:08.710320 #495] ERROR — : reaped #

worker=0 I, [2016-12-15T13:54:08.772777 #23285] INFO — : worker=0 ready E, [2016-12-15T13:54:10.812807 #495] ERROR — : worker=1 PID:22819 timeout (61s > 60s), killing E, [2016-12-15T13:54:10.889341 #495] ERROR — : reaped #

worker=1 I, [2016-12-15T13:54:10.925535 #23302] INFO — : worker=1 ready E, [2016-12-15T13:55:10.133465 #495] ERROR — : worker=0 PID:23285 timeout (61s > 60s), killing E, [2016-12-15T13:55:10.194133 #495] ERROR — : reaped #

worker=0 E, [2016-12-15T13:55:11.239516 #495] ERROR — : worker=1 PID:23302 timeout (61s > 60s), killing E, [2016-12-15T13:55:11.616705 #495] ERROR — : reaped #

worker=1 I, [2016-12-15T13:55:12.006857 #23766] INFO — : worker=0 ready I, [2016-12-15T13:55:12.025994 #23782] INFO — : worker=1 ready E, [2016-12-15T13:56:13.714402 #495] ERROR — : worker=0 PID:23766 timeout (62s > 60s), killing E, [2016-12-15T13:56:13.729221 #495] ERROR — : worker=1 PID:23782 timeout (61s > 60s), killing E, [2016-12-15T13:56:13.973930 #495] ERROR — : reaped #

worker=0 E, [2016-12-15T13:56:14.581461 #495] ERROR — : worker=1 PID:23782 timeout (61s > 60s), killing E, [2016-12-15T13:56:15.982136 #495] ERROR — : reaped #

worker=1 I, [2016-12-15T13:56:17.890595 #24390] INFO — : worker=0 ready I, [2016-12-15T13:56:17.961203 #24396] INFO — : worker=1 ready «>

Guys, I just ran into the same issue;
My Synology system (the host machine running the gitlab containers) met an unexpected power failure.
I don’t have the logs no more, but unicorn was dying and respawning every second or so.
The logs told me that the pid in /home/git/gitlab/tmp/pids/unicorn.pid was stale.
I checked the pid value in the log and checked if there was a running process with the same pid, and no there was none.

I’m guessing this is because of the unexpected powerdown, and unicorn.pid was not properly cleared.

My solution was simple

Same issue here (the gitlab is working and after some time hangs with 502 err), but im sure that host machine didn’t have unexpected powerdowns. The log looks similar as @alex3305 log.

@iamchanghyunpark Same problem with my Synology, cleared the bad pid from /home/git/gitlab/tmp/pids/unicorn.pid and restarted container, all is well. It seems that Synology does not cleanly shutdown the running containers.

Checking the status by running:

Turns out, the GitLab service was not running at all.
The solution was then to just restart the service with:

Just make sure, that you had open proper port on your router. In my case it was the problem.

I came to this issue when there is no shared memory. 502 Gitlab is taking too much time to respond

This issue has been automatically marked as stale because it has not had any activity for the last 60 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.

Источник

Как донастроить GitLab, установленный на собственный сервер, чтобы не выдавал ошибку 502 при попытке клонировать проект?

Ставлю GitLab на свой сайт, в поддомен, за своим собственным nginx, проблема в том, что не могу клонировать проект из GitLab’а, выдает ошибку 502.

Подробнее:
VPS, чистая Ubunta 18.04 LTS, 2 ядра, ОЗУ 4 Гб, диск 25 Гб;
1. ставлю nginx, потом Passenger (без Passenger не удастся переключить GitLab со встроенного на внешний nginx);
2. ставлю GitLab в поддомен;
3. отключаю nginx, встроенный в GitLab, переключаюсь на внешний nginx.

Все три пункта делаю в соответствии с документацией на GitLab.

Сразу после этого GitLab не работает, по логам нахожу ошибки, добавляю:
даю права пользователю git на /var/opt/gitlab;
инсталлирую ruby-dev && nodejs.

После этого в поддомене появляется GitLab, определяю пароль администратора, в целом web-версия выглядит рабочей.

Но — не могу клонировать проект из GitLab’а, выдает ошибку 502:
$ git clone https://git.tradercad.com/root/tock.git
Cloning into ‘tock’.
remote: GitLab is not responding
fatal: unable to access ‘https://git.tradercad.com/root/tock.git/’: The requested URL returned error: 502

Что странно, при запросе git clone в логах встроенного nginx по адресу var/log/gitlab/nginx/gitlab_access.log появляется запись:
81.30.208.16 — — [03/May/2021:13:51:42 +0300] «GET /root/tock.git/info/refs?service=git-upload-pack HTTP/1.1» 502 24 «-» «git/2.29.2.windows.2»

и при открытии в браузере страницы git.tradercad.com var/log/gitlab/nginx/gitlab_access.log появляется запись:
81.30.208.16 — — [03/May/2021:13:56:02 +0300] «GET /users/sign_in HTTP/1.1» 200 15487 «-» «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36»

в то время как в логах «нормального» nginx по адресу var/log/nginx/access.log и var/log/nginx/error.log ничего, пусто.

Может быть, nginx, встроенный в GitLab, отключен не до конца?

Источник

Русские Блоги

GitLab: 502 решено

Вышеупомянутая замечательная проблема заключается в том, что после конфигурации есть проблема, и вы не можете получить доступ к GitLab. Вы можете получить доступ к нему после перезагрузки. В то время проблем не было. Но в последнее время эта проблема часто видна. Так что здесь, чтобы решить это.

Возможность

Текст обычно упоминается в сервисе Unicorn и конфликт порта Tomcat, а Unicorn использует порт должен быть [этот порт »GitLab: Простая установка принадлежит к вашему собственному серверу GitLab«Вот, я упомянул, что это 8080, я не знаю, заметил ли вы это.

Установите порт (задайте себе нужный порт):

очередной раз gitlab-ctl reconfigure Перезапустите конфигурацию, чтобы сервер GitLab может работать нормально.

Возможные два

И на этот раз я столкнулся не в этой проблеме, я изменил порт, используемый Unicorn, и перезапуск имеет несколько раз, но все же 502.

Просмотр статуса GitLab

$gitlab-ctl status gitlab run: gitlab-workhorse: (pid 18179) 99s; down : 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 run: gitlab-workhorse: (pid 18179) 99s; down : 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 находится в состоянии вниз.

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»

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 не может получить доступ (Примечание: запрещено много разрешений: Посмотрите, есть ли какой-нибудь файл

$ll /var/opt/gitlab/gitlab-workhorse/socket srwxrwxrwx 1 git git 0 Mar 21 12:17 /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 http://localhost:8080 -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 http://localhost:8080 -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: warning: 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

# 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 http://localhost:8080 -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 http://localhost:8080 -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: warning: 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 портов, а не порт, который мы используем перед использованием единорога. Начните с обслуживанием GitLab, убить процесс 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, просмотрите процессы и делайте суждения.

Источник

I. false information

Two. Troubleshooting process

1. Start unicorn without listening to port.

Log path: /var/log/gitlab/unicorn/unicorn_stderr.log

PG::ConnectionBad: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?

  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `initialize'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `new'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in `connect'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:242:in `initialize'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:44:in `new'
  /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/activerecord-4.2.10/lib/active_record/connection_adapters/postgresql_adapter.rb:44:in `postgresql_connection'

··· ···
··· ···

The message is displayed because you can’t connect to the PG, so it’s normal to restart after starting postgresql (well, that’s it).

2,postgresql down

down: postgresql: 0s, normally up, want up; run: log: (pid 623) 15816094s

Through PG’s log path: /var/log/gitlab/postgresql/current, you can see the following information

2018-11-01_08:18:09.49669 FATAL:  could not map anonymous shared memory: Cannot allocate memory
2018-11-01_08:18:09.49671 HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4292984832 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2018-11-01_08:18:09.49671 LOG:  database system is shut down

You can also get the same information by commanding `gitlab-ctl tail postgresql’, so you can determine the problem.

This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4292984832 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2018-11-01_07:52:06.63024 LOG:  database system is shut down

In the configuration file, the shared_buffers and max_connections of postgresql are restricted.

[root@V2 ~]# cat /etc/gitlab/gitlab.rb |grep -v ^$ |grep -v ^#
external_url 'http://xxx.xxx.xxx.xxx.xxx:8090'
unicorn['worker_timeout'] = 60
unicorn['worker_processes'] = 3
unicorn['listen'] = 'xxx.xxx.xxx.xxx.xxx'
unicorn['port'] = 8870
postgresql['enable'] = true
postgresql['data_dir'] = "/var/opt/gitlab/postgresql/data"
postgresql['shared_buffers'] = "256MB"   # ! **recommend value is 1/4 of total RAM, up to 14GB.**      
postgresql['max_connections'] = 200
nginx['listen_addresses'] = ['*']
nginx['listen_port'] = 8090

The configuration is completed and saved, then the configuration is updated, and the application is restarted.

gitlab-ctl reconfigure   # Update configuration
gitlab-ctl restart       # restart app
gitlab-ctl status        # View service status

Reference material:

1. 502-Whoops, GitLab is taking too much time to respond

2. Postgresql down

3. HTTP 502: Whoops, GitLab is taking too much time to respond. Even after Server restart

Posted by myblue
in Operation & Maintenance
at Nov 04, 2018 — 7:08 PM

I have the same issue and the following in the unicorn.stderr.log:

I, [2016-12-15T13:52:08.252151 #22344]  INFO -- : worker=1 ready                                                
E, [2016-12-15T13:53:07.295769 #495] ERROR -- : worker=0 PID:22321 timeout (61s > 60s), killing                 
E, [2016-12-15T13:53:07.329132 #495] ERROR -- : reaped #<Process::Status: pid 22321 SIGKILL (signal 9)> worker=0
I, [2016-12-15T13:53:07.435196 #22795]  INFO -- : worker=0 ready                                                
E, [2016-12-15T13:53:09.416083 #495] ERROR -- : worker=1 PID:22344 timeout (61s > 60s), killing                 
E, [2016-12-15T13:53:09.455313 #495] ERROR -- : reaped #<Process::Status: pid 22344 SIGKILL (signal 9)> worker=1
I, [2016-12-15T13:53:09.646793 #22819]  INFO -- : worker=1 ready                                                
E, [2016-12-15T13:54:08.681832 #495] ERROR -- : worker=0 PID:22795 timeout (61s > 60s), killing                 
E, [2016-12-15T13:54:08.710320 #495] ERROR -- : reaped #<Process::Status: pid 22795 SIGKILL (signal 9)> worker=0
I, [2016-12-15T13:54:08.772777 #23285]  INFO -- : worker=0 ready                                                
E, [2016-12-15T13:54:10.812807 #495] ERROR -- : worker=1 PID:22819 timeout (61s > 60s), killing                 
E, [2016-12-15T13:54:10.889341 #495] ERROR -- : reaped #<Process::Status: pid 22819 SIGKILL (signal 9)> worker=1
I, [2016-12-15T13:54:10.925535 #23302]  INFO -- : worker=1 ready                                                
E, [2016-12-15T13:55:10.133465 #495] ERROR -- : worker=0 PID:23285 timeout (61s > 60s), killing                 
E, [2016-12-15T13:55:10.194133 #495] ERROR -- : reaped #<Process::Status: pid 23285 SIGKILL (signal 9)> worker=0
E, [2016-12-15T13:55:11.239516 #495] ERROR -- : worker=1 PID:23302 timeout (61s > 60s), killing                 
E, [2016-12-15T13:55:11.616705 #495] ERROR -- : reaped #<Process::Status: pid 23302 SIGKILL (signal 9)> worker=1
I, [2016-12-15T13:55:12.006857 #23766]  INFO -- : worker=0 ready                                                
I, [2016-12-15T13:55:12.025994 #23782]  INFO -- : worker=1 ready                                                
E, [2016-12-15T13:56:13.714402 #495] ERROR -- : worker=0 PID:23766 timeout (62s > 60s), killing                 
E, [2016-12-15T13:56:13.729221 #495] ERROR -- : worker=1 PID:23782 timeout (61s > 60s), killing                 
E, [2016-12-15T13:56:13.973930 #495] ERROR -- : reaped #<Process::Status: pid 23766 SIGKILL (signal 9)> worker=0
E, [2016-12-15T13:56:14.581461 #495] ERROR -- : worker=1 PID:23782 timeout (61s > 60s), killing                 
E, [2016-12-15T13:56:15.982136 #495] ERROR -- : reaped #<Process::Status: pid 23782 SIGKILL (signal 9)> worker=1
I, [2016-12-15T13:56:17.890595 #24390]  INFO -- : worker=0 ready                                                
I, [2016-12-15T13:56:17.961203 #24396]  INFO -- : worker=1 ready                                                

etc etc…

FATAL: Errono::EAFNOSUPPORT: Address family not supported by protocol - socket(2)

11 Answers

# gitlab-ctl stop

# vi /etc/gitlab/gitlab.rb   (change only these lines, uncomment if required)
unicorn['port'] = 8081
gitlab_git_http_server['auth_backend'] = "http://localhost:8081"

# gitlab-ctl reconfigure  (to apply the changes)
# gitlab-ctl restart
# lsof -i:8081        (check whether unicorn has started properly)

unicorn['worker_processes'] = 3
unicorn['worker_timeout'] = 120 # or any suitable timeout for your server

nginx['listen_port'] = 8081
unicorn['port'] = 8082 #the ports should be different

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart