The database was initialized with LC_COLLATE “en_US.UTF-8”, which is not recognized by setlocale()
Summary
Using Omnibus Gitlab in Docker, during startup reconfigure the following message is displayed and the container crashes
The database was initialized with LC_COLLATE “en_US.UTF-8”, which is not recognized by setlocale()
Steps to reproduce
- Start container with existing database that was apparently created with a locale unrecognized by Gitlab
Example Project
What is the current bug behavior?
The database was initialized with LC_COLLATE “en_US.UTF-8”, which is not recognized by setlocale() Container then exits
What is the expected correct behavior?
Normal startup
Results of GitLab environment info
Expand for output related to GitLab environment info
gitlab-rake gitlab:env:info System information System: Current User: git Using RVM: no Ruby Version: 2.7.5p203 Gem Version: 3.1.4 Bundler Version:2.2.33 Rake Version: 13.0.6 Redis Version: 6.2.6 Sidekiq Version:6.4.0 Go Version: unknown GitLab information Version: 14.9.3 Revision: ec11aba56f1 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.7 URL: https://gitlab.mycompany.com HTTP Clone URL: https://gitlab.mycompany.com/some-group/some-project.git SSH Clone URL: ssh://git@gitlab.mycompany.com:2222/some-group/some-project.git Using LDAP: yes Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.24.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Results of GitLab application Check
Expand for output related to the GitLab application check
gitlab-rake gitlab:check SANITIZE=true Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 13.24.0 ? ... OK (13.24.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes Number of Sidekiq processes (cluster/worker) ... 1/1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain not verifying SSL hostname of LDAPS server 'dir.mycompany.com:636' LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 100 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... no Try fixing it: sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} ; sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path /var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} ; For more information see: doc/install/installation.md in section "GitLab" Please fix the error above and rerun the checks. Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... 10/7 ... yes 2/29 ... yes 2/30 ... yes 30/35 ... yes 2/37 ... yes 2/39 ... yes 2/40 ... yes 2/41 ... yes 2/42 ... yes 2/43 ... yes 2/44 ... yes 30/64 ... yes 30/68 ... yes 29/75 ... yes 2/82 ... yes 29/85 ... yes 17/86 ... yes 29/87 ... yes 29/90 ... yes 29/91 ... yes 29/92 ... yes 29/93 ... yes 29/94 ... yes 29/95 ... yes 29/96 ... yes 29/97 ... yes 29/98 ... yes 30/99 ... yes 2/102 ... yes 35/103 ... yes 36/104 ... yes 2/105 ... yes 25/107 ... yes 29/108 ... yes 29/111 ... yes 29/113 ... yes 35/114 ... yes 35/115 ... yes 9/116 ... yes 2/117 ... yes 36/119 ... yes 29/120 ... yes 29/121 ... yes 2/122 ... yes 29/123 ... yes 29/125 ... yes 9/126 ... yes 29/128 ... yes 29/129 ... yes 25/130 ... yes 38/131 ... yes 38/132 ... yes 38/133 ... yes 38/134 ... yes 38/135 ... yes 29/136 ... yes 29/137 ... yes 39/138 ... yes 25/139 ... yes 41/146 ... yes 41/147 ... yes 42/151 ... yes 43/152 ... yes 29/153 ... yes 29/154 ... yes 29/155 ... yes 17/156 ... yes 2/157 ... yes 2/158 ... yes 2/160 ... yes 29/161 ... yes 37/163 ... yes 25/164 ... yes 25/166 ... yes 2/167 ... yes 30/168 ... yes 29/169 ... yes 29/170 ... yes 29/171 ... yes Redis version >= 5.0.0? ... yes Ruby version >= 2.7.2 ? ... yes (2.7.5) Git user has default SSH configuration? ... yes Active users: ... 18 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
- Convert database to expected locale
- Install locales and set local with localedef
My current workaround is to override the entrypoint script with the following:
if ! locale -a | grep -q "en_US.UTF-8"; then
apt update
apt-get install locales
localedef -f UTF-8 -i en_US en_US.UTF-8
fi
exec /assets/wrapper
Though, I would rather not have to workaround it.