trying to install the docker image from the instructions here:
install has been running for 14 hours at this point, login screen is there, but passwords are not yet available. Why is it taking so long to install?
what can I do to diagnose this and get my installation runing?
machine is an 8core xeon with 24GB of RAM and no load, even while installing this.
login screen is there, but passwords are not yet available. Why is it taking so long to install?
Try setting the password for the root (admin) user with
sudo docker exec -it gitlab gitlab-rake "gitlab:password:reset[root]"
If that doesn’t work, I’d check the logs an error message or stacktrace.
sudo docker logs -f gitlab
failed to create runc console socket: stat /run/user/1000: no such file or directory: unknown
logs are full of stuff like this: ==> /var/log/gitlab/gitlab-exporter/current <==
2023-09-30_22:07:50.59896 127.0.0.1 - - [30/Sep/2023:22:07:50 UTC] “GET /database HTTP/1.1” 200 1671
2023-09-30_22:07:50.59904 - → /database
==> /var/log/gitlab/gitlab-workhorse/current <==
{“error”:“keywatcher: pubsub receive: EOF”,“level”:“error”,“msg”:“”,“time”:“2023-09-30T22:07:52Z”}
{“address”:“/var/opt/gitlab/redis/redis.socket”,“level”:“info”,“msg”:“redis: dialing”,“network”:“unix”,“time”:“2023-09-30T22:07:52Z”}
==> /var/log/gitlab/gitlab-exporter/current <==
2023-09-30_22:07:54.34958 127.0.0.1 - - [30/Sep/2023:22:07:54 UTC] “GET /sidekiq HTTP/1.1” 200 180407
2023-09-30_22:07:54.34963 - → /sidekiq
2023-09-30_22:07:55.70207 127.0.0.1 - - [30/Sep/2023:22:07:55 UTC] “GET /ruby HTTP/1.1” 200 1080
2023-09-30_22:07:55.70214 - → /ruby
==> /var/log/gitlab/gitlab-rails/production_json.log <==
{“method”:“GET”,“path”:“/-/metrics”,“format”:“html”,“controller”:“MetricsController”,“action”:“index”,“status”:200,“time”:“2023-09-30T22:07:56.954Z”,“params
“:,“db_count”:0,“db_write_count”:0,“db_cached_count”:0,“db_replica_count”:0,“db_primary_count”:0,“db_main_count”:0,“db_ci_count”:0,“db_main_replica_count”
:0,“db_ci_replica_count”:0,“db_replica_cached_count”:0,“db_primary_cached_count”:0,“db_main_cached_count”:0,“db_ci_cached_count”:0,“db_main_replica_cached_c
ount”:0,“db_ci_replica_cached_count”:0,“db_replica_wal_count”:0,“db_primary_wal_count”:0,“db_main_wal_count”:0,“db_ci_wal_count”:0,“db_main_replica_wal_coun
t”:0,“db_ci_replica_wal_count”:0,“db_replica_wal_cached_count”:0,“db_primary_wal_cached_count”:0,“db_main_wal_cached_count”:0,“db_ci_wal_cached_count”:0,“db
_main_replica_wal_cached_count”:0,“db_ci_replica_wal_cached_count”:0,“db_replica_duration_s”:0.0,“db_primary_duration_s”:0.0,“db_main_duration_s”:0.0,“db_ci
_duration_s”:0.0,“db_main_replica_duration_s”:0.0,“db_ci_replica_duration_s”:0.0,“cpu_s”:0.094564,“mem_objects”:3295,“mem_bytes”:1680232,“mem_mallocs”:870,”
mem_total_bytes”:1812032,“pid”:1094,“worker_id”:“puma_1”,“rate_limiting_gates”:,“correlation_id”:“97bc3cc7-6bd9-47f2-9383-ee76fa5c7065”,“db_duration_s”:0.
0,“view_duration_s”:0.00083,“duration_s”:0.08989}
Got some help from a friend who knows docker, and this is a DOCKER problem and not a gitlab issue.
What’s the problem anyways?
Wow - 14 hours? You have got to be the most patient person in the world, amigo!
I would test the disks in that server. How old is this box? Even if it’s a recent server, one of the disks might just be a lemon.