Docker-gitlab: GitLab is taking too much time to respond. 502Error

[EasonWang01]

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.

[r2evans]

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

[EasonWang01]

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.

[EasonWang01]

@sameersbn

[iamchanghyunpark]

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

[EasonWang01]

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

[iamchanghyunpark]

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

docker exec -it gitlab bash # If you use docker
docker-compose exec gitlab bash # if you use docker-compose

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

[alex3305]

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...

[iamchanghyunpark]

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

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

[kurkowskik]

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.

[rizwansarwar]

@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.

Thank you

[leoluyi]

Checking the status by running:

$ docker exec gitlab gitlab-ctl status

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

$ docker exec gitlab gitlab-ctl start

[rjuszczyk]

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

[LF00]

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

[stale[bot]]

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.

[tray2100]

It would be great if there was a more permanent solution within the container itself that would resolve this.