Ubuntu gitlab 502 error

I have just installed GitLab on a fresh Ubuntu 14.04 64 bit server. I did so using the Omnibus package as indicated in the download page. There were no error messages during the install and all the

I have just installed GitLab on a fresh Ubuntu 14.04 64 bit server. I did so using the Omnibus package as indicated in the download page. There were no error messages during the install and all the remarks from the script were displayed in green.

When I access the server through port 80 I get the following:

enter image description here

Following the Trouble Shooting Guide I tried to query the status, but the result is also an error:

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
sudo: bundle: command not found

I tried to access the logs but the unicorn.stderr.log file is nowhere to be found in the system.

There is a similar question with the same error on Ubuntu 12.04, to which the solution is to increase the unicorn timeout. I have tried to do so but the error message remains.

Community's user avatar

asked Jan 7, 2015 at 9:21

Luís de Sousa's user avatar

Luís de SousaLuís de Sousa

5,30810 gold badges46 silver badges82 bronze badges

There is a lag of some 5 minutes from the moment gitlab is started/restarted to the point when it is actually able to process requests. Here is an example from the log:

2015-01-08_09:00:57.37719 [13326] 08 Jan 10:00:57.377 * The server is now ready to accept connections on port 0
2015-01-08_09:00:57.37722 [13326] 08 Jan 10:00:57.377 * The server is now ready to accept connections at /var/opt/gitlab/redis/redis.socket

[...]

==> /var/log/gitlab/unicorn/unicorn_stderr.log <==
I, [2015-01-08T10:04:48.676879 #13351]  INFO -- : listening on addr=127.0.0.1:8080 fd=11
I, [2015-01-08T10:04:48.677663 #13351]  INFO -- : unlinking existing socket=/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket
I, [2015-01-08T10:04:48.690283 #13351]  INFO -- : listening on addr=/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket fd=12
I, [2015-01-08T10:04:48.716769 #13413]  INFO -- : worker=0 spawned pid=13413
I, [2015-01-08T10:04:48.735878 #13351]  INFO -- : master process ready
I, [2015-01-08T10:04:48.846635 #13416]  INFO -- : worker=1 spawned pid=13416
I, [2015-01-08T10:04:48.837438 #13413]  INFO -- : worker=0 ready
I, [2015-01-08T10:04:48.863110 #13416]  INFO -- : worker=1 ready

Before Unicorn reports that it is up and running on port 8080, the «GitLab is not responding» message will be displayed. So all one has to do is wait.

answered Jan 8, 2015 at 9:12

Luís de Sousa's user avatar

Luís de SousaLuís de Sousa

5,30810 gold badges46 silver badges82 bronze badges

9

I have met the similar problem as I have installed GitLab EE on CentOS 7.5 64 bit server in the year of the end of 2018.

enter image description here

The most important thing you must pay attention to is Make sure your server is under the minimum requirements of performance!

In the official documentation of GitLab,your server must be at least 2 cores and 8GB RAM.

enter image description here

If your server is less than 2 cores and 8GB RAM.You can have a try to make a Swap to get more memories,and then reconfigure and restart your GitLab.If you still have this kind of situation,so pay attention to another big and terrible problem about first start of Gitlab:

It may take a long time,maybe some minutes to load the first page after GitLab installation as the above answer saied!

«GitLab is not responding.» 502 on Ubuntu 14.04 after starting server

Note:If you have a server with lower performance such as: 1 core & 1GB RAM,it will be 502 at most time,even if you try to make the Swap to 8GB RAM,it’s not working,the only way you can do is to make the performance of the server more than 2 cores & 8GB RAM minimum.

Some other methods for you to find more detail useful information:

  • We can use gitlab-ctl tail to get the detail information and then copy the log and find the key words such as warning,failed and so on.

  • You can go to the sub-directory of /var/log/gitlab to find the log to get some information.

answered Nov 15, 2018 at 3:27

ifeegoo's user avatar

If it is showing 502 bad gateway try running the following command from your gitlab server.

sudo service gitlab-runsvdir start

If you are facing 504. Restart the server from the AWS/ GCP.

answered Mar 4, 2021 at 7:44

Mehar Rahim's user avatar

Источник

Теги: 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».

Источник

Содержание

  1. 502 Error GitLab is taking too much time to respond on Ubuntu 14.04
  2. GitLab user. git by default
  3. Url to gitlab instance. Used for api calls. Should end with a slash.
  4. Ошибка 502 в GitLab
  5. Почему же бэкенд не отвечает?
  6. GitLab is taking too much time to respond. 502Error #1016
  7. Comments
  8. Как донастроить GitLab, установленный на собственный сервер, чтобы не выдавал ошибку 502 при попытке клонировать проект?
  9. Русские Блоги
  10. GitLab: 502 решено
  11. Возможность
  12. Возможные два

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, просмотрите процессы и делайте суждения.

Источник

Источник

GitLab was configured on Ali Cloud today, but the error 502 error kept coming up.

502
GitLab is not responding.
Please contact your GitLab administrator if this problem persists.


After searching for one afternoon, a mistake was finally found. It turned out that a Tomcat service was opened on the server and occupied port 8080, which made the Unicorn service of GitLab unable to be opened.
is finally modified as follows in /etc/gitlab/gitlab.rb

unicorn['port'] = 9090

Then gitlab-ctl reconfigure restart the configuration so that the gitlab server is up and running.

Here, write down the general process of solving the problem, and count it as a good experience for yourself.
install GitLab, start service, 502 error found. This is the beginning of the search for solutions to various Baidu.
1. Find the /var/log/gitlab/nginx in the error log file, found the following error /var/opt/gitlab/gitlab - rails/sockets/gitlab socket failed (2: No such file or directory), and then use the nc command to create the socket file, the final permission is set to SRWXRWXRWX , users and groups are set to git:git, but found that this method does not work.
2. When I ran to the GitLab website to find a solution, https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
CTRL + f 502 find the official tutorial says 502 problems

Note that on a single-core server it may take up to a minute to restart Unicorn and Sidekiq. Your GitLab instance will give a 502 error until Unicorn is up again.
It is also possible to start, stop or restart individual components.
sudo gitlab-ctl restart sidekiq
Unicorn supports zero-downtime reloads. These can be triggered as follows:
sudo gitlab-ctl hup unicorn
Note that you cannot use a Unicorn reload to update the Ruby runtime.

Try using the above two commands and find that it doesn't work. When I got angry, I kept typing gitlab-ctl status until I found that unicorn pid was getting bigger all the time. The PID for the other services has not changed.
3. Now we've almost found the problem -- unicorn's question. For the official tutorial, you can use gitlab-ctl tail unicorn to track the unicorn's status. Unfortunately, when we discovered that port 8080 was occupied, the unicorn's status was reported to have been captured

E, [2015-02-11T17:27:57.818492 #26687] ERROR -- : adding listener failed addr=127.0.0.1:8080 (in use)
E, [2015-02-11T17:27:57.818621 #26687] ERROR -- : retrying in 0.5 seconds (4 tries left)
E, [2015-02-11T17:27:58.318902 #26687] ERROR -- : adding listener failed addr=127.0.0.1:8080 (in use)
E, [2015-02-11T17:27:58.318998 #26687] ERROR -- : retrying in 0.5 seconds (3 tries left)
E, [2015-02-11T17:27:58.819309 #26687] ERROR -- : adding listener failed addr=127.0.0.1:8080 (in use)
E, [2015-02-11T17:27:58.819423 #26687] ERROR -- : retrying in 0.5 seconds (2 tries left)
E, [2015-02-11T17:27:59.319954 #26687] ERROR -- : adding listener failed addr=127.0.0.1:8080 (in use)
E, [2015-02-11T17:27:59.320076 #26687] ERROR -- : retrying in 0.5 seconds (1 tries left)

4. Well, here's the problem. The choice then became whether to kill the original 8080 port service or to change the unicorn port. This depends on your specific needs. I've changed the unicorn port to 9090, and the method is the one described at the beginning.

Read More:

  • About the problem I encountered: 226 transfer done but failed to open directory
  • Gitlab service migration and gitlab administrator password retrieval
  • To solve this problem, we can’t find the solution of / storage / emulated / 0 / file. I can’t. You can try this
  • There are three ways to deal with the problem of vs (Visual Studio) 2017 flashback. I feel that none of them is the fundamental solution.
  • I encountered a compilation error twice: crosses initialization of…
  • Solving environment: failed solution to the problem encountered when updating Anaconda
  • BarTender operation encountered the problem of “OLE DB encountered error 0x80004005”
  • The first time I write OpenGL program, what should I do when I encounter “can’t open include file:” GL / glaux. H “: no such file or directory”?
  • [unity problem] what should I do if I encounter ‘Global::’ already contains a definition
  • MSDN I tell you new site next I tell you open invitation code registration! Today’s quota is 5000!
  • [email protected] invalid privatekey
  • GitLab You are not allowed to push code to this project
  • The problem encountered in pyinstaller packaging “failed to execute script × *”
  • Using pop-up window and I18N, error in render: “typeerror: cannot read property” appears_ T ‘of undefined’ solution
  • windows GitLab: PTY allocation request failed on channel 0
  • DB2 encountered the problem of sqlcode = 911 lock table when updating record update
  • Docker encountered a problem 4: yaml: Line 1: mapping values are not allowed in this context
  • Raspberry pie 4B uses adafruit_ Pca9685 report error ioerror: [errno 121] remote I / O error solution
  • In thinkphp5, we encountered the problem of class’ phpoffice / phpspredsheet / spreadsheet ‘not found
  • Solve the problem of error loading MySQL DB module. Encountered during Django project

Источник

I’m trying to install GitLab on an Ubuntu 20.04.4 LTS server running from an Antsle Nano device. The server already had Nginx, PostgreSQL, and Postfix installed as a part of iRedMail, so I’m working on setting GitLab up to use those resources. All the existing sites on my Nginx server still appear to be working normally (e.g, webmail.mydomain.com, wiki.mydomain.com — a Wiki.Js installation — and www.mydomain.com), but when I try to access my GitLab install through the browser (gitlab.mydomain.com), I get a 502 Bad Gateway response.

I’ve followed the instructions for using a non-bundled web server and disabled the bundled Nginx server (and the bundled PostgreSQL server as well) in the gitlab.rb. Then I added the server information to the Nginx sites-enabled configuration file according to the GitLab recipe. I installed an SSL certificate from Let’s Encrypt for that specific subdomain that’s showing to be valid when I go to the site.

I’m sure I’m just «overlooking» something here, but I’ll readily admit that I’m not terribly familiar with *nix environments in general or Nginx in particular. Here are the uncommented sections of my gitlab.rb file (redacted):

external_url 'https://gitlab.mydomain.com'

postgresql['enable'] = false

gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
gitlab_rails['db_username'] = 'USERNAME'
gitlab_rails['db_password'] = 'PASSWORD'
gitlab_rails['db_host'] = '127.0.0.1'
gitlab_rails['db_port'] = 5432

web_server['external_users'] = ['www-data']

nginx['enable'] = false
nginx['ssl_prefer_server_ciphers'] = "off"

Everything else in the file is commented out.

For the sake of completeness, here are the conf settings for GitLab in my Nginx sites-enabled (redacted)

upstream gitlab-workhorse {
  # On GitLab versions before 13.5, the location is
  # `/var/opt/gitlab/gitlab-workhorse/socket`. Change the following line
  # accordingly.
  server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ipv6only=on ssl;
    server_name gitlab.mydomain.com;
    server_tokens off;

    root /opt/gitlab/embedded/service/gitlab-rails/public;

    # GitLab needs backwards compatible ciphers to retain compatibility with Java IDEs
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;

    ## Individual nginx logs for this GitLab vhost
    access_log  /var/log/nginx/gitlab_access.log;
    error_log   /var/log/nginx/gitlab_error.log;

    location / {
        client_max_body_size 0;
        gzip off;

        ## https://github.com/gitlabhq/gitlabhq/issues/694
        ## Some requests take more than 30 seconds.
        proxy_read_timeout 300;
        proxy_connect_timeout 300;
        proxy_redirect off;

        proxy_http_version 1.1;

        proxy_set_header    Host                $http_host;
        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-Ssl     on;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto   $scheme;
        proxy_pass http://gitlab-workhorse;
    }

    location ~ /.well-known/acme-challenge {
        root /var/www/ssl/;
        allow all;
    }

    ssl_certificate /etc/letsencrypt/live/gitlab.mydomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/gitlab.mydomain.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/gitlab.mydomain.com/chain.pem;
}

The PostgreSQL appears to be set up correctly — I was able to run the gitlab-rake gitlab:setup and the gitlabhq_production database exists on that server with its various schemata and tables.

As I said, I’m probably simply doing something wrong, but I’m just not sure what. I thought about removing the proxy stuff from the conf since that’s about all I can think of that could be causing the Bad Gateway response, but that would remove the workhorse part, which I believe is important. Otherwise, everything else seems pretty much essential there.

It’s certainly possible that I need to tweak the gitlab.rb some more, but I’ve tried to look through there a few times for anything that looks promising without luck. If anyone has any insight into what I’m missing here, I’d be grateful.

EDIT:

additional information about my own troubleshooting
I’ve tested the Nginx conf file and restarted that server:

nginx -t
systemctl reload nginx.service
systemctl restart nginx

I’ve run gitlab-ctl reconfigure multiple times as I’ve made adjustments to the gitlab.rb. I just remembered that there have been some «issues» that have come up as a part of those which are probably at least partially to blame:

Mixlib::ShellOut::CommandTimeout: ruby_block[authorize Grafana with GitLab] (monitoring::grafana line 101) had an error: Mixlib::ShellOut::CommandTimeout: Command timed out after 600s:
Command exceeded allowed execution time, process terminated

followed by a lot of StackTrace information (which I can provide if it will help)

EDIT #2:

Per comment, I tried to make sure that the GitLab service(s) are running:

sudo gitlab-ctl start
ok: run: alertmanager: (pid 29660) 51764s
ok: run: gitaly: (pid 26686) 58352s
ok: run: gitlab-exporter: (pid 3223) 46573s
ok: run: gitlab-kas: (pid 26650) 58367s
ok: run: gitlab-workhorse: (pid 29598) 51780s
ok: run: logrotate: (pid 9914) 864s
ok: run: node-exporter: (pid 29608) 51779s
ok: run: prometheus: (pid 29626) 51776s
ok: run: puma: (pid 2698) 47257s
ok: run: redis: (pid 26145) 58729s
ok: run: redis-exporter: (pid 29619) 51777s
ok: run: sidekiq: (pid 2535) 47368s

As far as I can tell with my limited understanding, that looks like it should be «good-to-go», but I’m still getting the Bad Gateway response from my browsers. It doesn’t show those services when I check ls /etc/init.d, but I assume that everything should be correct.

Источник

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…

Источник

Hey there,

I am a total linux (and git(lab)) noob and am trying to setup GitLab on an Ubuntu 16.04.5 LTS Server, but I always get the error message 502.

Wenn I check the running services, gitlab and unicorn are marked with a [-], which probably means, they are not running? I am not sure if gitlab isn’t running, because unicorn isn’t or if there is another problem. When I check unicorn logfile (unicorn_stderr.log) it states the following all the time:

ERROR -- : listen loop error: Invalid argument - accept (Errno::EINVAL)
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/unicorn-5.1.0/lib/unicorn/http_server.rb:657:in `kgio_tryaccept'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/unicorn-5.1.0/lib/unicorn/http_server.rb:657:in `worker_loop'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/unicorn-5.1.0/lib/unicorn/http_server.rb:508:in `spawn_missing_workers'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/unicorn-5.1.0/lib/unicorn/http_server.rb:132:in `start'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/unicorn-5.1.0/bin/unicorn:126:in `<top (required)>'
ERROR -- : /opt/gitlab/embedded/bin/unicorn:23:in `load'
ERROR -- : /opt/gitlab/embedded/bin/unicorn:23:in `<top (required)>'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/cli/exec.rb:74:in `load'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/cli/exec.rb:74:in `kernel_load'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/cli/exec.rb:28:in `run'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/cli.rb:424:in `exec'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/cli.rb:27:in `dispatch'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/cli.rb:18:in `start'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/exe/bundle:30:in `block in <top (required)>'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
ERROR -- : /opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/bundler-1.16.2/exe/bundle:22:in `<top (required)>'
ERROR -- : /opt/gitlab/embedded/bin/bundle:23:in `load'
ERROR -- : /opt/gitlab/embedded/bin/bundle:23:in `<main>'

I don’t understand what is happening here and if that is the information, you need to know. Actually I think it may be a port error. Do I need to use apache or is it enough, if there is unicorn?

In the gitlab.rb file, I configured external_url ‘http://myurl’ without adding the port number, which I set to 8088 in unicorn.rb. Reconfiguring and restarting gitlab-ctl didn’t change anything so far.

gitlab-ctl status shows this:

run: alertmanager: (pid 23247) 2256s; run: log: (pid 30646) 257594s
run: gitaly: (pid 23253) 2256s; run: log: (pid 30592) 257596s
run: gitlab-monitor: (pid 23264) 2255s; run: log: (pid 30603) 257595s
run: gitlab-workhorse: (pid 23267) 2255s; run: log: (pid 30572) 257596s
run: logrotate: (pid 23276) 2255s; run: log: (pid 30608) 257595s
run: nginx: (pid 23282) 2254s; run: log: (pid 30573) 257596s
run: node-exporter: (pid 23288) 2254s; run: log: (pid 30593) 257596s
run: postgres-exporter: (pid 23300) 2253s; run: log: (pid 30657) 257594s
run: postgresql: (pid 23309) 2253s; run: log: (pid 30557) 257597s
run: prometheus: (pid 23320) 2252s; run: log: (pid 30628) 257595s
run: redis: (pid 23325) 2251s; run: log: (pid 30562) 257597s
run: redis-exporter: (pid 23334) 2251s; run: log: (pid 30654) 257594s
run: sidekiq: (pid 23341) 2250s; run: log: (pid 30591) 257596s
run: unicorn: (pid 23557) 2219s; run: log: (pid 30589) 257596s

Could you guys help me getting through this?

edit: Deinstalling apache2 and rebooting the server solved the problem.

Источник

Понравилась статья? Поделить с друзьями:
  • Uc3 ошибка частотника
  • Ubuntu error unmounting
  • Ubuntu файловая система доступна только для чтения как исправить
  • Ubuntu error the following packages have unmet dependencies
  • Ubuntu проверка системы на ошибки