sameersbn / sameersbn/docker-gitlab
First startup 8.6.6 - Init never finishes
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 8.1k
- Forks
- 2.1k
- Avg merge
- 17h 47m
- Merged PRs (30d)
- 7
Description
I'm having trouble starting gitlab. I'm using the provided docker-compose.yml everything seems to be going fine but the init never finishes. This is the output after 15-20 min:
gitlab_1 | 2016-04-19 18:06:45,710 CRIT Server 'unix_http_server' running without any HTTP authentication checking
gitlab_1 | 2016-04-19 18:06:45,710 INFO supervisord started with pid 1
gitlab_1 | 2016-04-19 18:06:46,713 INFO spawned: 'sidekiq' with pid 486
gitlab_1 | 2016-04-19 18:06:46,716 INFO spawned: 'unicorn' with pid 487
gitlab_1 | 2016-04-19 18:06:46,720 INFO spawned: 'gitlab-workhorse' with pid 488
gitlab_1 | 2016-04-19 18:06:46,723 INFO spawned: 'cron' with pid 489
gitlab_1 | 2016-04-19 18:06:46,726 INFO spawned: 'nginx' with pid 490
gitlab_1 | 2016-04-19 18:06:46,727 INFO spawned: 'sshd' with pid 491
gitlab_1 | 2016-04-19 18:06:48,303 INFO success: sidekiq entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
gitlab_1 | 2016-04-19 18:06:48,303 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
gitlab_1 | 2016-04-19 18:06:48,303 INFO success: gitlab-workhorse entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
gitlab_1 | 2016-04-19 18:06:48,303 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
gitlab_1 | 2016-04-19 18:06:48,303 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
gitlab_1 | 2016-04-19 18:06:48,303 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
redis_1 | [1] 19 Apr 12:41:00.059 * 10 changes in 300 seconds. Saving...
redis_1 | [1] 19 Apr 12:41:00.059 * Background saving started by pid 20
redis_1 | [20] 19 Apr 12:41:00.107 * DB saved on disk
redis_1 | [20] 19 Apr 12:41:00.108 * RDB: 4 MB of memory used by copy-on-write
redis_1 | [1] 19 Apr 12:41:00.160 * Background saving terminated with success
redis_1 | [1] 19 Apr 12:46:01.046 * 10 changes in 300 seconds. Saving...
redis_1 | [1] 19 Apr 12:46:01.047 * Background saving started by pid 21
redis_1 | [21] 19 Apr 12:46:01.120 * DB saved on disk
redis_1 | [21] 19 Apr 12:46:01.121 * RDB: 4 MB of memory used by copy-on-write
redis_1 | [1] 19 Apr 12:46:01.147 * Background saving terminated with success
Navigating to localhost:10080 will return a 502 bad gateway. Is it expected to take this long on the first run? I've started it with DEBUG=true and I don't see any errors.
Ubuntu 14.04
Docker version 1.11.0, build 4dc5990
Docker info:
Containers: 7
Running: 4
Paused: 0
Stopped: 3
Images: 8
Server Version: 1.11.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 102
Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 3.13.0-85-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.63 GiB
Name: lnxsimonth
ID: 63MR:GFEV:RM6F:Q33N:LGZF:CRMW:BPBN:Q5YQ:KVKS:SDLF:G44O:FJHJ
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Http Proxy: http://proxy:3128/
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the provided docker-compose.yml and the startup output from the gitlab, redis, and related containers. Reproduce the first startup and determine why initialization does not complete and localhost:10080 returns a 502; done means identifying a reproducible cause and documenting or validating the required fix.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, docker-compose
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100