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.4k23 gold badges58 silver badges82 bronze badges
asked Oct 21, 2015 at 8:11
2
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,4271 gold badge30 silver badges24 bronze badges
3
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,0124 gold badges37 silver badges50 bronze badges
7
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 4Mchmod 0600 /swap/swapfile.imgmkswap /swap/swapfile.imgnano /etc/fstaband add «/swap/swapfile.img swap swap sw 0 0»swapon /swap/swapfile.img-
Verify if it works :
cat /proc/swapsFilename 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,43420 silver badges26 bronze badges
1
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_serverusername andweb_servergroup 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,8372 gold badges20 silver badges19 bronze badges
answered Oct 12, 2016 at 7:16
himeshc_IBhimeshc_IB
8334 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
94710 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
1
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,3341 gold badge32 silver badges61 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
4241 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,8372 gold badges20 silver badges19 bronze badges
answered Jun 17, 2019 at 2:45
1
Теги: 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».
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…
Recently, there are servers on the cloud that need to be released, and then the gitlab running on the cloud has to move somewhere. Because of limited resources, it borrows to build an environment on other servers (available memory is less than 4,000), but when the goose starts up, it inexplicably appears 502, Excuse me? Then I searched for some solutions on issue blogs (such as modifying ports, restarting or hup A service) and found some information in the log during the adjustment process.
The main idea of this trip is the train of thought. When you open your horizon, you will feel open-minded. It turns out that this is actually a minor problem.
1. It is not clear what the services and uses of the application will be started. Only status will be viewed simply.
2. Baidu is the first thing that comes to mind when you see a mistake. Wouldn’t it be good to look for a log path and read the log first?
3. Unaware of the relationship between services (e.g. postgresql and unicorn), I always knew that Unicorn did not listen to ports properly after booting, but there was no special information in the log (well, maybe because I read the wrong file)[Smile bitterly]
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