Gitlab 502 ошибка - Не ошибается лишь тот, кто ничего не делает!

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

Источник

GitLab Forum

Источник

I installed Gitlab on Raspberry Pi2, and it had worked well for a couple of months. But since shutting down the power of RPi, it doesn’t work anymore. The webpage returns 502 error.

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

So I tried reconfigure (sudo gitlab-ctl reconfigure) but, it failed with the error message:

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

I don’t know how to resolve this problem.

edwardmlyte

15.7k23 gold badges58 silver badges82 bronze badges

asked Oct 21, 2015 at 8:11

I saw issue like this several times.

If GitLab has been worked fine please do not touch anything. Just wait. It seems GitLab has not been started properly

I mean that after booting system you have to wait 1-2 minutes before using GitLab. GitLab needs some time for starting.

answered Oct 12, 2016 at 7:06

VladVlad

3,4651 gold badge30 silver badges24 bronze badges

I am not adding a comment since my answer needs some good formatting.

So that means, your port 8080 is already being used. I would advise to stop GitLab, and change unicorn port from 8080 to 8081 (or some unused port).

After starting/restarting GitLab wait for 2 minutes, and you should be okay. If not, again check gitlab-ctl tail for any errors.

# 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)

You need to be root or a sudo user (with root privileges) to run these commands.

answered Nov 29, 2015 at 10:38

vikas027vikas027

5,1724 gold badges39 silver badges51 bronze badges

After inspecting the gitlab-ctl tail (reboot loop) it turned out that there is not enough RAM (2GB) and there is no swap file in my fresh Ubuntu setup.

As mentioned in requirements GitLab requires at least 2GB RAM + 2GB swap memory …

So to create a swap file follow those steps:

gitlab-ctl stop
mkdir /swap && touch /swap/swapfile.img
dd if=/dev/zero of=/swap/swapfile.img bs=1024 count=2M # if you want 4G change 2M to 4M
chmod 0600 /swap/swapfile.img
mkswap /swap/swapfile.img
nano /etc/fstab and add «/swap/swapfile.img swap swap sw 0 0»
swapon /swap/swapfile.img

Verify if it works : cat /proc/swaps

Filename                Type        Size    Used    Priority

/swap/swapfile.img      file        2097148 0       -1

gitlab-ctl start

more info about creating swap : here

answered Feb 28, 2018 at 10:58

trojantrojan

1,45519 silver badges27 bronze badges

You can follow below steps to fix this kind of issue.

Update unicorn['port'] to ****.(Different port which is not used for process in the system)
Update nginx['port'] to ****.(Different port which is not used for process in the system)
Update web_server username and web_server group in this file as well and set it to apache’s/httpd’s username and group

Then do gitlab-ctl reconfigure and gitlab-ctl restart

Cà phê đen

1,8652 gold badges21 silver badges20 bronze badges

answered Oct 12, 2016 at 7:16

himeshc_IBhimeshc_IB

8434 silver badges10 bronze badges

You should change your Unicorn Settings
If you need to adjust the Unicorn timeout or the number of workers you can use the following settings in /etc/gitlab/gitlab.rb.
Change the following:

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

do not forget to remove # in line start if commented.
Run sudo gitlab-ctl reconfigure for the change to take effect.

answered Jul 29, 2018 at 10:04

Anas NaguibAnas Naguib

99610 silver badges12 bronze badges

This error is also occurred when the system, in your case the Raspberry Pi2 (in my case, in an t2.micro AWS EC2 instance) due to not fulfilling the minimum requirements for installing Gitlab.

That is the lack of Memory (t2.micro is 1GiB, but Gitlab requires 4GiB) for further processing. Therefore, provide all the requirements correctly (I occupied a t2.medium instance which is 4GiB instead of t2.micro).
It would be appropriate if the system has been enabled accurately.

answered Nov 9, 2017 at 5:00

Need to set nginx[‘listen_port’] and unicorn[‘port’].
For example:

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

Then:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

answered Dec 4, 2017 at 12:22

There was a port collision at my site. Jenkins has already run on my site, which uses the 8080 port also.

Change Gitlab or Jenkins port.

answered Mar 19, 2020 at 10:55

betontalpfabetontalpfa

3,3841 gold badge32 silver badges65 bronze badges

Something is listening to the 8080 port, so Unicorn can’t start.
What does the following command indicate?
The ports for Redis, PostgreSQL and Puma can be overridden in

/etc/gitlab/gitlab.rb

as follows:

    redis['port'] = 1234
    postgresql['port'] = 2345
    puma['port'] = 3456

For NGINX port changes please see settings/nginx.md.

see https://docs.gitlab.com/omnibus/common_installation_problems/#tcp-ports-for-gitlab-services-are-already-taken
(TCP ports for GitLab services are already taken)

answered May 16, 2020 at 9:23

ismaelismael

4341 gold badge4 silver badges11 bronze badges

Please note if you got 502 Whoops, GitLab is taking too much time to respond
before going so much with every step

Ensure that your server has at least 4GB of RAM
and give her server at least 10 minutes if you are using digital ocean droplet

answered Nov 22, 2021 at 12:44

I had that kind of error before and turns out that I had not physicall space (in my case, a virtual machine). Check that you have enough space

answered Apr 30, 2022 at 13:45

JoseJose

175 bronze badges

It is posyble that you has change change some configuration file, use this lines in your terminal:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Now wait a few minutes, and try again.

answered Jul 13, 2018 at 16:34

You should only change external_url http://xxx.xxx.xxx.xx:9090. Don’t change # unicorn['port'] = 8080.

Cà phê đen

1,8652 gold badges21 silver badges20 bronze badges

answered Jun 17, 2019 at 2:45

Источник

Before describing the diagnosis and troubleshooting methods that I used to solve this problem, allow me to give you a little rundown on what this is all about.

GitHub: It is a wonderful tool that make managing and administering lots of Git repositories and their associated permissions on a centralized server quite easy. What if you want to do something like this on your own servers where your developers can store their projects and network? GitLab gives you complete control over your repositories and allows you to decide whether they are public, private or free. It’s a github clone to be more specific running on your own hardware.

To learn more about the minimum requirements to run your own gitlab service click here.

Hunting down the errors with GitLab:

One of our gitlab servers started throwing up “502 bad gateway” error one fine day. We have a Ubuntu server with nginx+gitlab+ISPconfig (ISPconfig is a free hosting control panel) to server as a gitlab server.

Troubleshooting:

The usual routine is to check the error logs pertaining to the service.

We found this from gitlab_erorr.log

2012/09/21 23:42:29 [error] 19689#0: *5 connect() to unix:/home/gitlab/gitlab/tmp/sockets/gitlab.socket failed (111: Connection refused) while connecting to upstream, client: ****, server: gitlab..***, request: “GET / HTTP/1.1”, upstream:

Bad Gateway means nginx wasn’t able to connect to the upstream socket.

Three possible reasons:-

Misconfigured path to the socket
Unicorn is not running.
Unicorn crashes intermittently due to resource shortage

There was no resource shortage. Server was in ship-shape.

We tried to restart gitlab

ro[email protected]:/etc/nginx/sites-available# /etc/init.d/gitlab restart

Removing stale Unicorn web server pid. This is most likely caused by the web server crashing the last time it ran.
Removing stale Sidekiq web server pid. This is most likely caused by the Sidekiq crashing the last time it ran.
Starting the GitLab Unicorn web server…
master failed to start, check stderr log for details
Starting the GitLab Sidekiq event dispatcher…
The GitLab Unicorn webserver is not running.
The GitLab Sidekiq job dispatcher with pid 6296 is running.

The solution still eluded us. After a couple of minutes googling using “The GitLab Unicorn webserver is not running” as search keyword. We stumbled on the possibility of a port number mismatch/misconfiguration. We decided to check that.

Root Cause

We noticed that ISPconfig and Unicorn were running on same port 8080. Now that is the root cause of this problem. One of our associates had installed ISPconfig couple of hours before and inadvertently used the port number 8080 reserved for unicorn.

We changed ISP config port to 8081 from here:-

/etc/nginx/sites-available/ispconfig.vhost

/home/git/gitlab/config/unicorn.rb

Restarted ngnix and gitlab

Now both services are no longer sharing one port.

[email protected]:/home/git/gitlab/config# netstat -tulpn | grep :808
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 6692/unicorn.rb -E
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 6627/nginx

So, that was it! Double check before and after you install anything on the server. Make sure it does not adversely affect or tamper the functions of other services.

Sandeep, Sr. Linux administrator authored this post and it has been copy edited by Vineeth Venugopal from InstaCarma team.

InstaCarma is an eminent provider of managed IT services and web hosting technical support where you can easily avail 24*7*365 uninterrupted services.

Источник

Solution by iamchanghyunpark

“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”

docker-compose exec gitlab bash
vi log/unicorn.stderr.log # remove the value (which is the pid), save and exit
exit # from the bash shell of the gitlab container

#Now restart the containers
docker-compose down
docker-compose up -d

Share on:

Источник